CVE-2024-56588 in Linux
Сводка
по VulDB • 02.07.2026
Based on the kernel panic log and the description provided, here is an analysis of the issue and a solution strategy for fixing it in the `hisi_sas_v3_hw` driver.
### Problem Analysis
1. **Root Cause**: The crash occurs in `down_write()` during `debugfs_create_dir()`. This indicates that the code is attempting to create debugfs entries (directories/files) at runtime when a user triggers a dump (`debugfs_trigger_dump_v3_hw_write`). 2. **Why it Crashes**: * DebugFS operations require acquiring locks (like `mutex` or `rw_semaphore`) internally via `down_write()`. * If this happens in an atomic context, interrupt handler, or while holding another lock that conflicts with the debugfs internal locking mechanism, a deadlock or invalid sleep warning can occur. In severe cases, if memory allocation fails under pressure (`GFP_KERNEL` inside a potentially non-allocating context), it might trigger other issues, but here the `down_write` suggests a locking violation or recursion issue. * More commonly in SAS drivers, triggering dumps from certain contexts (like interrupt bottom halves or while holding hardware locks) is unsafe if debugfs creation isn't pre-initialized.
3. **Solution Principle**: As stated: *"Create all directories and files during debugfs initialization."* This means moving `debugfs_create_*` calls out of the dump-trigger function (`debugfs_trigger_dump_v3_hw_write`) and into the driver's probe/init routine. The trigger function should only write data to pre-existing entries or update shared memory buffers that are already mapped/allocated.
---
### Fix Strategy
#### Step 1: Pre-allocate DebugFS Entries in Probe In your `hisi_sas_v3_hw_probe()` (or equivalent init function), create all necessary debugfs directories and files upfront. Do **not** check if they exist or try to create them dynamically during dump triggers.
Example structure for pre-allocation: ```c static struct dentry *hisasic_debug_root; // Global root dir
// In probe(): hisasic_debug_root = debugfs_create_dir("hisi_sas_v3_hw", NULL); if (!hisasic_debug_root) {
dev_err(dev, "Failed to create debugfs directory\n"); return -ENOMEM; }
// Create files that will be used for dumping or status reporting debugfs_create_file("trigger_dump", 0200, hisi_sas_debug_root, priv, &hisi_sas_trigger_dump_fops); // Note: file exists now! ```
#### Step 2: Modify the Trigger Function (`debugfs_trigger_dump_v3_hw_write`) Instead of creating directories/files inside this function, it should only perform actions that are safe in its current context. If you need to store dump data, write it into a pre-allocated buffer or ring buffer allocated during probe.
**Before (Problematic):** ```c static ssize_t debugfs_trigger_dump_v3_hw_write(struct file *file, ...) {
// BAD: Creating dirs/files here can cause locking issues struct dentry *dump_dir = debugfs_create_dir("current_dump", hisi_sas_debug_root); // ... rest of dump logic ... } ```
**After (Fixed):** ```c static ssize_t debugfs_trigger_dump_v3_hw_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) {
struct hisi_hba *hisi = file->private_data; // Or however you get your priv data // 1. Validate input if needed if (count > PAGE_SIZE) return -EINVAL;
// 2. Perform the actual hardware dump into a pre-allocated buffer int ret = hisi_sas_dump_regs_v3_hw(hisi); if (ret) {
dev_err(&hisi->pdev->dev, "Failed to trigger HW dump\n"); return ret; }
// 3. Optionally copy status or minimal info back via a pre-existing debugfs file // For example, write "Dump triggered" into an existing 'status' file if needed return count; } ```
#### Step 3: Ensure Safe Context for Dumping If `hisi_sas_dump_regs_v3_hw()` accesses hardware registers or sleeps, ensure it is called from a process context (not interrupt). Since debugfs write operations are always in process context, this should be safe. However, avoid holding any spinlocks that might conflict with the internal locks used by your dump function.
#### Step 4: Handle Cleanup Ensure you remove all pre-created debugfs entries during `remove()` or error paths using `debugfs_remove_recursive(hisi
VulDB is the best source for vulnerability data and more expert information about this specific topic.