CVE-2026-23033: dmaengine: omap-dma: fix dma_pool resource leak in error paths
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: omap-dma: fix dma_pool resource leak in error paths
The dma_pool created by dma_pool_create() is not destroyed when
dma_async_device_register() or of_dma_controller_register() fails,
causing a resource leak in the probe error paths.
Add dma_pool_destroy() in both error paths to properly release the
allocated dma_pool resource.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel cleanup bug in the OMAP DMA driver. When driver initialization reaches specific failure paths, an allocated DMA memory pool is not released. The public record describes a resource leak, not data theft or remote code execution. Business urgency is mainly for systems that actually use this driver and track kernel maintenance closely.
Executive priority
Handle through normal kernel maintenance unless affected embedded or industrial systems are mission-critical. Escalate only if vendors confirm exposure in deployed products or systems show repeated driver initialization failures that could degrade reliability.
Technical view
The flaw is in dmaengine/omap-dma probe error handling. dma_pool_create() succeeds, then dma_async_device_register() or of_dma_controller_register() can fail; before the fix, those paths skipped dma_pool_destroy(), leaking the pool. Stable kernel commits add cleanup in both paths. No CVSS vector or CWE is provided in the bundle.
Likely exposure
Likely limited to Linux systems with the OMAP DMA driver present and relevant hardware or device-tree paths. Embedded and industrial Linux builds deserve attention. Generic servers and cloud workloads are less likely exposed unless they include and exercise this driver.
Exploitation context
The bundle does not show active exploitation, public exploit details, KEV listing, or a remote attack path. The condition appears tied to driver probe failure handling, so practical impact depends on whether an attacker can repeatedly trigger those initialization failures.
Researcher notes
Evidence is narrow: the CVE text only documents a dma_pool resource leak in two probe error paths. The affected-version data is inconsistent in the bundle and no CVSS is supplied. Validate against kernel commits and downstream vendor advisories before assigning operational severity.
Mitigation direction
Upgrade to a Linux stable kernel containing the referenced omap-dma cleanup fix.
Check distribution or device vendor advisories before backporting kernel patches manually.
For appliances, verify whether the OMAP DMA driver is enabled in shipped kernels.
Track the Siemens advisory for product-specific remediation if Siemens equipment is in scope.
Validation and detection
Inventory affected Linux kernel versions and downstream vendor kernel branches.
Check kernel configuration for the OMAP DMA driver or related platform support.
Confirm the relevant stable commit is present in the deployed kernel source package.
Review boot logs for repeated omap-dma probe failures on potentially affected devices.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23033 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
1ADP providers
9Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 31, 2026, 11:42 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.