<?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 01:51:51 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12244</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12244</link>
      <description>bdu:2026-12244</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12244</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31570</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31570</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-31570</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0519 — De multiples vulnérabilités ont été découvertes dans Microsoft Azure Linux. Elles permettent à un attaquant de provoque…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0519</link>
      <description>certfr-2026-avi-0519</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0519</guid>
    </item>
    <item>
      <title>EUVD-2026-347721</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347721</link>
      <description>EUVD-2026-347721</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347721</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31570</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31570</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;can: gw: fix OOB heap access in cgw_csum_crc8_rel()&lt;/p&gt;
&lt;p&gt;cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():&lt;/p&gt;
&lt;p&gt;int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);
    int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);
    int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);&lt;/p&gt;
&lt;p&gt;if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)
        return;&lt;/p&gt;
&lt;p&gt;However, the loop and the result write then use the raw s8 fields directly
instead of the computed variables:&lt;/p&gt;
&lt;p&gt;for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */
    cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */&lt;/p&gt;
&lt;p&gt;With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,
calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with
i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64].
This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the
start of the canfd_frame on the heap.&lt;/p&gt;
&lt;p&gt;The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`
correctly throughout; fix cgw_csum_crc8_rel() to match.&lt;/p&gt;
&lt;p&gt;Confirmed with KASAN on linux-7.0-rc2:
  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0
  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62&lt;/p&gt;
&lt;p&gt;To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&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;can: gw: fix OOB heap access in cgw_csum_crc8_rel()&lt;/p&gt;
&lt;p&gt;cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():&lt;/p&gt;
&lt;p&gt;int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);
    int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);
    int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);&lt;/p&gt;
&lt;p&gt;if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)
        return;&lt;/p&gt;
&lt;p&gt;However, the loop and the result write then use the raw s8 fields directly
instead of the computed variables:&lt;/p&gt;
&lt;p&gt;for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */
    cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */&lt;/p&gt;
&lt;p&gt;With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,
calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with
i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64].
This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the
start of the canfd_frame on the heap.&lt;/p&gt;
&lt;p&gt;The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`
correctly throughout; fix cgw_csum_crc8_rel() to match.&lt;/p&gt;
&lt;p&gt;Confirmed with KASAN on linux-7.0-rc2:
  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0
  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62&lt;/p&gt;
&lt;p&gt;To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31570</guid>
    </item>
    <item>
      <title>GHSA-67vp-4p2p-jr3c</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-67vp-4p2p-jr3c</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;can: gw: fix OOB heap access in cgw_csum_crc8_rel()&lt;/p&gt;
&lt;p&gt;cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():&lt;/p&gt;
&lt;p&gt;int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);
    int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);
    int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);&lt;/p&gt;
&lt;p&gt;if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)
        return;&lt;/p&gt;
&lt;p&gt;However, the loop and the result write then use the raw s8 fields directly
instead of the computed variables:&lt;/p&gt;
&lt;p&gt;for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */
    cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */&lt;/p&gt;
&lt;p&gt;With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,
calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with
i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64].
This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the
start of the canfd_frame on the heap.&lt;/p&gt;
&lt;p&gt;The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`
correctly throughout; fix cgw_csum_crc8_rel() to match.&lt;/p&gt;
&lt;p&gt;Confirmed with KASAN on linux-7.0-rc2:
  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0
  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62&lt;/p&gt;
&lt;p&gt;To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&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;can: gw: fix OOB heap access in cgw_csum_crc8_rel()&lt;/p&gt;
&lt;p&gt;cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():&lt;/p&gt;
&lt;p&gt;int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);
    int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);
    int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);&lt;/p&gt;
&lt;p&gt;if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)
        return;&lt;/p&gt;
&lt;p&gt;However, the loop and the result write then use the raw s8 fields directly
instead of the computed variables:&lt;/p&gt;
&lt;p&gt;for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */
    cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */&lt;/p&gt;
&lt;p&gt;With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,
calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with
i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64].
This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the
start of the canfd_frame on the heap.&lt;/p&gt;
&lt;p&gt;The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`
correctly throughout; fix cgw_csum_crc8_rel() to match.&lt;/p&gt;
&lt;p&gt;Confirmed with KASAN on linux-7.0-rc2:
  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0
  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62&lt;/p&gt;
