CVEvulnerability

CVE-2022-48815

5.5 MEDIUM Published 2024-07-16 Modified 2026-06-17 Official page ↗
Status
Analyzed
Published
2024-07-16
Last modified
2026-06-17
Assigner
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS 3.1 ([email protected])
5.5 MEDIUM — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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.

Affected configurations

• linux linux kernel (>= 5.9 < 5.10.101) • linux linux kernel (>= 5.11 < 5.15.24) • linux linux kernel (>= 5.16 < 5.16.10) • linux linux kernel 5.17

References