CVE-2022-49846 in Linux
Resumen
por VulDB • 2026-05-20
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 Filesystem (`fs/udf/`). * **Trigger:** A `creat()` system call (creating a new file). * **Specific Error:** The kernel accessed memory at an address that belongs to a `kmalloc-256` slab object, but the access was **150 bytes inside** a 256-byte region. This suggests an off-by-one or larger offset error in pointer arithmetic or buffer handling within `udf_find_entry`.
---
### 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 long. * The access happened at `base + 150`. * **Why is this bad?** If the object was already freed, this is a **Use-After-Free**. If the object was still allocated but the code tried to write/read beyond its intended logical bounds, it's an **Out-of-Bounds** access. Given KASAN's typical behavior, this is likely a UAF where the freed memory was reused, or a buffer overflow in a small allocation.
#### B. Call Trace Analysis The crash occurred during file creation: 1. `__x64_sys_creat` → User called `creat()`. 2. `path_openat` → VFS layer starts opening the path. 3. `udf_lookup` → UDF filesystem's lookup function 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 some UDF structure (likely a directory entry buffer or inode cache).
#### C. Root Cause Hypothesis The bug is in `fs/udf/namei.c` in the function `udf_find_entry`.
Common causes in UDF lookup: 1. **Incorrect Length Calculation:** UDF uses variable-length descriptors. If the code miscalculates the length of a directory entry or the offset to the next entry, it may read/write past the end of the allocated buffer. 2. **Use-After-Free:** A pointer to a directory entry or inode was cached or stored in a structure, but the underlying memory was freed (e.g., due to a race condition or improper cleanup in a previous operation). When `udf_find_entry` dereferences this stale pointer, it accesses freed memory. 3. **Integer Overflow:** If an offset is calculated as `base + length`, and `length` is corrupted or too large, it could point to an invalid location within the slab.
#### D. Page Owner Info ``` 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 at boot time (`pid 1`, `swapper/0`). This is typical for slab caches. * `free_ts 0` means the page has **never been freed** since boot. This is interesting. It suggests the bug might be an **Out-of-Bounds access within an active allocation** rather than a classic Use-After-Free where the memory was reused. However, KASAN marks it as "bad access," which can also happen if you access memory beyond the allocated size of an active object.
---
### 3. Recommended Actions
#### For Developers/Kernel Maintainers 1. **Inspect `udf_find_entry` in `fs/udf/namei.c`:** * Look for any pointer arithmetic involving `len`, `offset`, or `entry_len`. * Check if there are bounds checks before accessing `entry->len` or similar fields. * Verify that the buffer passed to `udf_find_entry` is large
If you want to get the best quality for vulnerability data then you always have to consider VulDB.