&lt;p&gt;To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-67vp-4p2p-jr3c</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31570 — can: gw: fix OOB heap access in cgw_csum_crc8_rel()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31570</link>
      <description>msrc_CVE-2026-31570</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31570</guid>
    </item>
    <item>
      <title>OESA-2026-2234 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2234</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;bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing&lt;/p&gt;
&lt;p&gt;struct bpf_plt contains a u64 target field. Currently, the BPF JIT
allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT
buffer.&lt;/p&gt;
&lt;p&gt;Because the base address of the JIT buffer can be 4-byte aligned (e.g.,
ending in 0x4 or 0xc), the relative padding logic in build_plt() fails
to ensure that target lands on an 8-byte boundary.&lt;/p&gt;
&lt;p&gt;This leads to two issues:
1. UBSAN reports misaligned-access warnings when dereferencing the
   structure.
2. More critically, target is updated concurrently via WRITE_ONCE() in
   bpf_arch_text_poke() while the JIT&amp;amp;apos;d code executes ldr. On arm64,
   64-bit loads/stores are only guaranteed to be single-copy atomic if
   they are 64-bit aligned. A misaligned target risks a torn read,
   causing the JIT to jump to a corrupted address.&lt;/p&gt;
&lt;p&gt;Fix this by increasing the allocation alignment requirement to 8 bytes
(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of
the JIT buffer to an 8-byte boundary, allowing the relative padding math
in build_plt() to correctly align the target field.(CVE-2026-23383)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: validate p_idx bounds in ext4_ext_correct_indexes&lt;/p&gt;
&lt;p&gt;ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the f…&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;bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing&lt;/p&gt;
&lt;p&gt;struct bpf_plt contains a u64 target field. Currently, the BPF JIT
allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT
buffer.&lt;/p&gt;
&lt;p&gt;Because the base address of the JIT buffer can be 4-byte aligned (e.g.,
ending in 0x4 or 0xc), the relative padding logic in build_plt() fails
to ensure that target lands on an 8-byte boundary.&lt;/p&gt;
&lt;p&gt;This leads to two issues:
1. UBSAN reports misaligned-access warnings when dereferencing the
   structure.
2. More critically, target is updated concurrently via WRITE_ONCE() in
   bpf_arch_text_poke() while the JIT&amp;amp;apos;d code executes ldr. On arm64,
   64-bit loads/stores are only guaranteed to be single-copy atomic if
   they are 64-bit aligned. A misaligned target risks a torn read,
   causing the JIT to jump to a corrupted address.&lt;/p&gt;
&lt;p&gt;Fix this by increasing the allocation alignment requirement to 8 bytes
(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of
the JIT buffer to an 8-byte boundary, allowing the relative padding math
in build_plt() to correctly align the target field.(CVE-2026-23383)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: validate p_idx bounds in ext4_ext_correct_indexes&lt;/p&gt;
&lt;p&gt;ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the f…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2234</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21555-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-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:21555-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:2111-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:2111-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:2111-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31570</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31570</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 205 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():     int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);     int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);     int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);     if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)         return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:     for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */     cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64]. This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2:   BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0   Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 205 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():     int from = calc_idx(crc8-&amp;gt;from_idx, cf-&amp;gt;len);     int to   = calc_idx(crc8-&amp;gt;to_idx,   cf-&amp;gt;len);     int res  = calc_idx(crc8-&amp;gt;result_idx, cf-&amp;gt;len);     if (from &amp;lt; 0 || to &amp;lt; 0 || res &amp;lt; 0)         return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:     for (i = crc8-&amp;gt;from_idx; ...)        /* BUG: raw negative index */     cf-&amp;gt;data[crc8-&amp;gt;result_idx] = ...;    /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf-&amp;gt;data[-64], and the write goes to cf-&amp;gt;data[-64]. This write might end up to 56 (7.0-rc) or 40 (&amp;lt;= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2:   BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0   Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31570</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1279 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</guid>
    </item>
  </channel>
</rss>
