CVE-2022-50737 in Linux
Sumário
de VulDB • 30/05/2026
Based on the kernel log snippet provided, here is an analysis of the issue:
### 1. **Core Issue: Use-After-Free (UAF) or Invalid Memory Access** The key line is: ``` [ 162.494214] The buggy address belongs to the physical page:
[ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc
``` - **`refcount:0`**: The page has no references. This strongly suggests the memory has been freed. - **`mapcount:0`**: The page is not mapped into any process’s page tables. - **`mapping:0000000000000000`**: No address space mapping.
This indicates that the kernel is trying to access memory that has already been freed and potentially reused or unmapped. This is a classic **Use-After-Free (UAF)** bug.
### 2. **Triggering Context: `mount` System Call** The stack trace shows: ``` [ 162.485593] __x64_sys_mount+0xca/0x110
[ 162.486024] do_syscall_64+0x3b/0x90
``` - The crash occurs during a **`mount` system call** (`sys_mount`). - The `RAX` register holds `0xffffffffffffffda`, which is `-22` in signed 64-bit two’s complement. This is **`-EINVAL`** (Invalid argument). - However, the presence of KASAN (Kernel Address Sanitizer) output (`__kasan_check_write`) suggests this is a **KASAN-detected bug**, not just a simple `-EINVAL` return. The `-EINVAL` might be a red herring or a secondary effect; the primary issue is the invalid memory access.
### 3. **KASAN Detection** The line: ``` [ 162.484782] ? __kasan_check_write+0x14/0x20
``` confirms that **KASAN** (Kernel Address Sanitizer) caught a **write** to an invalid address. KASAN is enabled in this kernel, which is why the bug is detected and reported in detail.
### 4. **Register State Analysis** - **`RIP: 0033:0x7f9d374e948a`**: The instruction pointer is in user space (`0x7f...` is a typical user-space address). This is unusual for a kernel crash unless: - The crash occurred in a kernel module that was loaded at a high address, or - The stack trace is incomplete/misleading, or - The crash happened in a context where user-space code was executing (e.g., in a syscall handler that returned to user space, but the KASAN report is from a different context). However, the stack trace shows kernel functions (`__x64_sys_mount`, `do_syscall_64`), so the `RIP` might be pointing to the return address in user space after the syscall, or the crash happened during the syscall but the `RIP` is misleading. More likely, the crash occurred in kernel space, and the `RIP` shown is the user-space return address.
- **`RAX: ffffffffffffffda`**: As noted, this is `-22` (`-EINVAL`). This might be the return value of a function that failed, but the KASAN bug is separate.
### 5. **Conclusion** - **Bug Type**: Use-After-Free (UAF) detected by KASAN. - **Trigger**: A `mount` system call. - **Affected Memory**: A page with `refcount:0`, `mapcount:0`, and `mapping:0`, indicating it was freed. - **Severity**: High. This can lead to kernel crashes, data corruption, or security vulnerabilities.
### 6. **Recommendations** 1. **Check Kernel Logs**: Look for earlier logs that might indicate which object was freed. KASAN usually provides more details about the allocation and free stack traces. 2. **Review Mount Code**: Examine the kernel code related to `sys_mount` and any filesystem-specific mount handlers. Look for cases where memory is freed but still referenced. 3. **Enable More KASAN
If you want to get the best quality for vulnerability data then you always have to consider VulDB.