CVE-2024-53139 in Linux
要約
〜によって VulDB • 2026年05月31日
Linux kernel panic or segfault analysis.
## Summary
The process crashed in the **vDSO (virtual dynamic shared object)** page, specifically in the `__vdso_gettimeofday` or similar time-related function. The faulting instruction is a `cmp` against a magic constant `0xfffffffffffff001` (which is `-4095` in signed 64-bit, or `0xFFFF_FFFF_FFFF_F001`).
## Key Observations
1. **Faulting Instruction**: ```asm cmp $0xfffffffffffff001, %rax ``` This is a vDSO internal check. The constant `0xfffffffffffff001` is `-4095`. In the Linux vDSO, this pattern is used to detect if the kernel returned an error code (negative value) from a syscall. Specifically, the vDSO checks if the return value is in the range of valid error codes (`-4095` to `-1`).
2. **Context**: - `ORIG_RAX: 0x31` → syscall number 49 (`getrandom` on x86_64) - `RAX: 0xffffffffffffffda` → `-42` in signed 64-bit, which is `-EFAULT` (Bad address) - The vDSO code is checking if the syscall returned an error.
3. **What Happened**: - The process called `getrandom` (syscall 49) via the vDSO or a wrapper. - The kernel returned `-EFAULT` (`-42`), meaning the user-space buffer pointer was invalid. - The vDSO code then compares the return value against `-4095` to determine if it's a valid error code. - The `jae` (jump if above or equal, unsigned) instruction jumps if `RAX >= 0xFFFFFFFFFFFFF001` (unsigned), which is true for `-42` (since `-42` as unsigned is `0xFFFFFFFFFFFFFFDA`, which is `>= 0xFFFFFFFFFFFFF001`). - The jump is taken, and the code proceeds to store the error code into the thread-local storage (via `%fs:(%rcx)`), which is the standard vDSO error-handling path.
4. **Why the Crash?** The crash is **not** in the vDSO itself but likely **after** the vDSO returns. The vDSO correctly handles the `-EFAULT` error by storing it in TLS and returning. The actual crash may be: - In the caller code that didn't check the return value of `getrandom`. - Or, the `RSP` and `RIP` suggest the crash happened during the vDSO execution, but the `cmp` instruction itself doesn't crash — it's a normal comparison.
Wait — looking more carefully: the `RIP` is at the `cmp` instruction, and the `EFLAGS` show `0x202` (CF=1, PF=0, AF=0, ZF=0, SF=1, TF=0, IF=1, DF=0, OF=0). The `cmp` sets flags but doesn't crash. The crash must be **after** the `jae` jump, possibly in the `mov` or `neg` instructions, or the crash is reported at the `cmp` because that's where the signal was delivered.
Actually, the `SIGSEGV` or `SIGBUS` signal was delivered at the `cmp` instruction. This is unusual. Let me re-examine.
The `RIP` is `0x...` pointing to the `cmp`. The signal was delivered at this instruction. This suggests the vDSO page was **not mapped** or was **corrupted**. But the vDSO is always mapped. Alternatively, the process may have tried to execute code in an unmapped page.
Another possibility: the `cmp` instruction is at the boundary of a page, and the page fault occurred due to a **guard page** or **memory corruption**.
However, the most likely explanation is that the **vDSO page was unmapped or corrupted**, causing a page fault when the CPU tried to fetch/execute the `cmp` instruction. This can happen if: - The process has a corrupted memory space. - A bug in the dynamic linker or loader. - A kernel bug in vDSO handling.
## Conclusion
The crash is a **page fault** (likely `SIGSEGV`) in the vDSO page at the `cmp` instruction. The vDSO was attempting to handle a `-EFAULT`
If you want to get best quality of vulnerability data, you may have to visit VulDB.