https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 18:39:17 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-04164 bdu:2026-04164 https://cve.radiocsirt.org/vuln/bdu:2026-04164 https://cve.radiocsirt.org/vuln/bell-cve-2026-23255 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-23255 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0497 certfr-2026-avi-0497 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0497 https://cve.radiocsirt.org/vuln/euvd-2026-364672 EUVD-2026-364672 https://cve.radiocsirt.org/vuln/euvd-2026-364672 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23255 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: add proper RCU protection to /proc/net/ptype</p> <p>Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.</p> <p>Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.</p> <p>ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier.</p> <p>At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period.</p> <p>Define ptype_iter_state to carry a dev pointer along seq_net_private:</p> <p>struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch };</p> <p>We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes.</p> <p>We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)</p> <p>Many thanks to Dong Chenchen for providing a repro.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: add proper RCU protection to /proc/net/ptype</p> <p>Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.</p> <p>Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.</p> <p>ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier.</p> <p>At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period.</p> <p>Define ptype_iter_state to carry a dev pointer along seq_net_private:</p> <p>struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch };</p> <p>We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes.</p> <p>We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)</p> <p>Many thanks to Dong Chenchen for providing a repro.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23255 https://cve.radiocsirt.org/vuln/ghsa-9w39-mw48-92gc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: add proper RCU protection to /proc/net/ptype</p> <p>Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.</p> <p>Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.</p> <p>ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier.</p> <p>At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period.</p> <p>Define ptype_iter_state to carry a dev pointer along seq_net_private:</p> <p>struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch };</p> <p>We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes.</p> <p>We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)</p> <p>Many thanks to Dong Chenchen for providing a repro.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: add proper RCU protection to /proc/net/ptype</p> <p>Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.</p> <p>Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.</p> <p>ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier.</p> <p>At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period.</p> <p>Define ptype_iter_state to carry a dev pointer along seq_net_private:</p> <p>struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch };</p> <p>We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes.</p> <p>We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)</p> <p>Many thanks to Dong Chenchen for providing a repro.</p> https://cve.radiocsirt.org/vuln/ghsa-9w39-mw48-92gc https://cve.radiocsirt.org/vuln/msrc_cve-2026-23255 msrc_CVE-2026-23255 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23255 https://cve.radiocsirt.org/vuln/oesa-2026-1862 <p><strong>Affected:</strong> openEuler:24.03-LTS: 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>f2fs: fix to detect potential corrupted nid in free_nid_list</p> <p>As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let&amp;apos;s add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.(CVE-2025-68315)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ntfs3: Fix uninit buffer allocated by __getname()</p> <p>Fix uninit errors caused after buffer allocation given to &amp;apos;de&amp;apos;; by initializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nf_tables: fix use-after-free in nf_tables_addchain()</p> <p>nf_tables_addchain() publishes the chain to table-&amp;gt;chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between.</p> <p>This creates two use-after-free conditions:</p> <p>1) Control-plane: nf_tables_dump_chains() traverses table-&amp;gt;chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it.</p> <p>2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: 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>f2fs: fix to detect potential corrupted nid in free_nid_list</p> <p>As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let&amp;apos;s add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.(CVE-2025-68315)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ntfs3: Fix uninit buffer allocated by __getname()</p> <p>Fix uninit errors caused after buffer allocation given to &amp;apos;de&amp;apos;; by initializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nf_tables: fix use-after-free in nf_tables_addchain()</p> <p>nf_tables_addchain() publishes the chain to table-&amp;gt;chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between.</p> <p>This creates two use-after-free conditions:</p> <p>1) Control-plane: nf_tables_dump_chains() traverses table-&amp;gt;chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it.</p> <p>2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1862 https://cve.radiocsirt.org/vuln/opensuse-su-2026:20572-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:20572-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:1573-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:1573-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23255 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, 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 and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net: add proper RCU protection to /proc/net/ptype Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch. Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules. ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier. At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period. Define ptype_iter_state to carry a dev pointer along seq_net_private: struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch }; We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes. We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values) Many thanks to Dong Chenchen for providing a repro.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, 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 and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net: add proper RCU protection to /proc/net/ptype Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch. Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules. ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev to get device name without any barrier. At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt-&gt;dev without an RCU grace period. Define ptype_iter_state to carry a dev pointer along seq_net_private: struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch }; We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt-&gt;dev changes. We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values) Many thanks to Dong Chenchen for providing a repro.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23255 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0790 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einem Denial-of-Service-Zustand, einer Rechteausweitung oder einer Speicherbeschädigung führen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einem Denial-of-Service-Zustand, einer Rechteausweitung oder einer Speicherbeschädigung führen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0790