https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 13:01:30 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11670 bdu:2026-11670 https://cve.radiocsirt.org/vuln/bdu:2026-11670 https://cve.radiocsirt.org/vuln/bell-cve-2026-23273 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-23273 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0545 certfr-2026-avi-0545 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0545 https://cve.radiocsirt.org/vuln/euvd-2026-364675 EUVD-2026-364675 https://cve.radiocsirt.org/vuln/euvd-2026-364675 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23273 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>macvlan: observe an RCU grace period in macvlan_common_newlink() error path</p> <p>valis reported that a race condition still happens after my prior patch.</p> <p>macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).</p> <p>We must respect an RCU period, either in macvlan or the core networking stack.</p> <p>After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:</p> <p>ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source</p> <p>(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument</p> <p>BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175</p> <p>CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/n…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>macvlan: observe an RCU grace period in macvlan_common_newlink() error path</p> <p>valis reported that a race condition still happens after my prior patch.</p> <p>macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).</p> <p>We must respect an RCU period, either in macvlan or the core networking stack.</p> <p>After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:</p> <p>ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source</p> <p>(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument</p> <p>BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175</p> <p>CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/n…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23273 https://cve.radiocsirt.org/vuln/ghsa-r5gh-q6f7-7q3v <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>macvlan: observe an RCU grace period in macvlan_common_newlink() error path</p> <p>valis reported that a race condition still happens after my prior patch.</p> <p>macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).</p> <p>We must respect an RCU period, either in macvlan or the core networking stack.</p> <p>After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:</p> <p>ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source</p> <p>(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument</p> <p>BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175</p> <p>CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/n…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>macvlan: observe an RCU grace period in macvlan_common_newlink() error path</p> <p>valis reported that a race condition still happens after my prior patch.</p> <p>macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).</p> <p>We must respect an RCU period, either in macvlan or the core networking stack.</p> <p>After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:</p> <p>ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source</p> <p>(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument</p> <p>BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175</p> <p>CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/n…</p> https://cve.radiocsirt.org/vuln/ghsa-r5gh-q6f7-7q3v https://cve.radiocsirt.org/vuln/icsa-26-209-04 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/icsa-26-209-04 https://cve.radiocsirt.org/vuln/oesa-2026-2416 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;apos;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto han…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;apos;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto han…</p> https://cve.radiocsirt.org/vuln/oesa-2026-2416 https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1 https://cve.radiocsirt.org/vuln/ssa-019113 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/ssa-019113 https://cve.radiocsirt.org/vuln/suse-su-2026:2068-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:2068-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23273 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 156 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: macvlan: observe an RCU grace period in macvlan_common_newlink() error path valis reported that a race condition still happens after my prior patch. macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev). We must respect an RCU period, either in macvlan or the core networking stack. After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source (ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvla…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 156 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: macvlan: observe an RCU grace period in macvlan_common_newlink() error path valis reported that a race condition still happens after my prior patch. macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev). We must respect an RCU period, either in macvlan or the core networking stack. After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source (ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: &lt;IRQ&gt; dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvla…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23273 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0809 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einem Denial-of-Service-Zustand, zur Manipulation und Offenlegung von Daten oder zu einer Speicherbeschädigung führen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einem Denial-of-Service-Zustand, zur Manipulation und Offenlegung von Daten oder zu einer Speicherbeschädigung führen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0809