CVE-2022-50739 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel oops trace provided, here is an analysis of the crash and potential causes.
### **Summary** This is a **kernel NULL pointer dereference or invalid memory access** occurring in the VFS (Virtual File System) layer during `d_flags_for_inode`. The crash happens while processing directory entry flags for an inode.
---
### **Key Details from the Trace**
1. **Crash Location**: ```text RIP: 0010:d_flags_for_inode+0xe0/0x110 ``` - The kernel crashed inside `d_flags_for_inode()`, a function responsible for determining flags (like read-only, immutable, etc.) for an inode's directory entry.
2. **Error Type**: ```text CR2: 0000000000000008 ``` - `CR2` holds the address that caused a page fault (if it was a segfault). Here, `0x8` suggests an attempt to access memory at offset `0x8` from a NULL or invalid base pointer. This is classic for dereferencing a **NULL struct member** (e.g., `ptr->field[1]`).
3. **Registers**: - `RAX: 0000000000000001` → Likely the return value or an error code (`-EFAULT` is `-14`, but here it's `1`; could be a flag). - `RBX: ffff888008ccd750` → A kernel virtual address (likely an inode, dentry, or superblock structure). - `RDI: 0000564b22297ce0` → User-space pointer? Wait, this looks like a user-space heap allocation (`0x56...`). But the crash is in kernel space. This suggests the syscall was passing data from userspace that triggered the bug.
4. **Syscall Context**: ```text ORIG_RAX: 00000000000000a5 ``` - System call number `0xa5` (165 in decimal) on x86_64 is typically **`statx()`** or a related file status syscall. This aligns with the crash happening during inode/dentry flag resolution.
---
### **Likely Cause**
The function `d_flags_for_inode()` expects valid pointers to an inode and/or dentry structure. The access at offset `0x8` from a NULL/invalid pointer suggests:
- A **NULL or corrupted `struct inode *`** was passed into the function. - Or, more likely, a **corrupted `struct super_block *`** or **`struct dentry *`** where one of its members (at offset 0x8) is NULL but expected to be valid.
This often happens when: 1. A filesystem driver returns an invalid inode/dentry structure. 2. Race condition in VFS layer causing use-after-free or double-free. 3. Bug in a specific filesystem module (e.g., NFS, CIFS, FUSE, Btrfs, XFS) that doesn’t properly initialize structures before returning them to the core VFS code.
---
### **How to Debug Further**
1. **Identify the Filesystem**: - Check `dmesg` for any filesystem-specific errors around this time. - Look at `/proc/mounts` or `mount | grep <filesystem>` to see what FS was being accessed when the crash occurred.
2. **Reproduce with Debug Info**: If you can reproduce it, enable kernel debugging: ```bash echo 1 > /sys/kernel/debug/kprobes/enabled # Or use ftrace to trace d_flags_for_inode calls ```
3. **Check for Recent Changes**: - Did you recently update the kernel or a filesystem module? - Are you using any third-party modules (e.g., ZFS, Btrfs experimental features)?
4. **Look at Full Stack Trace**: The trace is truncated. You need the full `Call Trace:` section to see which function called `d_flags_for_inode()`. It will likely show: ```text Call Trace: <TASK> ? d_flags_for_inode+0xe0/0x110 statfs_fill_cache? or similar VFS path... ... </TASK> ```
5. **Check Kernel Version**: - This bug may have been fixed in newer kernels. Check if your kernel version is
VulDB is the best source for vulnerability data and more expert information about this specific topic.