CVE-2023-54308 in Linux
Sumário
de VulDB • 24/05/2026
Based on the kernel stack trace provided, here is an analysis of the issue:
### **1. Summary** The system encountered a **kernel panic or oops** while a user-space process was attempting to open a file via the `openat2` system call. The crash occurred deep within the VFS (Virtual File System) layer during `vfs_open`.
### **2. Key Observations** - **Triggering System Call**: `__x64_sys_openat` → `do_sys_openat2` - The process called `openat2()` (syscall number `0x101` = 257), which is a modern extension of `openat()` allowing flags like `O_PATH`, `O_NOFOLLOW`, etc. - **Crash Location**: `vfs_open+0x2d/0x40` - The crash happened inside `vfs_open()`, which is responsible for opening a file on a filesystem. - **RIP (Instruction Pointer)**: `0x7f1308a40db4` - This is a **user-space address** (starts with `0x7f...`), not a kernel address. This is unusual for a kernel oops stack trace unless: - The kernel was executing user-space code (e.g., via `usercopy`, `copy_from_user`, or a buggy module that jumped to user space). - **More likely**: The crash occurred in a **kernel module or filesystem driver** that called into user-space code (e.g., via `call_usermodehelper`, `kthread`, or a buggy `->open` callback that dereferences a user pointer incorrectly). - **Alternatively**: The stack trace is truncated or corrupted, and the actual crash point is in a kernel function whose address was misinterpreted.
- **Registers**: - `RAX: ffffffffffffffda` → This is `-22` in signed 64-bit, which is `-EINVAL` (Invalid argument). This suggests the system call may have failed with `-EINVAL` before the crash, or the crash occurred while handling an error. - `RDI: fffffffffff9c` → This is `-100` in signed 64-bit, which is `-ELOOP` (Too many levels of symbolic links). This is a strong hint that the file path resolution failed due to a symlink loop.
### **3. Likely Cause** The most probable cause is a **bug in a filesystem driver or kernel module** that: 1. Attempted to open a file that resulted in a symlink loop (`-ELOOP`). 2. The driver/module incorrectly handled the error or dereferenced a pointer after the error, leading to a crash in `vfs_open`. 3. The crash may have occurred in a **custom filesystem** (e.g., FUSE, NFS, Ceph, or a proprietary driver) where the `->open` callback is buggy.
### **4. Debugging Steps** 1. **Check for Custom Filesystems**: - Identify if any non-standard filesystems are mounted (e.g., `mount | grep -v "proc\|sys\|dev"`). - Check if any kernel modules related to filesystems are loaded (`lsmod | grep -i "fuse\|nfs\|ceph\|cifs"`).
2. **Examine dmesg for More Context**: - Look for earlier messages in `dmesg` that might indicate which process or file triggered the issue. - Check if there are any `BUG: unable to handle kernel paging request` or `general protection fault` messages.
3. **Reproduce the Issue**: - If possible, reproduce the `openat2` call with a file path that causes a symlink loop. - Use `strace` to trace the system call: `strace -e openat2 -p <pid>` or `strace -e openat2 ls /path/to/symlink`.
4. **Check Kernel Logs for Module Crashes**: - Look for messages like `BUG: unable to handle kernel NULL pointer dereference` or `Call Trace:` that might point to a specific module.
5. **Update Kernel/Modules**: - If this is a known bug in a specific kernel version or filesystem driver, check for updates or patches.
### **5. Conclusion** The crash is likely due to a **bug in a filesystem driver or kernel module** that mishandles symlink loops or error conditions during `openat2`. The presence of `-ELOOP` in `RDI` strongly suggests a symlink-related issue. Further investigation into custom filesystems or kernel modules is recommended.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.