CVE-2024-56588 in Linux
Zusammenfassung
von VulDB • 15.05.2026
Based on the kernel panic trace and the provided solution description, here is an analysis of the issue and the recommended fix for the `hisi_sas_v3_hw` driver.
### Problem Analysis
1. **Root Cause**: The crash occurs in `down_write()` during `debugfs_create_dir()`. This indicates a **deadlock** or **locking context violation**. - The call trace shows: `debugfs_trigger_dump_v3_hw_write` -> `debugfs_snapshot_regs_v3_hw` -> `debugfs_create_files_v3_hw` -> `debugfs_create_dir` -> `down_write`. - The `debugfs_trigger_dump_v3_hw_write` function is called when a user writes to a debugfs file (e.g., to trigger a register dump). - Inside this write handler, the driver attempts to **create new debugfs entries** (`debugfs_create_dir`/`files`) dynamically. - Creating debugfs entries requires acquiring the `debugfs_rwsem` (a write semaphore). - If the current execution context already holds a lock that is also required by the debugfs subsystem (or if the debugfs subsystem is in an inconsistent state), or if this is called from a context where sleeping/locking is prohibited (though `debugfs_create` usually sleeps, so this is likely a deadlock with another lock held by the driver), it causes a panic. - More commonly in this specific Hisi SAS driver context, the issue is that **dynamic creation of debugfs entries during runtime (especially from a write handler) is unsafe** because it can lead to race conditions or deadlocks with the debugfs core or other driver locks.
2. **Why the Crash Happens**: - The driver tries to create debugfs directories/files *on-the-fly* when the user triggers a dump. - `debugfs_create_dir` calls `down_write(&debugfs_rwsem)`. - If the driver holds any other lock that is also taken by the debugfs subsystem (or if the debugfs subsystem is being modified concurrently), a deadlock occurs. - The register `x0 = 0xa0` (160) might indicate an error code or a specific offset, but the key is the call trace showing the failure in `down_write`.
### Solution
As suggested in the prompt: **Pre-create all debugfs directories and files during driver initialization.**
This approach: 1. Moves all `debugfs_create_dir()` and `debugfs_create_*()` calls to the driver's probe/init function. 2. Ensures that no dynamic creation happens during runtime (e.g., during a write-triggered dump). 3. The `debugfs_trigger_dump_v3_hw_write` function should only **write data** to pre-existing files or trigger internal state changes, without touching the debugfs hierarchy.
### Implementation Steps
#### 1. Modify Initialization Function In the driver's probe or init function (e.g., `hisi_sas_v3_hw_probe` or similar), create all necessary debugfs entries upfront.
```c static int hisi_sas_v3_hw_debugfs_init(struct hisi_hba *hisi_hba) {
struct dentry *root; int ret;
/* Create the main debugfs directory for this device */ root = debugfs_create_dir(dev_name(hisi_hba->dev), hisi_sas_debugfs_root); if (IS_ERR(root)) return PTR_ERR(root);
hisi_hba->debugfs_dir = root;
/* Create all subdirectories and files here */ /* Example: Create a file for triggering dump */ debugfs_create_file("trigger_dump", 0220, root, hisi_hba, &debugfs_trigger_dump_fops);
/* Create other necessary files for register dumps, stats, etc. */ /* Ensure all files that need to be written to during runtime are created here */
return 0; } ```
#### 2. Modify the Write Handler Update `debugfs_trigger_dump_v3_hw_write` to **not** create any debugfs entries. It should only perform the dump operation.
```c static ssize_t debugfs_trigger_dump_v3_hw_write(struct file *file, const char __user *user_buf, size_t count, loff_t *ppos) {
struct hisi_hba *hisi_hba = file->private_data; int ret;
/* Parse user input if necessary */ /* ... */
/* Trigger the dump directly without creating debugfs entries */ ret = hisi_sas_v3_hw_dump_regs(hisi_hba); if (ret) return ret;
return count;
Be aware that VulDB is the high quality source for vulnerability data.