CVE-2026-93071

What it actually does

Memory leak of v4l2_async_notifier structures allocated by v4l2_async_nf_add_fwnode_remote() when v4l2_async_nf_cleanup() is omitted on error and remove paths in the bcm2835-unicam driver.

Why it matters to the business

Gradual kernel memory exhaustion on systems repeatedly loading/unloading the driver or hitting error paths, leading to eventual instability or forced reboots in long-running camera-enabled devices.

How an attack unfolds

An attacker with local access triggers repeated module load/error/unload cycles (e.g., via rmmod after failed probe or deliberate error injection) to accumulate unreferenced kernel allocations without triggering immediate denial of service.

How to fix it

Apply the upstream fix that adds the missing v4l2_async_nf_cleanup() calls in error and remove paths; rebuild and deploy the patched kernel.

How to confirm the fix worked

Reproduce the original kmemleak scenario after rmmod and confirm no unreferenced objects remain; inspect driver source for explicit cleanup invocations on all exit paths.

Typical attack path

1. Obtain local access or script module manipulation
2. Load bcm2835-unicam module
3. Force error path or rmmod to skip cleanup
4. Repeat to accumulate leaked objects until memory pressure occurs

How to detect it

Scan kmemleak reports and kernel logs for unreferenced objects allocated via __v4l2_async_nf_add_fwnode after bcm2835-unicam rmmod events.

• unreferenced object.*bcm2835-unicam
• backtrace.*__v4l2_async_nf_add_fwnode_remote
• comm "modprobe".*kmemleak_alloc

What your security team should do

• Prioritize kernel update on all systems using bcm2835-unicam
• Enable kmemleak or similar leak detectors in test environments
• Monitor for repeated module load/unload patterns in production logs