CVE-2024-36939 in Linux
Zusammenfassung
von VulDB • 16.05.2026
This is a kernel crash (Oops/Panic) trace. Here is the analysis:
### **1. Root Cause** The crash occurs in **`rpc_proc_unregister`** (`net/sunrpc/stats.c:310`) during the cleanup of the NFS network namespace (`nfs_net_exit`).
The likely cause is a **use-after-free** or **double-free** scenario involving the RPC stats registration. Specifically: - The NFS module is being unloaded or a network namespace is being destroyed (`nfs_net_exit`). - It attempts to unregister RPC statistics procedures via `rpc_proc_unregister`. - However, the data structure being unregistered has already been freed or corrupted, leading to a null pointer dereference or invalid memory access.
### **2. Call Trace Analysis** ``` rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 ↓ nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ↓ ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 ↓ setup_net+0x46c/0x660 net/core/net_namespace.c:372 ↓ copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 ↓ create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 ↓ unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ↓ ksys_unshare+0x342/0x760 kernel/fork.c:3322 ↓ __do_sys_unshare kernel/fork.c:3393 [inline]
↓ __se_sys_unshare kernel/fork.c:3391 [inline]
↓ __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 ``` - The system was executing the `unshare` system call (`SYS_unshare`, syscall number `0x110` = 272). - `unshare` creates new namespaces, including a new network namespace (`copy_net_ns`). - During the setup/teardown of the network namespace, the NFS module's exit function (`nfs_net_exit`) is called. - `nfs_net_exit` calls `rpc_proc_unregister`, which crashes.
### **3. Key Registers** - **RIP**: `0x7f30d0febe5d` (User-space address? This is unusual for a kernel crash. It suggests the crash might have occurred in a context where user-space memory was accessed, or the trace is from a user-space process that triggered a kernel fault. However, the call trace is clearly kernel-space. This might be a **KASAN** or **KCSAN** report where the RIP points to the faulting instruction in user space that caused the kernel to panic, or it's a display artifact. More likely, the crash happened in kernel space, and the RIP shown is from the user-space context that invoked the syscall.) - **RAX**: `0xffffffffffffffda` (-42 in signed 64-bit). This is often an error code. In the context of `rpc_proc_unregister`, it might indicate a failure in finding the procedure to unregister. - **DR6/DR7**: Debug registers are set, indicating this might be a **KASAN** (Kernel Address Sanitizer) report. KASAN uses hardware debug registers to detect out-of-bounds accesses.
### **4. Likely Scenario** This is a known class of bugs in the Linux kernel's RPC/NFS subsystem: - **Race Condition**: A race between the unregistration of RPC stats and their usage. - **Use-After-Free**: The `rpc_proc` structure is freed while still being referenced during namespace cleanup. - **Missing Initialization**: The `rpc_proc` list might not be properly initialized or cleaned up in certain edge cases during namespace creation/destruction.
### **5. Recommended Actions** 1. **Check Kernel Version**: This bug may have been fixed in newer kernel versions. Check if your kernel is up-to-date. 2. **Reproduce**: Try to reproduce the crash with a simple `unshare` command that triggers NFS namespace operations. 3. **KASAN Report**: If this is a KASAN report, look for the "BUG: KASAN: use-after-free" or "BUG: KASAN: double-free" message above the call trace. It will provide the exact object that was freed and where it was allocated. 4. **Patch**:
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.