CVE-2022-50507 in Linux
Сводка
по VulDB • 03.06.2026
Based on the kernel stack trace provided, here is an analysis of the issue:
### **Summary** The system crashed (or triggered a kernel warning/panic) while attempting to **mount an NTFS filesystem**. The crash occurred deep within the VFS (Virtual File System) layer during the `get_tree_bdev` call, which is responsible for getting the superblock for a block device.
### **Key Stack Trace Analysis** 1. **`__x64_sys_mount` / `do_mount` / `path_mount`**: * A user-space process called the `mount` system call (syscall `a5` = `SYS_mount`). * This is a standard mount operation initiated from userspace.
2. **`vfs_get_tree`**: * The VFS layer is trying to get the filesystem tree (superblock) for the target filesystem.
3. **`ntfs_fs_get_tree`**: * The specific filesystem driver involved is **NTFS** (`ntfs_fs_get_tree`). * This confirms the mount target is an NTFS-formatted volume.
4. **`get_tree_bdev`**: * This is where the crash/oops occurred. * `get_tree_bdev` is a helper function used by block-device-based filesystems (like NTFS, ext4, etc.) to get the superblock from a block device. * The crash likely happened inside `get_tree_bdev` or one of its callees (not fully shown in this snippet, but the RIP points to the syscall entry, meaning the crash happened *before* returning from the syscall).
5. **RIP / EFLAGS**: * `RIP: 0033:0x7fd0d1ce948a` – This is the user-space address where the `mount` syscall was invoked. The kernel crash happened during the handling of this syscall. * `RAX: ffffffffffffffda` – This is `-22` in signed 64-bit integer, which corresponds to **`-EINVAL` (Invalid argument)**. However, note that `RAX` is often used to return error codes *from* the syscall. If the kernel crashed, `RAX` might not reflect the actual error code from the crash site. More importantly, the presence of `RAX: ffffffffffffffda` suggests the syscall might have returned `-EINVAL` *after* the crash context was unwound, or this is a KASAN/bug report artifact.
### **Likely Causes** 1. **Corrupted NTFS Superblock or Metadata**: * The NTFS filesystem on the target device may be corrupted. When `ntfs_fs_get_tree` tries to read the superblock or validate the filesystem, it encounters invalid data, leading to a kernel panic or BUG_ON.
2. **Kernel Bug in NTFS Driver**: * There might be a bug in the `ntfs3` (the newer NTFS driver in Linux) or `ntfs` (the older, read-only driver) driver. The `ntfs_fs_get_tree` function might be dereferencing a NULL pointer or accessing invalid memory.
3. **Hardware Issue**: * Bad sectors on the disk containing the NTFS filesystem could cause read errors that the driver doesn't handle gracefully.
4. **Incompatible or Malformed Image**: * If you are mounting an NTFS image file (loop device), the image might be truncated or malformed.
### **Troubleshooting Steps**
1. **Check dmesg for More Details**: * Look for more lines before and after this stack trace in `dmesg`. There might be a specific error message like "NTFS: error reading superblock" or "BUG: unable to handle kernel NULL pointer dereference".
2. **Verify the NTFS Filesystem**: * If possible, check the filesystem from a Windows machine using `chkdsk`. * On Linux, you can try `ntfsfix` (from `ntfs-3g` package) to repair common issues: ```bash sudo ntfsfix /dev/sdXN # Replace with your NTFS partition ```
3. **Check Kernel Version and Patches**: * Ensure your kernel is up-to-date. Bugs in the NTFS driver are occasionally fixed in newer kernel versions. * If you are using the `ntfs3` driver (default in newer kernels), check for known issues with your specific kernel version.
4. **Test with a Different Filesystem**: * Try mounting a different filesystem (e.g., ext4)
VulDB is the best source for vulnerability data and more expert information about this specific topic.