CVE-2024-27399 in Linux
要約
〜によって VulDB • 2026年06月13日
Based on the kernel oops log provided, here is an analysis of the crash:
### 1. **Crash Type** - **Exception**: `Page Fault` (`asm_exc_page_fault`, `do_user_addr_fault`, `page_fault_oops`). - **Context**: Kernel mode (`CS: 0010`, `CR0: 0000000080050033` indicates kernel space). - **Taint**: Likely tainted (see `add_taint` in call trace), possibly due to a bug or external module.
### 2. **Faulting Address** - **CR2**: `0x0000000000000158` - This is the virtual address that caused the page fault. - It is **not** a NULL pointer (`0x0`), but it is very close to it. - `0x158` is a small offset, suggesting the code tried to dereference a pointer that was either `NULL` or pointed to an unmapped page near the beginning of the address space.
### 3. **Register Analysis** - **RAX**: `0x0000000000000000` - RAX is zero. This is often the value being dereferenced or used as an index. - **RBP**: `0x0000000000000158` - **Critical Clue**: The Base Pointer (`RBP`) is exactly equal to the faulting address (`CR2`). - In x86-64, `RBP` is often used as a frame pointer. However, in this context, it strongly suggests that the code was trying to access memory at an offset from a base pointer that was `NULL` or invalid. - Specifically, if the code did something like `ptr->field` where `ptr` was `NULL`, and `field` is at offset `0x158`, then `CR2` would be `0x158`. - Alternatively, if `RBP` was set to `0x158` (perhaps from a previous calculation or a corrupted stack), and then dereferenced, it would cause this fault. But given `RAX=0`, it's more likely that `RAX` (or another register) was used as a base, and `0x158` was the offset.
### 4. **Call Trace Analysis** The call trace shows the following sequence: 1. `asm_exc_page_fault` → Hardware exception entry. 2. `exc_page_fault` → Exception handler. 3. `do_user_addr_fault` → Handles page faults. Note: This function is typically for user-space faults, but it can be called in kernel mode if the fault occurs in a context that allows user-space-like access (e.g., `copy_from_user`, `get_user`, or a bug in kernel code that mimics user access). 4. `kernelmode_fixup_or_oops` → Determines if the fault can be fixed or if it's an oops. 5. `page_fault_oops` → Generates the oops. 6. `__die_body` → Finalizes the die.
**Key Functions in the Trace:** - `mutex_lock+0x68/0xc0`, `mutex_lock+0x75/0xc0`, `mutex_lock+0x88/0xc0`: - The crash occurred while holding or attempting to acquire a mutex. - Multiple `mutex_lock` entries suggest nested locking or a recursive lock attempt, but the fault itself is not directly in `mutex_lock` (which is at `0x68/0xc0`, etc., and the fault is at `0x158` offset from `RBP`). - `l2cap_chan_timeo`: - **This is the most important clue.** The last function in the truncated call trace is `l2cap_chan_timeo`. - `l2cap_chan_timeo` is the timeout handler for L2CAP channels in Bluetooth (RFCOMM/SCO/L2CAP). - This suggests the crash happened in the Bluetooth subsystem, specifically during a channel timeout.
### 5. **Root Cause Hypothesis** - **Subsystem**: Bluetooth (L2CAP). - **Trigger**: A channel timeout (`l2cap_chan_timeo`). - **Bug**: The code in `l2cap_chan_timeo` (or a function it calls) attempted to dereference a pointer that was `NULL` or invalid. - The offset `0x158`
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.