CVE-2024-35899 in Linux
الملخص
بحسب VulDB • 02/07/2026
Based on the kernel crash log and stack trace provided, here is an analysis of the issue:
### **Summary** This is a **Use-After-Free (UAF)** bug in the Linux Netfilter subsystem (`nf_tables`). A memory object was freed by task `192222` during module unloading (`delete_module`) but was subsequently accessed/used by another context (likely via netlink communication) at timestamp `[ 1360.548... ]`.
---
### **Detailed Analysis**
#### **1. The Crash Context (Use)** - **Timestamp:** `1360.548927` - **Function Call Chain:** ``` nfnetlink_rcv → netlink_unicast → netlink_sendmsg → ____sys_sendmsg ... ``` - **Interpretation:** A user-space process is sending a Netfilter message (likely via `libnftnl` or similar) to the kernel. The kernel receives it in `nfnetlink_rcv`, processes it, and attempts to access memory that has already been freed.
#### **2. The Free Context** - **Timestamp:** `1360.548994` (Note: This is *after* the crash timestamp in the log output order, but KASAN reports "Freed by task..." as a separate event. In reality, the free likely happened slightly before or concurrently due to race conditions.) - **Task:** `192222` - **Function Call Chain:** ``` __do_sys_delete_module → nf_tables_module_exit → unregister_pernet_subsys ... → nf_tables_exit_net → __nft_release_table → kfree ``` - **Interpretation:** Task `192222` is deleting the `nf_tables` kernel module. During cleanup, it calls `__nft_release_table`, which iterates over and frees all sets (`table->sets`) in a table.
#### **3. The Bug Location** The GDB output points to: ```c net/netfilter/nf_tables_api.c:11354 list_for_each_entry_safe(set, ns, &table->sets, list) {
list_del(&set->list); // <-- Line 11355 (near the crash site) nft_use_dec(&table->use); ... } ```
However, note that **KASAN reports the free happened in `__nft_release_table`**, and the **crash happens during netlink reception**. This suggests a classic race condition:
> A user-space process is modifying or querying an NFT table (via netlink) at the same time as another thread/module unload path is destroying that table. The set object is freed by `__nft_release_table`, but the netlink handler still holds a reference to it and dereferences it, causing UAF.
---
### **Root Cause** The issue is likely due to: 1. **Missing Reference Counting or RCU Protection:** When iterating over sets in `nf_tables_exit_net` → `__nft_release_table`, the code may not be properly synchronizing with concurrent netlink operations that are accessing those same sets. 2. **Race Between Module Unload and Netlink Ops:** The module exit path (`nf_tables_module_exit`) proceeds to free resources while user-space requests (via netlink) might still be in-flight or being processed for the same table/sets.
---
### **Relevant Code Snippet** From `net/netfilter/nf_tables_api.c` around line 11354: ```c static void __nft_release_table(struct nft_table *table) {
struct nft_flowtable *flowtable, *nf; struct nft_set *set, *ns;
list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
list_del(&flowtable->list); nft_use_dec(&table->use); nf_tables_flowtable_destroy(flowtable); }
// <-- CRITICAL SECTION: Sets are being freed here list_for_each_entry_safe(set, ns, &table->sets, list) {
list_del(&set->list); // Removed from table's set list nft_use_dec(&table->use); if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) nft_map_deactivate(set); nf_tables_set_destroy(set); // This eventually calls kfree() on the set object }
... } ```
If a netlink request is processing this `table` or one of its `set`s concurrently, it may dereference
If you want to get best quality of vulnerability data, you may have to visit VulDB.