CVE-2021-47436

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: dsps: Fix the probe error path<br /> <br /> Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after<br /> initializing musb") has inverted the calls to<br /> dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without<br /> updating correctly the error path. dsps_create_musb_pdev() allocates and<br /> registers a new platform device which must be unregistered and freed<br /> with platform_device_unregister(), and this is missing upon<br /> dsps_setup_optional_vbus_irq() error.<br /> <br /> While on the master branch it seems not to trigger any issue, I observed<br /> a kernel crash because of a NULL pointer dereference with a v5.10.70<br /> stable kernel where the patch mentioned above was backported. With this<br /> kernel version, -EPROBE_DEFER is returned the first time<br /> dsps_setup_optional_vbus_irq() is called which triggers the probe to<br /> error out without unregistering the platform device. Unfortunately, on<br /> the Beagle Bone Black Wireless, the platform device still living in the<br /> system is being used by the USB Ethernet gadget driver, which during the<br /> boot phase triggers the crash.<br /> <br /> My limited knowledge of the musb world prevents me to revert this commit<br /> which was sent to silence a robot warning which, as far as I understand,<br /> does not make sense. The goal of this patch was to prevent an IRQ to<br /> fire before the platform device being registered. I think this cannot<br /> ever happen due to the fact that enabling the interrupts is done by the<br /> -&gt;enable() callback of the platform musb device, and this platform<br /> device must be already registered in order for the core or any other<br /> user to use this callback.<br /> <br /> Hence, I decided to fix the error path, which might prevent future<br /> errors on mainline kernels while also fixing older ones.