---

Introduction

A new Linux kernel vulnerability—CVE-2024-56747—has been recently patched. If you use the qedi SCSI driver, understanding this bug and its fix is important for system reliability and security. Here, we’ll break down what caused the issue, how the code fix works, and what you can do.

This article is *exclusive* and written in straightforward American English, so even if you’re new to kernel code, you’ll follow along!

The Vulnerability

Component Affected:
drivers/scsi/qedi/ (specifically, the qedi_alloc_and_init_sb() function)

Type of Bug:
Memory leak during error handling—DMA-mapped memory was not released if the function failed.

Short Explanation:
When the qedi_alloc_and_init_sb() function failed at a certain step, the code didn’t clean up some memory it had reserved. Over time, enough failures could crash the system, and it may open the door to denial-of-service scenarios.

If sb_init fails, there was no cleanup for the previously allocated sb_virt memory.

Result:
Memory would leak—these ghost allocations would never get cleaned up.

The Original Code (Vulnerable Section)

sb_info->sb_virt = dma_alloc_coherent(&qedi->pdev->dev,
                                      sb_size,
                                      &sb_info->sb_phys,
                                      GFP_KERNEL);
if (!sb_info->sb_virt)
    return -ENOMEM;

rc = qedi_ops->common->sb_init(&qedi->cdev, ...);
if (rc)
    return rc; // <-- Memory leak here! sb_virt isn't freed

Problem:
If sb_init fails (that is, returns a non-zero error code), we leave without freeing sb_virt.

The Patch: How It Was Fixed

The solution is classic in error handling: *on failure, undo what you did*. The patch adds a memory release (dma_free_coherent()) right before returning on error.

Fixed Code

sb_info->sb_virt = dma_alloc_coherent(&qedi->pdev->dev,
                                      sb_size,
                                      &sb_info->sb_phys,
                                      GFP_KERNEL);
if (!sb_info->sb_virt)
    return -ENOMEM;

rc = qedi_ops->common->sb_init(&qedi->cdev, ...);
if (rc) {
    dma_free_coherent(&qedi->pdev->dev, sb_size,
                      sb_info->sb_virt, sb_info->sb_phys); // NEW LINE
    sb_info->sb_virt = NULL;
    return rc;
}

Patch Commit on kernel.org:

scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()

Kernel Mailing List (LKML) Discussion:

Patchwork: SCSI qedi memory leak fix

SCSI QEDI Driver Source:

qedi_main.c on Elixir.bootlin

Exploit Details

Is this an RCE or Privilege Escalation bug?
No—it does not allow code execution or privilege escalation directly. It *does* enable a Denial-of-Service vector: if an attacker can reliably trigger driver error conditions, they could provoke repeated leaks, exhausting kernel memory and destabilizing the system.

Trigger Allocations:

Cause repeated SCSI “Slow Path” allocation failures (possibly by malicious SCSI commands or using malformed devices).

System may hang, crash, or require reboot, especially on resource-constrained hosts.

Proof of Concept:
Here’s a *simulated* short-circuit for educational purposes.

// Pseudo: not meant for real attack
for (int i = ; i < ATTEMPTS; i++) {
    int rc = qedi_alloc_and_init_sb(...);
    if (rc) {
        // It leaked before the patch!
    }
}

Who is affected?

- Users with QLogic FastLinQ 4xxxx/8xxxx 25/50/100Gb Ethernet Adapters using iSCSI with QEDI.

Conclusion

CVE-2024-56747 is a textbook example of why robust error handling matters in kernel code. This memory leak would fly under the radar unless you hit (rare) error conditions, but could destabilize your server if left unchecked.

For more details, always check the upstream kernel commits and security advisories.

Stay patched!

Links for Further Reading:
- Linux Kernel SCSI Subsystem
- Secure DMA Memory Management
- How Kernel Memory Leaks Become DoS

Timeline

Published on: 12/29/2024 12:15:08 UTC
Last modified on: 01/20/2025 06:27:18 UTC