CVE-2024-26771

What it actually does

Missing null pointer validation after devm_kasprintf allocation inside edma_probe allows a subsequent dereference of a NULL pointer when memory allocation fails.

Why it matters to the business

Kernel panic or driver initialization failure on systems using TI EDMA DMA hardware can produce unexpected reboots or loss of DMA functionality during boot or module load.

How an attack unfolds

An attacker able to induce memory pressure or trigger device probe (via module load, hotplug, or system boot) causes the allocation to fail; the unchecked pointer is later dereferenced, resulting in an oops or panic.

How to fix it

Update the Linux kernel to a version containing commit c432094aa7c9970f2fa10d2305d550d3810657ce or later; rebuild and deploy the updated kernel image on all affected hosts.

How to confirm the fix worked

Verify the running kernel source contains commit c432094aa7c9970f2fa10d2305d550d3810657ce; inspect edma_probe for the added NULL check after devm_kasprintf calls; confirm no NULL-dereference oops occurs under memory pressure during probe.

Typical attack path

1. Induce low-memory conditions on the target system
2. Trigger edma_probe (module insertion, device enumeration, or boot)
3. devm_kasprintf returns NULL
4. Kernel dereferences the unchecked pointer
5. System panics or driver aborts

How to detect it

Search kernel ring buffer and syslog for edma_probe stack traces containing NULL pointer dereference or oops around devm_kasprintf; correlate with low-memory events or recent module loads.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the TI EDMA driver
• Monitor kernel logs for edma-related oops or NULL pointer dereference events
• Apply the fix during the next scheduled maintenance window if immediate reboot is not feasible