{"uuid": "ad051a66-3a3b-4be9-9117-7e9f7eef85af", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2022-48817", "type": "seen", "source": "https://t.me/cvedetector/949", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2022-48817 - \"Cisco DSA MDIO Bus Registration Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2022-48817 \nPublished : July 16, 2024, 12:15 p.m. | 43\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: dsa: ar9331: register the mdiobus under devres  \n  \nAs explained in commits:  \n74b6d7d13307 (\"net: dsa: realtek: register the MDIO bus under devres\")  \n5135e96a3dd2 (\"net: dsa: don't allocate the slave_mii_bus using devres\")  \n  \nmdiobus_free() will panic when called from devm_mdiobus_free() remove on  \n->shutdown) do not apply. But there is one more which applies here.  \n  \nIf the DSA master itself is on a bus that calls ->remove from ->shutdown  \n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link  \nbetween the switch and the DSA master, and device_links_unbind_consumers()  \nwill unbind the ar9331 switch driver on shutdown.  \n  \nSo the same treatment must be applied to all DSA switch drivers, which  \nis: either use devres for both the mdiobus allocation and registration,  \nor don't use devres at all.  \n  \nThe ar9331 driver doesn't have a complex code structure for mdiobus  \nremoval, so just replace of_mdiobus_register with the devres variant in  \norder to be all-devres and ensure that we don't free a still-registered  \nbus. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"16 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T15:26:38.000000Z"}