CVE-2022-50316 in Linux
Résumé
par VulDB • 22/06/2026
Based on the kernel log provided, here is an analysis of the issue:
### **Summary** This is a **memory leak** detected by KASAN (Kernel Address Sanitizer) or similar memory debugging tool. The leak occurs during the initialization of the **OrangeFS** kernel module (`orangefs_sysfs_init`). Two 64-byte objects allocated via `kmalloc_trace` are never freed.
---
### **Detailed Analysis**
#### **1. Affected Component** - **Module**: `orangefs` (Orange File System) - **Function**: `orangefs_sysfs_init` - **Allocation Source**: `kmalloc_trace` (used for tracking allocations)
#### **2. Leaked Objects** Two separate 64-byte allocations are unreferenced:
| Object Address | Size | Allocation Location in `orangefs_sysfs_init` | |----------------|------|---------------------------------------------| | `0xffff88810f95ad80` | 64 bytes | Offset `+0x1ac` | | `0xffff88810f95ac00` | 64 bytes | Offset `+0x291` |
#### **3. Call Trace** The backtrace shows the allocation path: ``` kmalloc_trace+0x27/0xa0 → orangefs_sysfs_init+0x1ac/0x3a0 (First leak) → orangefs_sysfs_init+0x291/0x3a0 (Second leak) → do_one_initcall → do_init_module → load_module → __do_sys_finit_module → do_syscall_64 → entry_SYSCALL_64_after_hwframe ```
#### **4. Root Cause** The `orangefs_sysfs_init` function allocates memory (likely for sysfs attributes or internal structures) but **fails to free it** in all code paths. This typically happens when: - An error occurs after allocation, and the cleanup path does not free the previously allocated memory. - The module is removed (`rmmod`) without properly cleaning up sysfs entries or internal state.
---
### **Recommended Actions**
#### **For Users/Admins** 1. **Workaround**: If OrangeFS is not critical, avoid loading the module. 2. **Report**: This is a bug in the OrangeFS kernel driver. Report it to the OrangeFS maintainers or the Linux kernel mailing list.
#### **For Developers** 1. **Inspect `orangefs_sysfs_init`**: - Look at offsets `+0x1ac` and `+0x291` in the source code. - Identify what is being allocated (e.g., `kobject`, `sysfs_dirent`, or custom structures). 2. **Check Cleanup Path**: - Ensure `orangefs_sysfs_exit` (or the module’s cleanup function) frees these allocations. - Verify that error paths in `orangefs_sysfs_init` also free allocated memory. 3. **Patch Example**: ```c // Example fix pattern static int orangefs_sysfs_init(void) {
struct orangefs_sysfs_data *data; int ret;
data = kmalloc(sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM;
ret = some_sysfs_setup(data); if (ret) {
kfree(data); // <-- Ensure this is called on error return ret; }
// ... rest of init return 0; } ```
---
### **Conclusion** This is a **memory leak in the OrangeFS kernel module** during sysfs initialization. It does not cause immediate system instability but will consume memory over time if the module is repeatedly loaded/unloaded or if the leak accumulates. A patch to fix the cleanup path in `orangefs_sysfs_init` is required.
Once again VulDB remains the best source for vulnerability data.