Vulnerability · Published Jul 16, 2024 · Assigned by Linux

CVE-2022-48818net: dsa: mv88e6xxx: don't use devres for mdiobus

Medium 5.5

In plain English

A medium-severity security flaw in Linux from Linux. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.3% (higher than 20% of all known vulnerabilities). Fixed versions are available - upgrade the affected package.

Severity (CVSS NVD)5.5Medium
Exploit odds (30 days)0.3%top 79.9% of all CVEs
Exploited in the wildNo reportsCISA SSVC: none
Attack toolingNoneno public tooling known

Official description

In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: 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 mv88e6xxx is an MDIO 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 Marvell switch driver on shutdown. systemd-shutdown[1]: Powering off. mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down fsl-mc dpbp.9: Removing from iommu group 7 fsl-mc dpbp.8: Removing from iommu group 7 ------------[ cut here ]------------ kernel BUG at drivers/net/phy/mdio_bus.c:677! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc : mdiobus_free+0x44/0x50 lr : devm_mdiobus_free+0x10/0x20 Call trace: mdiobus_free+0x44/0x50 devm_mdiobus_free+0x10/0x20 devres_release_all+0xa0/0x100 __device_release_driver+0x190/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x4c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 kernel_power_off+0x34/0x6c __do_sys_reboot+0x15c/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c 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 Marvell driver already has a good structure for mdiobus removal, so just plug in mdiobus_free and get rid of devres.

Affected packages & fixed versions

EcosystemPackageFixed inAdvisory
Debian:12linux5.16.10-1DEBIAN-CVE-2022-48818
Debian:13linux5.16.10-1DEBIAN-CVE-2022-48818
Debian:14linux5.16.10-1DEBIAN-CVE-2022-48818
Ubuntu:22.04:LTSlinux-allwinner-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-aws-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-aws-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-azure-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-azure-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-azure-fde-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-azure-fde-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-gcp-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-gcp-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-hwe-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-hwe-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-hwe-6.5no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-intel-iot-realtimeno fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-lowlatency-hwe-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-lowlatency-hwe-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-lowlatency-hwe-6.5no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-nvidia-6.2no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-oem-5.17no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-oem-6.0no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-oem-6.1no fix listedUBUNTU-CVE-2022-48818
Ubuntu:24.04:LTSlinux-raspi-realtimeno fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-realtimeno fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-riscvno fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-riscv-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-riscv-6.5no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-starfive-5.19no fix listedUBUNTU-CVE-2022-48818
Ubuntu:22.04:LTSlinux-starfive-6.2no fix listedUBUNTU-CVE-2022-48818

Affected products (as reported)

VendorProductVersions
Linux Linux ac3a68d56651c3dad2c12c7afce065fe15267f44 – before 8ccebe77df6e0d88c72ba5e69cf1835927e53b6cac3a68d56651c3dad2c12c7afce065fe15267f44 – before 8b626d45127d6f5ada7d815b83cfdc09e8cb1394ac3a68d56651c3dad2c12c7afce065fe15267f44 – before 1b451c3994a2d322f8e55032c62c8b47b7d95900ac3a68d56651c3dad2c12c7afce065fe15267f44 – before f53a2ce893b2c7884ef94471f170839170a4eba0
Linux Linux 5.9

References