CVE-2024-53168 in Linux
要約
〜によって VulDB • 2026年05月27日
Linux kernel network namespace cleanup race condition in NFS client TCP socket handling.
### Root Cause Analysis
The issue is a **use-after-free (UAF)** vulnerability in the Linux kernel's network namespace cleanup path, specifically involving NFS client TCP sockets.
1. **Scenario**: * An NFS client is running inside a network namespace (`netns_1`). * The NFS client establishes a TCP connection to an NFS server. * The network namespace is deleted (`ip netns del netns_1`).
2. **Race Condition**: * When the namespace is being destroyed, the NFS client's TCP socket is closed (`xs_destroy`), which shuts down the socket and sends a FIN packet. * However, due to network conditions (e.g., dropped FIN packets as in the reproduction script), the NFS server continues to send retransmissions. * The kernel's TCP timer (`tcp_write_timer` or similar) is still active for this socket. * The timer handler function accesses the `net` structure (network namespace) associated with the socket. * **Critical Bug**: The network namespace (`net`) is freed *before* the TCP timer handler finishes executing or before all references to it are dropped. * This leads to a **use-after-free** when the timer handler accesses the already-freed `net` structure.
3. **KASAN Report**: * The KASAN (Kernel Address Sanitizer) report shows a slab object allocated by `copy_net_ns` (during namespace creation) and freed by `cleanup_net` (during namespace deletion). * The allocation trace shows it was allocated during `unshare` (creating a new network namespace). * The free trace shows it was freed during `cleanup_net` (deleting the namespace). * The use-after-free occurs because the TCP timer handler still holds a reference to this freed `net` structure.
### Fix
The fix is to **hold a reference to the network namespace (`netns refcnt`) for the TCP kernel socket** while the socket is active, similar to how other kernel modules handle this. This ensures that the `net` structure is not freed until all references to it (including those held by the TCP timer) are dropped.
This is described as an "ugly hack" because it's a quick fix to prevent the UAF, but it doesn't address the underlying design issue of how socket timers interact with namespace lifecycle. A proper, cleaner fix would involve refactoring the interfaces to ensure proper synchronization between socket timers and namespace cleanup, but this may not be easy to backport to older kernels.
### Reproduction Script Explanation
The provided script sets up a scenario to trigger this race condition:
1. **Setup NFS Server**: Creates an NFS share on `/dev/sdb`. 2. **Create Network Namespace**: Creates `netns_1` and sets up a veth pair to connect it to the host. 3. **Drop FIN Packets**: Uses `iptables` in `netns_1` to drop FIN packets destined for the NFS server. This simulates a network condition where the TCP connection teardown is incomplete. 4. **Mount NFS**: Mounts the NFS share from within `netns_1`. This creates the TCP socket. 5. **Delete Namespace**: Deletes `netns_1`. This triggers the namespace cleanup, which frees the `net` structure. 6. **Trigger UAF**: If the TCP timer fires after the `net` structure is freed but before the socket is fully cleaned up, it accesses the freed memory, causing the UAF.
### Key Takeaways
* **Network Namespace Lifecycle**: Care must be taken when cleaning up network namespaces to ensure all associated resources (like sockets and their timers) are properly cleaned up before the `net` structure is freed. * **Reference Counting**: Using reference counting (`refcnt`) is a common and effective way to prevent UAF in kernel code. The fix applies this principle to the TCP socket's association with the network namespace. * **KASAN**: KASAN is a powerful tool for detecting memory errors like UAF in the kernel. The detailed stack traces provided by KASAN are invaluable for debugging such issues. * **Backporting**: Quick fixes like this are often backported to older kernel versions to address security vulnerabilities, even if they are not the ideal long-term solution.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.