CVE-2022-49846 in Linux
要約
〜によって VulDB • 2026年06月06日
Based on the KASAN (Kernel Address Sanitizer) report provided, here is a detailed analysis of the bug, its root cause, and potential solutions.
### 1. Summary of the Bug * **Type:** **Use-After-Free (UAF)** or **Out-of-Bounds (OOB) Write/Read**. * **Severity:** Critical. This can lead to kernel panic, data corruption, or arbitrary code execution. * **Component:** UDF (Universal Disk Format) filesystem driver (`fs/udf/`). * **Trigger:** A `creat()` system call (creating a new file) on a UDF filesystem. * **Specific Error:** The kernel accessed memory at an address that belongs to a `kmalloc-256` slab object that has already been freed. The access was **150 bytes inside** a 256-byte region, which suggests an out-of-bounds access within the object or a use-after-free where the object was partially overwritten.
### 2. Detailed Analysis
#### A. The Buggy Address ``` The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900)
``` * The object is 256 bytes large. * The access happened at offset `150` within this object. * Since `150 < 256`, this is **not** a simple heap overflow beyond the object boundary. However, KASAN reports this as a "bad access" because the object has been **freed**. The memory is still mapped, but it is no longer valid for use. The fact that it's 150 bytes in suggests the code is trying to access a field or structure member that was valid when the object was allocated but is now stale or corrupted.
#### B. The Call Trace (Root Cause Location) The crash occurred during a file creation operation: 1. `__x64_sys_creat` -> User space called `creat()`. 2. `path_openat` -> VFS layer starts opening the path. 3. `udf_lookup` -> UDF filesystem's `lookup` operation is called to find/create the directory entry. 4. `udf_find_entry` -> **This is the critical function.** It searches for an existing entry or prepares to create a new one. 5. `kmalloc` -> Memory was allocated for a UDF-specific structure (likely `struct udf_fileident_loc` or similar, used to store file identification information).
**Key Insight:** The bug is in `udf_find_entry` (`fs/udf/namei.c:243`). The code allocated memory, used it, and then **freed it**, but later tried to access it again. Alternatively, it accessed memory beyond the intended bounds of the allocated structure.
#### C. The Freed Object's History ``` page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 ``` * The page was allocated by `swapper/0` (PID 1), which is normal for early kernel memory allocation. * The `free_ts 0` suggests the page was freed very early or the timestamp wasn't updated properly, but more importantly, the **KASAN shadow memory** has marked this region as freed.
### 3. Likely Root Cause in `udf_find_entry`
Looking at the Linux kernel source code for `fs/udf/namei.c` (specifically around `udf_find_entry`), the issue is likely one of the following:
#### Scenario 1: Use-After-Free in Error Path The function `udf_find_entry` allocates memory (e.g., for a buffer or a structure). If an error occurs (e.g., disk read error, invalid inode), the code might free the memory but then continue to use a pointer to it in a cleanup or error-handling path.
#### Scenario 2: Out-of-Bounds Access Due to Malformed UDF Image UDF is a complex filesystem. If the UDF image on disk is corrupted or non-standard, `udf_find_entry` might calculate an incorrect offset or size, leading to an access that is technically within the 256-byte slab but logically invalid (e.g., accessing a field that doesn
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.