https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 01:24:18 +0000 https://vulnerability.circl.lu/vuln/cve-2026-64574 <p><strong>Affected:</strong> Linux</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> <p><strong>Affected:</strong> Linux</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://vulnerability.circl.lu/vuln/cve-2026-64574