CVE-2026-80650
NoneCVSS
—
EPSS
0.2%
Published
Aug 28, 2026
CISA due date
—
Cloudanix analysis
A camera driver inside the operating system kernel can crash or be abused when certain startup errors occur because it cleans up memory incorrectly.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Improper error handling in gc2235_probe allows gc2235_remove to free the device structure before subsequent calls, producing a use-after-free, plus unconditional cleanup of uninitialized objects and leaked media entity/control handler allocations on other failure paths.
Why it matters to the business
Systems using the affected camera driver may experience kernel instability, crashes, or local privilege escalation; the low EPSS and absence from KEV indicate limited current attacker interest, but the bug affects upstream Linux media subsystems.
How an attack unfolds
An attacker with local access loads or probes the gc2235 module under conditions that cause media_entity_pads_init or atomisp_register_i2c_module to fail, triggering the flawed error paths that reuse a freed structure or skip cleanup.
How to fix it
Apply the upstream fix that replaces erroneous gc2235_remove calls with explicit unwind labels performing only the initialized-resource cleanup in reverse order; rebuild and deploy the corrected kernel image.
How to confirm the fix worked
Confirm the patched probe function contains per-failure-point unwind labels instead of calling gc2235_remove; exercise the probe paths with injected failures and verify no UAF warnings appear under KASAN or similar instrumentation.
Typical attack path
- Obtain local code execution or shell on a system with the gc2235 driver present
- Trigger module probe or device registration while inducing failure in media_entity_pads_init or atomisp_register_i2c_module
- Cause the probe error handler to call gc2235_remove followed by further registration, dereferencing the freed dev structure
How to detect it
Review kernel logs for KASAN or slab-use-after-free reports referencing gc2235 or atomisp structures during module load; inspect dmesg for media_entity_pads_init or atomisp_register_i2c_module failure paths followed by later dereferences.
What your security team should do
- Prioritize kernel update on any system exposing the atomisp gc2235 driver to untrusted local users
- Monitor for new stable kernel releases containing the error-path correction
- If the driver is unnecessary, blacklist the module to reduce attack surface until patched
The record
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|