In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
In the Linux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don t use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don t use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don tlet devres free a still-registered bus.
| linux | | https://git.kernel.org/linus/0d120dfb5d67edc5bcd1804e167dba2b30809afd | https://git.kernel.org/linus/ac3a68d56651c3dad2c12c7afce065fe15267f44 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
IntheLinux kernel, the following vulnerability has been resolved:net: dsa: lantiq_gswip: don't use devres for mdiobusAs 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 wasnot previously unregistered.The GSWIP switch is a platform device, so the initial set of constraintsthat 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 linkbetween the switch and the DSA master, and device_links_unbind_consumers()will unbind the GSWIP switch driver on shutdown.So the same treatment must be applied to all DSA switch drivers, whichis: either use devres for both the mdiobus allocation and registration,or don't use devres at all.The gswip driver has the code structure in place for orderly mdiobusremoval, so just replace devm_mdiobus_alloc() with the non-devresvariant, and add manual free where necessary, to ensure that we don'tlet devres free a still-registered bus.The Linux kernel CVE team has assigned CVE-2022-48812 to this issue.
