CVE-2021-47436: usb: musb: dsps: Fix the probe error path
In the Linux kernel, the following vulnerability has been resolved:
usb: musb: dsps: Fix the probe error path
Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.
While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.
My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
->enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.
Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability flaw in a USB controller driver. On some embedded boards, an error during driver startup can leave a stale device object behind, leading to a kernel crash during boot. The clearest reported impact is availability loss on BeagleBone Black Wireless with a v5.10.70 stable kernel backport.
Executive priority
Treat as a targeted availability risk for affected embedded Linux fleets, not a broad enterprise emergency. Prioritize devices where a boot crash would interrupt operations, remote management, or field recovery.
Technical view
The musb_dsps probe error path did not unregister a platform device created by dsps_create_musb_pdev() when dsps_setup_optional_vbus_irq() failed. A reported -EPROBE_DEFER path left the device registered, and later USB Ethernet gadget use triggered a NULL pointer dereference crash.
Likely exposure
Exposure appears concentrated in Linux systems using the MUSB DSPS USB controller path, especially embedded boards and vendor kernels with the affected backport pattern. General servers are unlikely to be exposed unless they include this driver and hardware path.
Exploitation context
The bundle does not show active exploitation, public weaponization, or KEV listing. The documented scenario is a boot-time kernel crash caused by driver probe error handling on specific hardware and kernel conditions.
Researcher notes
Evidence is specific and limited: the report names a NULL pointer dereference on BeagleBone Black Wireless with v5.10.70 stable behavior. No CVSS, CWE, or exploitability details are provided in the bundle, so scope should be validated against deployed kernel trees.
Mitigation direction
Apply a kernel update containing the referenced musb_dsps error-path fix.
Check board vendor or BSP advisories for patched kernel packages.
Prioritize embedded devices that depend on USB gadget or USB Ethernet during boot.
If no patch is available, follow vendor guidance for temporary operational workarounds.
Validation and detection
Inventory kernels and hardware using the MUSB DSPS driver path.
Compare deployed kernel versions against vendor fixes and referenced stable commits.
Review boot logs for musb_dsps probe failures or -EPROBE_DEFER behavior.
Regression-test USB gadget and USB Ethernet boot behavior after patching.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2021-47436 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.