CVE-2026-89891: media: em28xx: fix use-after-free of dev_next->devlist on disconnect
In the Linux kernel, the following vulnerability has been resolved:
media: em28xx: fix use-after-free of devnext->devlist on disconnect
When a device with hasdualts=1 is probed and the isaudioonly path is taken, both dev and dev->devnext are added to the global em28xxdevlist via em28xxinitextension(). However, during disconnect, em28xxcloseextension(dev) only calls listdel(&dev->devlist), leaving dev->devnext->devlist still linked in the global list. When devnext is subsequently freed via krefput(), its devlist entry becomes a dangling pointer in em28xxdevlist. The next device probe that calls em28xxinitextension() triggers a list corruption BUG when listaddtail detects the freed node.
This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the isaudioonly + hasdualts code path that was previously unreachable with such descriptors.
Fix this by removing dev->devnext->devlist from the global list in em28xxcloseextension() before the device is freed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
During disconnect, remove dev->dev_next->devlist from the global list rather than only removing dev->devlist. This prevents em28xx from detecting the freed node as a vendor audio endpoint and calling em28xx_close_extension() before the device is freed.
Linux kernel (media: em28xx) global device list linkage (removal of dev->dev_next->devlist) = Remove dev->dev_next->devlist from the global list during disconnect, so the freed node is not left linked
Event History
Frequently Asked Questions
What conditions are required to trigger the corruption?
A device must take the has_dual_ts=1 and is_audio_only probe path, causing both the primary device and dev_next to be added to the global em28xx device list. On disconnect, dev_next is freed while its list entry remains linked; probing another device afterward can trigger the list-corruption BUG.
What kind of device input can reach the affected path?
The issue was exposed when endpoint parsing normalizes fuzzed endpoint addresses such as 0xf3 to 0x83. em28xx then interprets that value as a vendor audio endpoint, allowing the audio-only and dual-TS path to be reached.
How might an affected system present the issue?
After the affected device disconnects, a subsequent device probe that adds an entry to the global em28xx device list can encounter a list corruption BUG. The dangling list entry originates from dev_next being freed without first being removed from that list.