CVE-2026-31583: media: em28xx: fix use-after-free in em28xx_v4l2_open()
In the Linux kernel, the following vulnerability has been resolved:
media: em28xx: fix use-after-free in em28xxv4l2open()
em28xxv4l2open() reads dev->v4l2 without holding dev->lock, creating a race with em28xxv4l2init()'s error path and em28xxv4l2fini(), both of which free the em28xxv4l2 struct and set dev->v4l2 to NULL under dev->lock.
This race leads to two issues: - use-after-free in v4l2fhinit() when accessing vdev->ctrlhandler, since the videodevice is embedded in the freed em28xxv4l2 struct. - NULL pointer dereference in em28xxresolutionset() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.
Fix this by moving the mutexlock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify em28xx_v4l2_open() to call mutex_lock() before reading dev->v4l2, and add a NULL check for dev->v4l2 while holding the lock to prevent use-after-free and NULL pointer dereference.
Linux kernel media em28xx driver (em28xx_v4l2_open) mutex_lock placement and dev->v4l2 NULL-check = lock before reading dev->v4l2; check dev->v4l2 for NULL while holding the lock
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's media em28xx driver are affected. The listed software also includes Microsoft azl3 kernel 6.6.134.1-2.
What does an attacker need to exploit the flaw?
The CVSS vector indicates local access, low privileges, and no user interaction are required. Exploitation depends on triggering a race while the em28xx V4L2 device is being opened and its V4L2 state is being initialized, torn down, or encountering initialization failure.
What failures can this race cause?
It can cause a use-after-free when V4L2 file-handle initialization accesses a video device embedded in freed memory. It can also cause a NULL pointer dereference when resolution handling accesses V4L2 state after it has been cleared.
How can teams determine whether they need the fix?
Review whether the running kernel includes and uses the media em28xx driver, then check whether its source contains the locking change that reads dev->v4l2 only after acquiring dev->lock and verifies it is non-NULL. The provided stable-kernel references identify commits containing the resolution.