CVE-2021-47436

What it actually does

Missing platform_device_unregister() call in the dsps probe error path allows a partially initialized platform device to remain registered, leading to NULL pointer dereference when the USB gadget driver later accesses it.

Why it matters to the business

Systems using affected TI USB controllers (such as BeagleBone Black Wireless) may experience kernel crashes during boot or USB initialization, causing downtime and requiring manual intervention; the issue is rare outside specific embedded hardware and carries low exploitation likelihood.

How an attack unfolds

An attacker with local access or the ability to influence USB probe timing triggers the dsps_setup_optional_vbus_irq() error path (returning -EPROBE_DEFER); the leaked platform device is then dereferenced by the USB Ethernet gadget driver, producing a crash that can be leveraged for denial of service or, under controlled conditions, memory corruption primitives.

How to fix it

Update the Linux kernel to a version containing commit 7d2a07b769330c34b4deabeed939325c77a7ec2f or later; rebuild and deploy the fixed kernel image on all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit 7d2a07b769330c34b4deabeed939325c77a7ec2f via git log or kernel version string; attempt to reproduce the original probe error path in a test environment and confirm no crash occurs.

Typical attack path

1. Trigger USB MUSB DSPS probe on affected hardware
2. Force dsps_setup_optional_vbus_irq() to fail on first attempt
3. Allow USB gadget driver to reference the unregistered platform device
4. Trigger NULL pointer dereference during device access

How to detect it

Inspect kernel logs for musb_dsps probe failures followed by NULL pointer dereference stack traces involving platform_device or USB gadget drivers; search dmesg and syslog for references to dsps_create_musb_pdev and EPROBE_DEFER around USB initialization.

What your security team should do

• Prioritize patching embedded Linux devices using TI MUSB controllers within standard maintenance windows
• Monitor kernel logs for musb_dsps and platform_device registration errors during boot
• Test updated kernels on representative hardware before broad deployment