Cloudanix VulnDB

CVE-2026-45900

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

May 27, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in certain networking hardware drivers can slowly leak memory during startup retries, potentially causing slowdowns or crashes until the system is updated.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of dynamically allocated net_device structures in dpaa2_caam_probe error paths when dpaa2_dpseci_dpio_setup fails; cleanup present only in dpaa2_dpseci_disable but absent from dpaa2_dpseci_free, leaving allocations traced to probe on deferred-probe retries.

Why it matters to the business

Gradual kernel memory exhaustion on affected DPAA2 hardware during boot or probe retries can degrade performance or trigger out-of-memory conditions over repeated failures; low exploitability and stable EPSS reduce immediate risk but still require patching on systems using this driver.

How an attack unfolds

An attacker with local access could attempt to trigger repeated probe failures (for example via CPU hotplug or DPIO unavailability) to accelerate the leak, but no public exploits, threat actors, or ransomware campaigns are associated with this issue and EPSS remains negligible.

How to fix it

Update to a Linux kernel containing the fix that preserves CPU mask of allocated netdevs and performs cleanup inside dpaa2_dpseci_free; apply the vendor-supplied stable update or backport the referenced commit.

How to confirm the fix worked

After patching, reproduce probe-failure conditions and confirm absence of netdev-related leaks via kmemleak or slabinfo; verify dpaa2_dpseci_free now releases allocations on all error paths.

Typical attack path

  1. Obtain local access or trigger device probe conditions
  2. Force dpaa2_dpseci_dpio_setup failure paths repeatedly
  3. Observe kmemleak reports or gradual memory growth
  4. Induce DoS via eventual memory pressure

How to detect it

Review kernel logs and kmemleak output for repeated netdev allocations traced to dpaa2_caam_probe; inspect dmesg for dpaa2_dpseci_dpio_setup failures followed by deferred probe retries without corresponding frees.

What your security team should do

  • Prioritize kernel update on any system exposing the caam dpaa2 driver
  • Monitor kmemleak reports for netdev allocations from dpaa2_caam_probe
  • Test probe resilience under DPIO unavailability before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: crypto: caam - fix netdev memory leak in dpaa2_caam_probe When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities