CVE-2026-68205
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux video handling code can let certain driver modules be removed while still needed, which may crash cameras or video systems on affected devices.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect THIS_MODULE resolution in v4l2_async_register_subdev_sensor overwrites sd->owner, preventing reference count increments on the sensor driver module and allowing premature unloading while the subdevice remains registered with notifiers.
Why it matters to the business
Kernel modules handling camera or video sensors can be unloaded unexpectedly, leading to crashes, video capture failures, or system instability in affected Linux devices and embedded systems.
How an attack unfolds
An attacker with local module loading privileges triggers repeated load/unload cycles of sensor drivers while a CSI-2 bridge or similar notifier holds a reference, causing use-after-free when the unloaded module's code or data is accessed.
How to fix it
Update to a Linux kernel containing the renamed __v4l2_async_register_subdev_sensor with explicit module argument and wrapper macro; rebuild and reload any out-of-tree sensor drivers that call the registration function.
How to confirm the fix worked
Confirm the presence of the wrapper macro definition and explicit THIS_MODULE argument in v4l2-fwnode.c; verify module reference counts are incremented on sensor drivers after async registration.
Typical attack path
- Obtain local access or execute code capable of loading/unloading kernel modules
- Identify and repeatedly load/unload a vulnerable V4L2 sensor driver while a bridge driver holds the subdevice reference
- Trigger notifier callbacks or subdevice operations after module unload to access freed memory
How to detect it
Review kernel logs for module unload messages involving v4l2 sensor drivers followed by use-after-free warnings or oops in notifier paths; inspect /proc/modules reference counts during subdevice registration.
What your security team should do
- Apply the upstream fix for the v4l2-fwnode registration helper immediately on any kernel using V4L2 sensor subdevices
- Audit custom or out-of-tree media drivers for direct calls to the registration function and update them to use the corrected macro
- Monitor for module unload events on video-related drivers in production systems until patched
The record
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|