Cloudanix VulnDB

CVE-2026-90405

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in a camera driver for certain chips can make the computer crash or leak memory when the driver starts up.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Improper error handling in the stm32 dcmi driver's probe function causes direct returns after dma_request_chan without cleanup, incorrect variable checks leading to memory leaks, and dma_release_channel calls on unassigned pointers resulting in NULL pointer dereference.

Why it matters to the business

Systems using affected Linux kernel versions with STM32 DCMI media hardware may experience kernel instability, crashes, or resource exhaustion during driver initialization, potentially disrupting media capture functionality and requiring reboots.

How an attack unfolds

An attacker with local access triggers error paths in the dcmi probe routine by forcing DMA allocation failures or manipulating device registration, leading to NULL dereference or leaks that can be chained for memory corruption and privilege escalation.

How to fix it

Update the Linux kernel to a version containing the fix for the dcmi probe error handling; rebuild and deploy the stm32-dcmi driver with corrected cleanup logic using the local chan variable and proper mdma_chan checks.

How to confirm the fix worked

Confirm the patch is applied by inspecting the probe function for use of the chan variable in release calls and correct mdma_chan checks; test driver load under allocation failure conditions to verify no crashes or leaks occur.

Typical attack path

  1. Load or trigger initialization of the stm32-dcmi kernel module on vulnerable hardware
  2. Force dma_request_chan failure for the tx channel
  3. Execute error path that dereferences uninitialized pointers or skips cleanup
  4. Exploit resulting NULL dereference or leaked resources for memory corruption

How to detect it

Review kernel logs for dcmi probe errors, dma channel allocation failures, or NULL pointer dereferences during module initialization; examine call traces involving dma_request_chan and dma_release_channel in the stm32-dcmi path.

What your security team should do

  • Prioritize kernel updates for any systems exposing STM32 DCMI hardware
  • Monitor for driver probe failures in system logs
  • Restrict unprivileged module loading until patched

The record

In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: fix some error handling bugs in probe() There are a few issues here: 1) After we assign: chan = dma_request_chan(&pdev->dev, "tx"); Then the error paths need to clean up before returning. The first error path does a direct return. 2) The error paths check "dcmi->mdma_chan" but that is not assigned until later so it results in memory leaks. Test "mdma_chan" instead. 3) The error handling calls dma_release_channel(dcmi->dma_chan) before "dcmi->dma_chan" has been assigned which leads to a NULL pointer dereference. Use the "chan" variable instead. I also moved the call to dma_release_channel() after the call to dma_release_channel() so it mirrors the allocation code better.

Affected packages

Ecosystem Package Introduced Fixed