CVE-2026-68203
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel driver for virtual media devices had bugs in its error cleanup code that could leak resources if setup steps failed.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
A reference count leak in the vivid driver initialization error path when platform_device_register fails after device_initialize, plus an incorrect platform_driver_register call instead of unregister in the workqueue failure cleanup label.
Why it matters to the business
Resource leaks in the kernel on systems using the vivid virtual media driver may lead to gradual memory pressure or driver instability during media device initialization under failure conditions.
How an attack unfolds
An attacker would need local access to induce specific platform device registration or workqueue creation failures during vivid_init to trigger the reference leak or broken cleanup, though the bugs reside in error paths with low likelihood of direct malicious control.
How to fix it
Update to a Linux kernel version containing the fix that inserts platform_device_put before the free_output_strings jump and replaces the erroneous register call with platform_driver_unregister at the unreg_driver label.
How to confirm the fix worked
Inspect the vivid_init function in media/vivid/vivid-core.c for the presence of platform_device_put in the registration failure path and the correct unregister call in the cleanup label after applying kernel updates.
Typical attack path
- Gain local access on a Linux system using the vivid driver
- Trigger failure conditions during platform_device_register or subsequent workqueue creation in vivid_init
- Observe or exploit resulting reference leak or improper driver unregistration
How to detect it
Examine kernel logs and dmesg output around vivid driver load for repeated initialization failures or platform device errors; no widespread exploitation indicators exist given the nature of the bugs.
What your security team should do
- Prioritize kernel updates for systems exposing the vivid driver
- Review error paths in custom or out-of-tree media drivers for similar reference handling issues
- Test vivid-dependent workloads after patching to confirm stable initialization under failure scenarios
The record
In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|