CVE-2024-43871

What it actually does

Memory leak occurs when devm_free_percpu() is used to release percpu memory previously allocated via devm_alloc_percpu() because devres_destroy() is called instead of devres_release(), leaving allocated resources unreclaimed in the device resource tracking structures.

Why it matters to the business

Long-running systems experience gradual memory exhaustion that can degrade performance or trigger denial-of-service conditions in kernel drivers; low immediate urgency given the local attack vector and absence from KEV lists, though widespread Linux kernel and Android device deployments increase exposure.

How an attack unfolds

An attacker with local access loads a malicious or vulnerable kernel driver that repeatedly calls devm_alloc_percpu() followed by devm_free_percpu(); the incorrect devres_destroy() call leaves the percpu allocations tracked but unreleased, accumulating leaked memory until the system becomes unstable. Threat actor mentions of espionage and financial campaigns targeting Linux kernel resource issues provide context for potential targeted local exploitation.

How to fix it

Upgrade the Linux kernel to a version containing commit 700e8abd65b10792b2f179ce4e858f2ca2880f85; Android devices should apply the corresponding framework/base fixes listed for versions 9-12 released in November 2021.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or newer stable release; monitor percpu memory usage with slabinfo or kmemleak after exercising affected drivers to verify leaks are no longer present.

Typical attack path

1. Obtain local user or container access on a Linux system
2. Load or trigger a driver that uses devm_alloc_percpu() and devm_free_percpu()
3. Repeatedly exercise the allocation/free path to induce leaks
4. Observe kernel memory growth until resource exhaustion occurs

How to detect it

Review kernel logs for repeated calls to devm_free_percpu and devres functions; watch for unexplained growth in percpu or slab memory statistics; correlate with driver load events in systems exposed to the listed threat actor campaigns.

What your security team should do

• Apply the referenced kernel commit or latest stable branch immediately on affected systems
• Audit custom or third-party drivers for use of devm_alloc_percpu() paired with devm_free_percpu()
• Enable kernel memory leak detectors in test and production environments
• Monitor EPSS and threat intelligence feeds for any increase in local kernel exploitation