CVE-2024-53065 in Linux
Riassunto
di VulDB • 15/06/2026
Based on the kernel oops log provided, here is an analysis of the crash and potential causes.
### **1. Key Observations** - **Architecture**: ARM64 (`arm64+`) - **Kernel Version**: `6.12.0-rc5mm-unstable-arm64+` (This is a **development/unstable** kernel, likely from the `mm` tree, meaning it is prone to regressions). - **Taint**: `[W]=WARN` – The kernel was already in a warned state before the crash.
- **Crash Location**: `__kmem_cache_create_args+0xb8/0x3b0` - **Process**: `swapper/0` (PID 1, the idle task, meaning this happens during early boot or initialization). - **Hardware**: QEMU Virtual Machine.
### **2. Analysis of the Crash** The crash occurs in `__kmem_cache_create_args`, which is part of the **SLAB/SLUB memory allocator** subsystem. This function is responsible for creating new kmem caches (used for object allocation).
#### **Likely Cause: Null Pointer Dereference or Invalid Pointer** Looking at the register dump: - `x0` to `x2` are all `0x0`. - `x19` is `fdff0000c163d6c0` (likely a pointer to a cache name or structure). - `x20` is `fbff0000c1674410` (likely a pointer to a cache structure). - `x21` and `x22` are also pointers.
The fact that `x0` (the first argument) is `0` suggests that a pointer passed to the function is **NULL**. In `__kmem_cache_create_args`, if a required parameter (like `name` or `size`) is NULL, it may trigger a warning or crash depending on the code path.
However, the more critical clue is the **Taint: [W]=WARN**. This indicates that a `WARN_ON()` or similar check failed earlier, possibly corrupting state or leading to an invalid call.
### **3. Common Causes in `__kmem_cache_create_args`** 1. **NULL Name Pointer**: The cache name passed to `kmem_cache_create` is NULL. 2. **Invalid Size**: The size of the cache object is 0 or unaligned. 3. **Corrupted Cache Structure**: A previous cache creation failed, leaving a corrupted structure that is later dereferenced. 4. **Race Condition**: In early boot, multiple CPUs might be initializing caches concurrently, leading to a race in the `mm` subsystem.
### **4. Recommended Debugging Steps**
#### **A. Check for Recent Commits in the `mm` Tree** Since this is an `rc5mm-unstable` kernel, the bug is likely a recent regression. Check the git log for recent changes to: - `mm/slab_common.c` - `mm/slub.c` - `mm/slab.c`
Look for commits related to: - `kmem_cache_create` - `__kmem_cache_create_args` - Cache initialization during boot.
#### **B. Enable More Verbose Logging** Add these kernel boot parameters to get more context: ```bash loglevel=8 slub_debug=FZP slub_min_objects=1 ``` - `loglevel=8` will print all kernel messages, including warnings before the crash. - `slub_debug=FZP` enables debugging for SLUB (Free, Zero, Poison), which might catch the issue earlier.
#### **C. Check the `WARN` Message** The log is truncated. Look for the **WARN_ON** message that preceded this oops. It will likely be a few lines above the `Call trace:` section. It will tell you exactly which condition failed.
#### **D. Bisect the Kernel** If you have access to the git history, perform a **git bisect** between the last known good kernel and this `rc5mm-unstable` kernel to identify the commit that introduced the bug.
### **5. Potential Fix (If You Are a Developer)** If you are able to modify the kernel, check the code in `mm/slab_common.c` around `__kmem_cache_create_args`. Ensure that: 1. The `name` parameter is not NULL before proceeding. 2. The `size` parameter is valid and aligned. 3. Any pointers passed to helper functions are properly initialized.
Example check: ```c if (!name) {
WARN_ON(1); return NULL; } ```
###
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.