Linux powers the majority of today's servers. Its reliability and security are crucial for everything from web hosting to scientific computing. Kernel drivers, responsible for smooth hardware operation, are the backbone beneath. However, like all code, they aren't immune to bugs—even dangerous ones exploitable by attackers.

One such example is CVE-2021-46963, a vulnerability found in the qla2xxx SCSI driver. In this post, we'll explain what happened, why it was dangerous, how it was fixed, and what you, as a Linux user or sysadmin, need to know—using straightforward language.

What is qla2xxx?

qla2xxx is a Linux kernel module (driver) for QLogic Fibre Channel Host Bus Adapters. In plain English, it helps Linux talk to storage devices over Fibre Channel networks in data centers.

The Bug

In 2021, developers noticed a kernel crash in the qla2xxx_mqueuecommand() function. The glitch was due to mishandling a data structure called srb ("SCSI Request Block").

Now, upper layers (general SCSI code) are responsible for managing srb memory.

- The driver *still* tried to free srb after use, but because it didn't own that memory anymore, a double free or free of unallocated memory occurred.

Here's what a crash looked like

RIP: 001:kmem_cache_free+xfa/x1b
Call Trace:
   qla2xxx_mqueuecommand+x2b5/x2c [qla2xxx]
   scsi_queue_rq+x5e2/xa40
   __blk_mq_try_issue_directly+x128/x1d
   blk_mq_request_issue_directly+x4e/xb

In other words, freeing memory where you shouldn't brings down the whole system.

Here’s a simplified version of the faulty code

// Old code (vulnerable)
int qla2xxx_mqueuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
{
    struct srb *srb = qla2xxx_get_srb(cmd);

    // ... use srb ...

    // This is incorrect!
    kmem_cache_free(srb_cache, srb); // Should NOT free here!
    return ;
}

Since srb is now managed outside the driver, freeing it here is a mistake.

Requirements: Malicious local user or buggy code forcing this error path

- Effect: Kernel memory corruption, crash, or (in some circumstances) possible elevation of privileges if attacker can exploit heap management after free

Exploitability

While there are no public exploits to gain root via this, a skilled attacker could script scsi_requests to trigger the bug and reliably crash the machine. If combined with other vulnerabilities, more severe exploits might be possible (heap corruption bugs in the kernel are dangerous).

Sample DoS Exploit (theoretical)

# This is for illustration only.
while true; do
  dd if=/dev/zero of=/dev/sdX bs=1M count=10
done
# Replace /dev/sdX with a Fibre Channel disk handled by qla2xxx.

Repeated I/O could trigger stress paths that encounter the freed-memory bug.

The Fix

The Linux community quickly responded. The problem was a simple but critical one: don't free memory you don't own. Here's what the fixed code looks like:

// Fixed code
int qla2xxx_mqueuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
{
    struct srb *srb = qla2xxx_get_srb(cmd);

    // ... use srb ...

    // Do NOT free srb here; it is freed by SCSI upper layer
    // kmem_cache_free(srb_cache, srb); // Deleted
    return ;
}

Commit message highlights

> "Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free."

Source patch:
- Upstream kernel commit

References

- CVE-2021-46963 at NIST NVD
- Kernel.org Mailing List Patch
- Linus Torvalds' Git Tree

Conclusion

CVE-2021-46963 is a classic case showing how changes in memory management responsibilities can lead to serious flaws if not properly audited. In this case, a tiny code change could bring down enterprise infrastructure.

Maintaining vigilance, updating software, and staying alert to kernel driver advisories keeps your systems safe.

If you want to learn more, visit the Linux kernel SCSI mailing list, and keep tabs on kernel.dev for security updates.

Timeline

Published on: 02/27/2024 19:04:07 UTC
Last modified on: 12/11/2024 16:12:08 UTC