https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:02:20 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-64574 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-64574 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1030 certfr-2026-avi-1030 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1030 https://cve.radiocsirt.org/vuln/euvd-2026-353438 EUVD-2026-353438 https://cve.radiocsirt.org/vuln/euvd-2026-353438 https://cve.radiocsirt.org/vuln/fkie_cve-2026-64574 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: tear down new links on vif update error path</p> <p>When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free.</p> <p>The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed.</p> <p>drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures).</p> <p>Remove the new links&#39; debugfs entries and stop them before freeing.</p> <p>BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at add…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: tear down new links on vif update error path</p> <p>When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free.</p> <p>The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed.</p> <p>drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures).</p> <p>Remove the new links&#39; debugfs entries and stop them before freeing.</p> <p>BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at add…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-64574 https://cve.radiocsirt.org/vuln/ghsa-5g36-vffc-3jvc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: tear down new links on vif update error path</p> <p>When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free.</p> <p>The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed.</p> <p>drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures).</p> <p>Remove the new links&#39; debugfs entries and stop them before freeing.</p> <p>BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at add…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: tear down new links on vif update error path</p> <p>When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free.</p> <p>The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed.</p> <p>drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures).</p> <p>Remove the new links&#39; debugfs entries and stop them before freeing.</p> <p>BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at add…</p> https://cve.radiocsirt.org/vuln/ghsa-5g36-vffc-3jvc https://cve.radiocsirt.org/vuln/msrc_cve-2026-64574 msrc_CVE-2026-64574 https://cve.radiocsirt.org/vuln/msrc_cve-2026-64574 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1 <p>kernel-devel-7.1.7-1.1 on GA media</p> <p>kernel-devel-7.1.7-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1 https://cve.radiocsirt.org/vuln/suse-su-2026:23477-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:23477-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64574 <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 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links&#39; debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff…</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 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file-&gt;private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to &#39;free&#39;, which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file-&gt;private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link&#39;s keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (&#34;wifi: mac80211: avoid weird state in error path&#34;) hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links&#39; teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links&#39; debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64574 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2659 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, einen Denial-of-Service-Zustand auszulösen, Daten zu manipulieren oder vertrauliche Informationen offenzulegen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, einen Denial-of-Service-Zustand auszulösen, Daten zu manipulieren oder vertrauliche Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2659