<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 22:00:22 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-53036</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-53036</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-53036</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0862 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862</link>
      <description>certfr-2026-avi-0862</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862</guid>
    </item>
    <item>
      <title>EUVD-2026-348134</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-348134</link>
      <description>EUVD-2026-348134</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-348134</guid>
    </item>
    <item>
      <title>fkie_cve-2026-53036</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-53036</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: Fix off-by-one in check_imm signed range check&lt;/p&gt;
&lt;p&gt;check_imm(bits, imm) is used in the arm64 BPF JIT to verify that
a branch displacement (in arm64 instruction units) fits into the
signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding
before it is handed to the encoder. The macro currently tests for
(imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits
values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A
signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check
admits one extra bit of range on each side.&lt;/p&gt;
&lt;p&gt;In particular, for check_imm19(), values in [2^18, 2^19) slip past
the check but do not fit into the 19-bit signed imm19 field of
B.cond. aarch64_insn_encode_immediate() then masks the raw value
into the 19-bit field, setting bit 18 (the sign bit) and flipping
a forward branch into a backward one. Same class of issue exists
for check_imm26() and the B/BL encoding. Shift by (bits - 1)
instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: Fix off-by-one in check_imm signed range check&lt;/p&gt;
&lt;p&gt;check_imm(bits, imm) is used in the arm64 BPF JIT to verify that
a branch displacement (in arm64 instruction units) fits into the
signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding
before it is handed to the encoder. The macro currently tests for
(imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits
values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A
signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check
admits one extra bit of range on each side.&lt;/p&gt;
&lt;p&gt;In particular, for check_imm19(), values in [2^18, 2^19) slip past
the check but do not fit into the 19-bit signed imm19 field of
B.cond. aarch64_insn_encode_immediate() then masks the raw value
into the 19-bit field, setting bit 18 (the sign bit) and flipping
a forward branch into a backward one. Same class of issue exists
for check_imm26() and the B/BL encoding. Shift by (bits - 1)
instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-53036</guid>
    </item>
    <item>
      <title>GHSA-mfc2-6j6q-99vp</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mfc2-6j6q-99vp</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: Fix off-by-one in check_imm signed range check&lt;/p&gt;
&lt;p&gt;check_imm(bits, imm) is used in the arm64 BPF JIT to verify that
a branch displacement (in arm64 instruction units) fits into the
signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding
before it is handed to the encoder. The macro currently tests for
(imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits
values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A
signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check
admits one extra bit of range on each side.&lt;/p&gt;
&lt;p&gt;In particular, for check_imm19(), values in [2^18, 2^19) slip past
the check but do not fit into the 19-bit signed imm19 field of
B.cond. aarch64_insn_encode_immediate() then masks the raw value
into the 19-bit field, setting bit 18 (the sign bit) and flipping
a forward branch into a backward one. Same class of issue exists
for check_imm26() and the B/BL encoding. Shift by (bits - 1)
instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: Fix off-by-one in check_imm signed range check&lt;/p&gt;
&lt;p&gt;check_imm(bits, imm) is used in the arm64 BPF JIT to verify that
a branch displacement (in arm64 instruction units) fits into the
signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding
before it is handed to the encoder. The macro currently tests for
(imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits
values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A
signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check
admits one extra bit of range on each side.&lt;/p&gt;
&lt;p&gt;In particular, for check_imm19(), values in [2^18, 2^19) slip past
the check but do not fit into the 19-bit signed imm19 field of
B.cond. aarch64_insn_encode_immediate() then masks the raw value
into the 19-bit field, setting bit 18 (the sign bit) and flipping
a forward branch into a backward one. Same class of issue exists
for check_imm26() and the B/BL encoding. Shift by (bits - 1)
instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mfc2-6j6q-99vp</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-53036 — bpf, arm64: Fix off-by-one in check_imm signed range check</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-53036</link>
      <description>msrc_CVE-2026-53036</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-53036</guid>
    </item>
    <item>
      <title>OESA-2026-3156 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3156</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: add missing kref_get in handle_write_conflicts&lt;/p&gt;
&lt;p&gt;With `two-primaries` enabled, DRBD tries to detect &amp;amp;quot;concurrent&amp;amp;quot; writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.&lt;/p&gt;
&lt;p&gt;In handling &amp;amp;quot;superseeded&amp;amp;quot; writes, we forgot a kref_get,
resulting in a premature drbd_destroy_device and use after free,
and further to kernel crashes with symptoms.&lt;/p&gt;
&lt;p&gt;Relevance: No one should use DRBD as a random data generator, and apparently
all users of &amp;amp;quot;two-primaries&amp;amp;quot; handle concurrent writes correctly on layer up.
That is cluster file systems use some distributed lock manager,
and live migration in virtualization environments stops writes on one node
before starting writes on the other node.&lt;/p&gt;
&lt;p&gt;Which means that other than for &amp;amp;quot;test cases&amp;amp;quot;,
this code path is never taken in real life.&lt;/p&gt;
&lt;p&gt;FYI, in DRBD 9, things are handled differently nowadays.  We still detect
&amp;amp;quot;write conflicts&amp;amp;quot;, but no longer try to be smart about them.
We decided to disconnect hard instead: upper layers must not submit concurrent
writes. If they do, that&amp;amp;apos;s their fault.(CVE-2025-38708)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mwifiex: Initialize the chan_stats array to zero&lt;/p&gt;
&lt;p&gt;The adapter-&amp;amp;gt…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: add missing kref_get in handle_write_conflicts&lt;/p&gt;
&lt;p&gt;With `two-primaries` enabled, DRBD tries to detect &amp;amp;quot;concurrent&amp;amp;quot; writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.&lt;/p&gt;
&lt;p&gt;In handling &amp;amp;quot;superseeded&amp;amp;quot; writes, we forgot a kref_get,
resulting in a premature drbd_destroy_device and use after free,
and further to kernel crashes with symptoms.&lt;/p&gt;
&lt;p&gt;Relevance: No one should use DRBD as a random data generator, and apparently
all users of &amp;amp;quot;two-primaries&amp;amp;quot; handle concurrent writes correctly on layer up.
That is cluster file systems use some distributed lock manager,
and live migration in virtualization environments stops writes on one node
before starting writes on the other node.&lt;/p&gt;
&lt;p&gt;Which means that other than for &amp;amp;quot;test cases&amp;amp;quot;,
this code path is never taken in real life.&lt;/p&gt;
&lt;p&gt;FYI, in DRBD 9, things are handled differently nowadays.  We still detect
&amp;amp;quot;write conflicts&amp;amp;quot;, but no longer try to be smart about them.
We decided to disconnect hard instead: upper layers must not submit concurrent
writes. If they do, that&amp;amp;apos;s their fault.(CVE-2025-38708)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mwifiex: Initialize the chan_stats array to zero&lt;/p&gt;
&lt;p&gt;The adapter-&amp;amp;gt…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3156</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21388-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22742-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22742-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:22742-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-53036</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53036</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 252 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix off-by-one in check_imm signed range check check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 252 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix off-by-one in check_imm signed range check check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm &amp;gt; 0 &amp;amp;&amp;amp; imm &amp;gt;&amp;gt; bits) || (imm &amp;lt; 0 &amp;amp;&amp;amp; ~imm &amp;gt;&amp;gt; bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53036</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2077 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077</link>
      <description>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen und weitere, nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen und weitere, nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077</guid>
    </item>
  </channel>
</rss>
