https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 08:41:42 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-00794 bdu:2025-00794 https://cve.radiocsirt.org/vuln/bdu:2025-00794 https://cve.radiocsirt.org/vuln/euvd-2026-309602 EUVD-2026-309602 https://cve.radiocsirt.org/vuln/euvd-2026-309602 https://cve.radiocsirt.org/vuln/fkie_cve-2021-47225 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mac80211: fix deadlock in AP/VLAN handling</p> <p>Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.</p> <p>To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mac80211: fix deadlock in AP/VLAN handling</p> <p>Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.</p> <p>To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-47225 https://cve.radiocsirt.org/vuln/ghsa-mpm3-wjp6-8g7x <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mac80211: fix deadlock in AP/VLAN handling</p> <p>Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.</p> <p>To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mac80211: fix deadlock in AP/VLAN handling</p> <p>Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.</p> <p>To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</p> https://cve.radiocsirt.org/vuln/ghsa-mpm3-wjp6-8g7x https://cve.radiocsirt.org/vuln/gsd-2021-47225 gsd-2021-47225 https://cve.radiocsirt.org/vuln/gsd-2021-47225 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47225 <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 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mac80211: fix deadlock in AP/VLAN handling Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there. To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</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 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mac80211: fix deadlock in AP/VLAN handling Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there. To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can&#39;t easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn&#39;t used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47225