CVE-2024-35899 in Linux
Riassunto
di VulDB • 17/06/2026
Based on the kernel crash log and the GDB output provided, here is an analysis of the issue:
### **1. Summary of the Issue** This is a **Use-After-Free (UAF)** bug in the Linux kernel's `nf_tables` subsystem. - **Symptom**: The kernel crashes (likely a NULL pointer dereference or invalid memory access) when accessing a `nf_tables` object. - **Root Cause**: Memory was freed by task `192222` during module unload (`nf_tables_module_exit`), but was still accessed by another context (likely a netlink message processing thread) after it had been freed. - **Location**: The crash occurs in `nfnetlink_rcv` → `netlink_unicast` → ... → `__nft_release_table` (or a related function called from it). The GDB trace shows the crash happened while iterating over `table->sets` in `__nft_release_table`.
### **2. Detailed Analysis**
#### **A. The "Freed by" Stack Trace** ``` Freed by task 192222: kfree+0xb6/0x260 __nft_release_table+0x473/0x6a0 [nf_tables]
nf_tables_exit_net+0x170/0x240 [nf_tables]
... nf_tables_module_exit+0x43/0x80 [nf_tables]
__do_sys_delete_module+0x253/0x370 ``` - **What happened**: Task `192222` was unloading the `nf_tables` kernel module (`delete_module`). - **Action**: It called `nf_tables_module_exit` → `unregister_pernet_subsys` → `nf_tables_exit_net` → `__nft_release_table`. - **Result**: `__nft_release_table` iterated through all tables, sets, flowtables, etc., and called `kfree` on them. Specifically, the GDB output shows it was in the loop: ```c list_for_each_entry_safe(set, ns, &table->sets, list) {
list_del(&set->list); nft_use_dec(&table->use); if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) nft_map_deactivate(set); // or similar // ... eventually kfree(set) } ```
#### **B. The "Allocated by" / "Accessed by" Stack Trace** ``` Accessed by task ??? (implied from the first stack trace): nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
netlink_unicast+0x367/0x4f0 netlink_sendmsg+0x34b/0x610 ____sys_sendmsg+0x4d4/0x510 ... do_syscall_64+0x55/0x120 ``` - **What happened**: Another task (likely a user-space process sending a netlink message) was processing an `NFNETLINK` message. - **Action**: It called `nfnetlink_rcv`, which eventually tried to access an `nf_tables` object (e.g., a set or table) that had just been freed. - **Result**: The kernel crashed because it dereferenced a pointer to freed memory.
### **3. Root Cause Explanation** This is a classic **race condition** between: 1. **Module Unload Path**: `nf_tables_module_exit` is cleaning up all netfilter tables and sets. 2. **Netlink Message Processing Path**: A concurrent netlink message (e.g., `NFT_MSG_GETSET`, `NFT_MSG_NEWSET`, etc.) is being processed and holds a reference to an object that is being freed.
The bug likely stems from one of the following: - **Missing Reference Counting**: The netlink message processing path did not properly increment the reference count (`nft_use_inc`) on the object before accessing it, or did not check if the object was still valid. - **Improper Cleanup Order**: The module exit path freed objects while they were still being accessed by pending netlink messages. - **Missing Synchronization**: There is no lock protecting the iteration over `table->sets` in `__nft_release_table` from concurrent netlink operations.
### **4. How to Fix** This is a kernel bug that needs to be fixed in the `nf_tables` subsystem. Possible fixes include:
1. **Ensure Proper Reference Counting
Be aware that VulDB is the high quality source for vulnerability data.