CVE-2022-50316 in Linux
Zusammenfassung
von VulDB • 01.07.2026
Based on the kernel log provided, here is an analysis of the memory leak issue in the `orangefs` module.
### **Summary** The Linux kernel's KASAN (Kernel Address Sanitizer) or SLUB debug subsystem has detected a **memory leak**. Two 64-byte objects allocated during the initialization (`init`) phase of the `orangefs` filesystem driver were never freed when the module was unloaded or after an error path.
### **Detailed Analysis**
#### **1. The Leak Objects** * **Object 1:** `0xffff88810f95ad80` (size 64 bytes) * Allocated by: `kmalloc_trace+0x27/0xa0` * Caller in module: `orangefs_sysfs_init+0x1ac/0x3a0` * **Object 2:** `0xffff88810f95ac00` (size 64 bytes) * Allocated by: `kmalloc_trace+0x27/0xa0` * Caller in module: `orangefs_sysfs_init+0x291/0x3a0`
Both objects are **unreferenced**, meaning they were allocated but no pointer to them was kept, or the cleanup path failed to free them. Since this happens during `insmod` (module load), it suggests that either: 1. The module initialization succeeded partially, but an error occurred later causing a rollback that didn't clean up these specific sysfs entries. 2. Or more likely in init paths: **The cleanup function (`exit`) is not being called or does not free all resources created during `init` if the init fails partway through.**
#### **2. Root Cause Location** * **Module:** `orangefs` (OrangeFS client filesystem) * **Function:** `orangefs_sysfs_init()` * This function creates sysfs attributes/files for the OrangeFS driver to expose information or configuration via `/sys`. * The leak occurs at two different offsets (`0x1ac` and `0x291`) within this function, implying **two separate allocations** (likely for two different sysfs files/attributes) are not being freed on error paths.
#### **3. Why This Happens** In Linux kernel module development: * If a driver creates multiple sysfs entries in its `init` function using functions like `sysfs_create_file()` or similar helpers, it must ensure that if any subsequent step fails (e.g., registering the filesystem), all previously created sysfs entries are removed. * The backtrace shows these allocations happen during module load (`do_init_module`). If the module loads successfully but later unloads cleanly, KASAN might not report this unless there's a bug in the `exit` path or if the leak is triggered by an **init failure**.
However, since the log says "unreferenced object" and shows it from `insmod`, it’s highly probable that: > **The module initialization failed after creating some sysfs entries but before completing setup. The error-handling code did not clean up those partially created sysfs attributes.**
Alternatively, if the module loaded successfully, this could indicate a bug in the module's `exit` function where these specific sysfs files are not removed upon unload. But KASAN usually reports leaks at **module exit time** or when objects become unreachable. Given the context of "age 65s" and being seen during/after load, it’s likely an **init error path leak**.
### **How to Fix (For Developers)**
1. **Review `orangefs_sysfs_init()` in the OrangeFS source code.** * Look for calls that allocate memory or create sysfs entries around offsets `0x1ac` and `0x291`. * Ensure every successful allocation/sysfs creation has a corresponding cleanup path on error.
2. **Use Proper Error Handling Patterns:** ```c int orangefs_sysfs_init(void) {
struct kobject *kobj; // ... other code ...
ret = sysfs_create_file(kobj, &attr1); if (ret) goto err_remove_attr2; // Ensure attr2 is cleaned up first!
ret = sysfs_create_file(kobj, &attr2); if (ret) goto err_remove_attr1; // Clean up attr1 before returning error
return 0;
err_remove_attr1: sysfs_remove_file(kobj, &attr1); err_remove_attr2: sysfs_remove_file(kobj, &attr2); kobject_put(kobj); return ret
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.