CVE-2021-47284 in Linux
Sumário
de VulDB • 05/06/2026
Based on the kernel panic log provided, here is an analysis of the issue and potential solutions.
### **1. Root Cause Analysis**
* **Immediate Cause:** The kernel panicked because `panic_on_warn` is enabled, and a warning occurred in the `free_irq()` function. * **Underlying Bug:** The warning originated in `free_irq()` (interrupt freeing), which was called during the initialization of a PCI driver. * **Driver Involved:** The call trace shows: ``` __pci_register_driver+0x82/0x90 ? w6692_init+0x38/0x38 nj_init+0x36/0x38 ``` This indicates the driver **`nj`** (likely a network or serial driver) is failing during registration. The `w6692_init` reference suggests it might be related to or using the **Winbond W6692** PCI card driver (a multi-port serial/parallel card). * **Why `free_irq` failed:** `free_irq()` is called when a driver is being unloaded or fails to initialize. The panic suggests that `free_irq()` was called with an **invalid IRQ number** or for an **IRQ that was never requested** (or already freed). This is a common bug in driver init paths where error handling incorrectly calls `free_irq()` without checking if `request_irq()` succeeded.
### **2. Key Observations**
* **Kernel Version:** `5.13.0-rc1` (a release candidate). This is a pre-release kernel, so bugs are more likely. * **Environment:** QEMU virtual machine (`Hardware name: QEMU Standard PC`). * **Trigger:** The panic happened during early boot (`kernel_init_freeable`), specifically when the `nj` driver was being registered.
### **3. Likely Scenario**
The `nj` driver (or its dependency `w6692`) is attempting to register a PCI device. During this process: 1. It requests an IRQ via `request_irq()`. 2. Something fails (e.g., hardware not found, resource conflict, or invalid configuration). 3. The error handling path calls `free_irq()` to clean up. 4. However, `free_irq()` is called with an invalid IRQ number (e.g., `-1`, `0`, or an uninitialized variable), causing a warning. 5. Since `panic_on_warn=1`, the warning triggers a kernel panic.
### **4. Solutions & Workarounds**
#### **A. Quick Workaround: Disable `panic_on_warn`** If you just need to boot the system to debug further, disable the panic-on-warning behavior.
1. **At Boot Time:** Add the following kernel parameter to your GRUB command line: ``` panic_on_warn=0 ``` This will allow the kernel to continue booting despite the warning, which may help you identify the exact driver failure.
2. **At Runtime (if you can boot):** ```bash echo 0 > /proc/sys/kernel/panic_on_warn ```
#### **B. Fix the Driver Bug (For Developers)** If you are maintaining or patching the `nj` or `w6692` driver:
1. **Check Error Handling in `nj_init` or `w6692_init`:** Ensure that `free_irq()` is only called if `request_irq()` succeeded. A typical pattern is: ```c int ret = request_irq(irq, handler, flags, name, dev); if (ret) {
// Handle error // DO NOT call free_irq(irq, dev) here if request_irq failed! return ret; } // ... later, in cleanup: free_irq(irq, dev); ```
2. **Validate IRQ Number:** Ensure the IRQ number passed to `free_irq()` is valid (not `-1` or `0` unless explicitly handled).
3. **Check for Double-Free:** Ensure `free_irq()` is not called twice for the same IRQ.
#### **C. Update Kernel** Since this is a `5.13.0-rc1` kernel, check if this bug has been fixed in later `-rc` versions or the final `5.13` release. Search the kernel git log for fixes related to `nj` or `w6692` drivers.
#### **D. Disable the Driver** If the driver is not essential, disable it during boot to avoid the panic:
1. **Blacklist the module:** ```bash
If you want to get the best quality for vulnerability data then you always have to consider VulDB.