CVE-2024-56747

What it actually does

Failure to release DMA coherent memory (sb_virt) when qed_sb_init fails inside qedi_alloc_and_init_sb, leaving the allocation live and causing a memory leak on the error path.

Why it matters to the business

Systems using the qedi driver can experience gradual memory exhaustion under repeated error conditions, leading to reduced stability, performance degradation, and potential denial of service on Linux hosts; kernel prevalence increases exposure across many distributions.

How an attack unfolds

An attacker with local access or the ability to induce qed_sb_init failures (via resource pressure or crafted conditions) repeatedly triggers the leaky path, accumulating unfreed DMA memory until the system becomes unstable; listed threat actors in Linux kernel campaigns could leverage similar resource-exhaustion patterns.

How to fix it

Update the Linux kernel to commit 4e48e5b26b3edc0e1dd329201ffc924a7a1f9337 or later; Ubuntu 14.04 users apply 1.8.8-1ubuntu3.3 and Ubuntu 16.04 users apply 1.9.3-2ubuntu1.1 (or newer) packages containing the fix.

How to confirm the fix worked

Verify the running kernel contains commit 4e48e5b26b3edc0e1dd329201ffc924a7a1f9337; confirm qedi_alloc_and_init_sb now calls dma_free_coherent on sb_init failure via source inspection or kpatch/dkms validation.

Typical attack path

1. Obtain local execution or ability to trigger qedi sb allocation paths
2. Force repeated failures in qed_sb_init (resource starvation or error injection)
3. Accumulate leaked DMA pages without triggering immediate crash
4. Drive system toward memory pressure and instability

How to detect it

Review kernel logs for repeated qedi sb allocation failures; correlate with rising DMA or slab memory usage without corresponding process growth; no widespread in-the-wild exploitation artifacts reported for this specific leak.

What your security team should do

• Apply the referenced kernel commit or Ubuntu package updates immediately given the 652-day exposure window
• Prioritize hosts running qedi or qed drivers for patching
• Monitor memory usage on storage-initiator systems for unexplained growth
• Test updated kernels in staging before broad deployment