CVE-2021-47647 in Linux
요약
\~에 의해 VulDB • 2026. 07. 01.
Based on the kernel panic log provided, here is an analysis of the crash and potential solutions.
### **Summary** The system crashed during early boot while initializing the **Clock Controller (CC)** for a Qualcomm IPQ8074 SoC (`gcc_ipq8074_probe`). The crash occurred in `clk_core_get_parent_by_index`, which is called by `__clk_register`. This suggests that when registering a clock, the driver tried to look up its parent clock using an index, but something went wrong (likely invalid data or NULL pointer).
---
### **Detailed Analysis**
#### 1. **Crash Location & Call Trace** - **Function:** `clk_core_get_parent_by_index+0x68/0xec` - **Caller:** `__clk_register+0x1d8/0x820` - **Context:** The kernel is registering a clock via the device tree (`of_platform_populate`). Specifically, it’s probing the Global Clock Control (GCC) driver for IPQ8074.
#### 2. **Register State** ```text x5 : 061b3c403a0a0017 <- Likely a pointer or index value x4 : 0000000000000000 <- NULL? Or zeroed out x3 : 0000000000000001 <- Index = 1? x2 : 0000a00000000000 <- Likely a base address or flag x1 : 0000000000000001 <- Another index/flag x0 : ffffff8000309700 <- Pointer to clk_core structure? ``` - `x5` contains a non-zero value (`061b...`) which might be an invalid pointer or corrupted data. - The crash happens when trying to access memory using this value, leading to an **Invalid Instruction** or **Page Fault**.
#### 3. **Root Cause Hypotheses** The most likely causes are:
##### A. **Device Tree (DTS) Error** - The device tree may specify a parent clock for one of the clocks in `gcc_ipq8074` using an invalid index or referencing a non-existent clock provider. - Example: If a clock’s `.parent_names` array is misconfigured, or if `clocks = <&clk X>` references an incorrect cell count/index.
##### B. **Driver Bug / Missing Clock Definition** - The `gcc_ipq8074.c` driver might be registering a clock with an invalid parent index (e.g., trying to get parent at index 1 when only 0 exists). - This can happen if the `.num_parents` field is incorrect or if the parent array pointer is NULL.
##### C. **Memory Corruption / Early Boot Issue** - Less likely, but possible: Memory corruption before this point could have corrupted clock data structures.
---
### **Troubleshooting Steps**
#### 1. **Check Device Tree (DTS)** Look for the `gcc` node in your IPQ8074 device tree (`ipq8074.dtsi` or board-specific `.dts`). Check: - Are all clock parents correctly referenced? - Is there a mismatch between the number of parent clocks defined and what is being accessed?
Example snippet to check: ```dts gcc: clock-controller@100000 {
compatible = "qcom,gcc-ipq8074"; reg = <0x100000 0x2c>; clocks = <&xo_board>, ...; // Ensure these are valid }; ```
#### 2. **Enable Debug Logging** Recompile the kernel with more verbose clock debugging: - Enable `CONFIG_COMMON_CLK_DEBUG` in `.config`. - Add earlyprintk or console=ttyMSM0,115200n8 to bootargs to see if any warnings precede the crash.
#### 3. **Check Driver Code** In `drivers/clk/qcom/gcc-ipq8074.c` (or similar), look for: - Any clock registration that uses `.parent_data` or `.num_parents`. - Ensure no clock is trying to access a parent index out of bounds.
#### 4. **Test with Minimal DTS** Try booting with a minimal device tree that only initializes essential clocks (e.g., `xo_board`, `gcc`) and see if the crash persists. This helps isolate whether a specific peripheral
If you want to get best quality of vulnerability data, you may have to visit VulDB.