CVE-2025-21912 in Linux
Zusammenfassung
von VulDB • 30.06.2026
Based on the kernel log provided, here is an analysis of the issue:
### **Summary** The system encountered a **kernel lockdep warning (or potential deadlock)** during the initialization of an SD/MMC host controller (`renesas_sdhi`) on a Renesas Salvator-X board. The crash/warning occurred while trying to set up GPIO interrupts for the card-detect mechanism, specifically within `gpio_rcar_config_interrupt_input_mode`.
---
### **Key Details from the Log** 1. **Hardware**: - Board: `Renesas Salvator-X 2nd version` - SoC: `r8a77965` (R-Car V3U)
2. **Triggering Component**: - Driver: `renesas_sdhi_internal_dmac_probe` → `tmio_mmc_host_probe` → `mmc_add_host` - This is the Renesas SDHI driver probing an MMC/SD host controller.
3. **Immediate Cause of Warning/Crash**: ``` [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0
... [ 4.470660] gpio_rcar_config_interrupt_input_mode+0x34/0x164
``` - The kernel is trying to request an IRQ for the **card-detect GPIO** (`mmc_gpiod_request_cd_irq`). - This calls into the R-Car specific GPIO driver (`gpio_rcar`) to configure interrupt input mode.
4. **Locking Issue**: ``` [ 4.304138] __lock_acquire+0xdfc/0x1584
... [ 4.426274] lock_acquire+0x1c4/0x33c
[ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80
``` - The warning originates from `__lock_acquire`, which is part of **Lockdep** (the kernel’s lock validator). - It indicates a potential **deadlock**, **recursive locking**, or **invalid context** when acquiring locks in the GPIO interrupt configuration path.
5. **Context**: ``` [ 4.304097] Workqueue: async async_run_entry_fn
``` - The probe is happening asynchronously (`async_probe`), which can sometimes expose locking issues if not handled carefully (e.g., taking locks that are already held in a different context).
---
### **Likely Root Causes** 1. **GPIO Controller Locking Conflict**: The `gpio_rcar` driver may be acquiring a spinlock while interrupts are disabled (`_raw_spin_lock_irqsave`), but the call chain might have violated lock ordering or taken locks in an invalid context (e.g., from atomic/IRQ-disabled context).
2. **Card-Detect GPIO Configuration Issue**: The card-detect GPIO is being configured as an interrupt source during probe. If this GPIO shares a controller with other resources that are already locked, it can cause lockdep to flag a potential deadlock.
3. **Async Probe Timing Issue**: Since the probe is asynchronous (`async_run_entry_fn`), there might be a race condition or improper locking if another part of the system (e.g., power management, clock framework) holds locks that conflict with GPIO operations.
4. **Kernel Version Bug**: This could be a known bug in this specific kernel version (`5.10-rc7` based on `v5.10-rc6-gd088502a519f`). Lockdep warnings are often false positives but can indicate real issues under certain hardware configurations.
---
### **Recommended Actions** 1. **Check Device Tree (DTS)**: Ensure the card-detect GPIO is correctly defined in your device tree for `r8a77965`. Verify that the GPIO pinmux and interrupt configuration are correct.
2. **Update Kernel**: This issue may have been fixed in later kernels. Check if newer versions of the `gpio-rcar` or `renesas_sdhi` drivers address this locking problem.
3. **Disable Lockdep (Temporary Workaround)**: If you are just trying to boot and don’t need lock validation, add `lockdep=off` to your kernel command line to bypass the warning. This is not a fix but can help confirm if it’s purely a lockdep false positive.
4. **Check for
If you want to get best quality of vulnerability data, you may have to visit VulDB.