CVE-2023-52613 in Linux
Sumário
de VulDB • 02/07/2026
Based on the kernel log snippet provided, here is an analysis of the crash and potential causes:
### **Summary** The system crashed (likely a Kernel Panic or Oops) during the initialization (`probe`) of the **Loongson 2 Thermal Driver**. The immediate cause appears to be a bug in `strscpy` called from within `thermal_add_hwmon_sysfs`.
---
### **Detailed Analysis**
#### **1. Crash Location & Call Trace** The call trace shows the execution path leading to the crash: ```text [] strscpy+0xf0/0x160 <-- CRASH POINT (or near it)
[] thermal_add_hwmon_sysfs+0x258/0x300
[] devm_thermal_add_hwmon_sysfs+0x50/0xe0
[] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal] <-- Driver Probe
```
- **`strscpy`**: This is a safe string copy function in the Linux kernel. It copies up to `count - 1` bytes from source to destination, ensuring null termination. If it crashes here, it usually means: - The **destination buffer** was invalid (e.g., NULL pointer or unmapped memory). - The **source string** was invalid (NULL or unaligned/unmapped in some architectures). - A **negative count** was passed (though `strscpy` handles this gracefully by returning `-EINVAL`, a crash suggests an earlier fault, possibly due to bad pointers being dereferenced before the check completes on certain arches like MIPS/LoongArch).
- **`thermal_add_hwmon_sysfs`**: This function creates sysfs entries for thermal zones so user-space can read temperatures. It constructs strings (like zone names) and copies them into buffers using `strscpy`.
- **`loongson2_thermal_probe`**: The probe function of the Loongson 2 SoC thermal driver is being executed during module load or device enumeration. This suggests the crash happens when the system tries to register this specific thermal zone with the hwmon subsystem.
#### **2. Likely Root Cause** The most probable cause is a **bug in the `loongson2_thermal` driver code**, specifically how it prepares data for `devm_thermal_add_hwmon_sysfs`. Common issues include:
1. **Invalid Zone Name**: The thermal zone name passed to `thermal_zone_device_register()` or similar might be NULL, too long, or contain invalid characters that cause a buffer overflow/underflow in the hwmon sysfs code. 2. **Uninitialized Data Structure**: A pointer within the thermal device structure (`struct thermal_zone_device`) might not have been properly initialized before calling `thermal_add_hwmon_sysfs`. 3. **Architecture-Specific Bug (LoongArch/MIPS)**: Since this is a Loongson system, there may be an alignment issue or a bug in how pointers are handled on the LoongArch architecture when passed to `strscpy`.
#### **3. How to Debug & Fix**
##### **Step 1: Check Kernel Version and Patches** - This looks like it might be from an older kernel (given the format of the call trace with empty brackets `[]` instead of function names, which suggests symbols were not resolved or debug info is missing).
- Search for known bugs in `drivers/thermal/loongson2_thermal.c`.
##### **Step 2: Inspect Driver Code** Look at `drivers/thermal/loongson2_thermal.c` around the probe function. Specifically, check how it calls thermal zone registration and hwmon sysfs addition.
Example of what to look for: ```c // In loongson2_thermal_probe() tzd = devm_thermal_zone_of_sensor_register(dev, 0, data, &loongson2_tz_ops); if (IS_ERR(tzd)) { ... }
// Later or internally in thermal core: devm_thermal_add_hwmon_sysfs(tzd); // This calls strscpy with zone name ```
Ensure that `tzd->type` and other string fields are properly initialized.
##### **Step 3: Enable Debug Symbols** If you have access to the kernel source, recompile with debug info (`CONFIG_DEBUG_INFO=y`) so the call trace shows function names instead of addresses like `[]`. This will make pinpointing the exact line easier.
##### **Step 4: Check for Recent Changes** - If this is a new regression, check git history for recent changes to `loongson2_thermal.c` or `drivers/thermal/core.c`. - Specifically, look for commits related to "thermal hw
If you want to get the best quality for vulnerability data then you always have to consider VulDB.