CVE-2022-48815: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
AI Analysis
Technical Summary
CVE-2022-48815 is a vulnerability identified in the Linux kernel's Distributed Switch Architecture (DSA) subsystem, specifically affecting the bcm_sf2 (Broadcom Starfighter 2) switch driver. The issue arises from improper management of the MDIO bus resource lifecycle when using the devres (device resource management) framework. The vulnerability is rooted in the use of devm_mdiobus_alloc() for allocating the MDIO bus, which leads to a panic during device shutdown sequences. This occurs because mdiobus_free() is called from devm_mdiobus_free() via devres_release_all() and __device_release_driver(), but the MDIO bus may still be registered at that time, causing an invalid free operation. The problem is exacerbated when the DSA master device resides on a bus that invokes its remove callback during shutdown (e.g., dpaa2-eth on the fsl-mc bus). In such cases, device links cause the bcm_sf2 switch driver to be unbound prematurely, leading to the panic. The fix involves replacing devm_mdiobus_alloc() with a non-devres allocation method and manually freeing the MDIO bus to ensure orderly removal and prevent devres from freeing a still-registered bus. This change aligns with the handling of other DSA switch drivers and prevents kernel panics during device shutdown. The vulnerability does not have known exploits in the wild and affects specific Linux kernel versions identified by commit hashes. It is a low-level kernel resource management bug that can cause system instability or crashes during device shutdown sequences involving the affected drivers.
Potential Impact
For European organizations relying on Linux systems with the bcm_sf2 DSA switch driver—commonly found in embedded systems, network appliances, or specialized industrial hardware—this vulnerability could lead to unexpected kernel panics and system crashes during device shutdown or reboot processes. Such instability can disrupt network operations, cause downtime, and potentially lead to data loss if systems are abruptly halted. While the vulnerability does not directly allow code execution or privilege escalation, the denial-of-service impact on critical network infrastructure could be significant, especially in environments where uptime and reliability are paramount, such as telecommunications, manufacturing, or critical infrastructure sectors. Given the Linux kernel's widespread use in European data centers, telecom equipment, and industrial control systems, the vulnerability could affect operational continuity if unpatched. However, the absence of known exploits and the technical nature of the bug limit its immediate threat level. Organizations using affected hardware or custom Linux builds incorporating the bcm_sf2 driver should be aware of potential stability issues and plan timely patching to avoid service interruptions.
Mitigation Recommendations
1. Apply the official Linux kernel patches that replace devm_mdiobus_alloc() with manual allocation and freeing of the MDIO bus in the bcm_sf2 driver as soon as they are available in your kernel distribution. 2. For organizations maintaining custom or embedded Linux kernels, backport the fix from the relevant commit to ensure the bcm_sf2 driver handles MDIO bus resources correctly. 3. Test kernel updates in staging environments to verify that device shutdown sequences complete without panics or crashes. 4. Monitor system logs for kernel panics or device removal errors related to the bcm_sf2 driver or DSA subsystem to detect potential exploitation or instability. 5. Where possible, schedule maintenance windows to reboot or shut down affected systems safely after patching to prevent unexpected downtime. 6. Engage with hardware vendors to confirm whether their devices use the bcm_sf2 driver and request updated firmware or kernel versions if applicable. 7. Implement robust backup and recovery procedures to mitigate the impact of unexpected system crashes caused by this vulnerability.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Spain, Sweden, Finland
CVE-2022-48815: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
AI-Powered Analysis
Technical Analysis
CVE-2022-48815 is a vulnerability identified in the Linux kernel's Distributed Switch Architecture (DSA) subsystem, specifically affecting the bcm_sf2 (Broadcom Starfighter 2) switch driver. The issue arises from improper management of the MDIO bus resource lifecycle when using the devres (device resource management) framework. The vulnerability is rooted in the use of devm_mdiobus_alloc() for allocating the MDIO bus, which leads to a panic during device shutdown sequences. This occurs because mdiobus_free() is called from devm_mdiobus_free() via devres_release_all() and __device_release_driver(), but the MDIO bus may still be registered at that time, causing an invalid free operation. The problem is exacerbated when the DSA master device resides on a bus that invokes its remove callback during shutdown (e.g., dpaa2-eth on the fsl-mc bus). In such cases, device links cause the bcm_sf2 switch driver to be unbound prematurely, leading to the panic. The fix involves replacing devm_mdiobus_alloc() with a non-devres allocation method and manually freeing the MDIO bus to ensure orderly removal and prevent devres from freeing a still-registered bus. This change aligns with the handling of other DSA switch drivers and prevents kernel panics during device shutdown. The vulnerability does not have known exploits in the wild and affects specific Linux kernel versions identified by commit hashes. It is a low-level kernel resource management bug that can cause system instability or crashes during device shutdown sequences involving the affected drivers.
Potential Impact
For European organizations relying on Linux systems with the bcm_sf2 DSA switch driver—commonly found in embedded systems, network appliances, or specialized industrial hardware—this vulnerability could lead to unexpected kernel panics and system crashes during device shutdown or reboot processes. Such instability can disrupt network operations, cause downtime, and potentially lead to data loss if systems are abruptly halted. While the vulnerability does not directly allow code execution or privilege escalation, the denial-of-service impact on critical network infrastructure could be significant, especially in environments where uptime and reliability are paramount, such as telecommunications, manufacturing, or critical infrastructure sectors. Given the Linux kernel's widespread use in European data centers, telecom equipment, and industrial control systems, the vulnerability could affect operational continuity if unpatched. However, the absence of known exploits and the technical nature of the bug limit its immediate threat level. Organizations using affected hardware or custom Linux builds incorporating the bcm_sf2 driver should be aware of potential stability issues and plan timely patching to avoid service interruptions.
Mitigation Recommendations
1. Apply the official Linux kernel patches that replace devm_mdiobus_alloc() with manual allocation and freeing of the MDIO bus in the bcm_sf2 driver as soon as they are available in your kernel distribution. 2. For organizations maintaining custom or embedded Linux kernels, backport the fix from the relevant commit to ensure the bcm_sf2 driver handles MDIO bus resources correctly. 3. Test kernel updates in staging environments to verify that device shutdown sequences complete without panics or crashes. 4. Monitor system logs for kernel panics or device removal errors related to the bcm_sf2 driver or DSA subsystem to detect potential exploitation or instability. 5. Where possible, schedule maintenance windows to reboot or shut down affected systems safely after patching to prevent unexpected downtime. 6. Engage with hardware vendors to confirm whether their devices use the bcm_sf2 driver and request updated firmware or kernel versions if applicable. 7. Implement robust backup and recovery procedures to mitigate the impact of unexpected system crashes caused by this vulnerability.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-07-16T11:38:08.900Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982ec4522896dcbe6268
Added to database: 5/21/2025, 9:09:02 AM
Last enriched: 6/30/2025, 10:10:23 PM
Last updated: 8/7/2025, 6:55:08 PM
Views: 10
Related Threats
CVE-2025-41242: Vulnerability in VMware Spring Framework
MediumCVE-2025-47206: CWE-787 in QNAP Systems Inc. File Station 5
HighCVE-2025-5296: CWE-59 Improper Link Resolution Before File Access ('Link Following') in Schneider Electric SESU
HighCVE-2025-6625: CWE-20 Improper Input Validation in Schneider Electric Modicon M340
HighCVE-2025-57703: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in Delta Electronics DIAEnergie
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.