CVE-2024-56642 Overview
CVE-2024-56642 is a use-after-free vulnerability in the Linux kernel's TIPC (Transparent Inter-Process Communication) subsystem. The flaw exists in the cleanup_bearer() function within the UDP media handling code. When bearer_disable() calls tipc_udp_disable(), the cleanup of the UDP kernel socket is deferred to a work queue via cleanup_bearer(). However, a race condition occurs where tipc_exit_net() prematurely unblocks cleanup_net() because the work decrements the reference count (tipc_net(net)->wq_count) before the kernel socket is fully released, leading to a use-after-free condition.
Critical Impact
This vulnerability allows a local attacker with low privileges to potentially achieve privilege escalation or cause system instability through memory corruption. The use-after-free in udp_lib_unhash() can be exploited to corrupt kernel memory structures.
Affected Products
- Linux Kernel (multiple versions across stable branches)
- Linux Kernel 6.13-rc1
- Systems using TIPC with UDP bearer transport
Discovery Timeline
- 2024-12-27 - CVE-2024-56642 published to NVD
- 2025-11-03 - Last updated in NVD database
Technical Details for CVE-2024-56642
Vulnerability Analysis
This use-after-free vulnerability (CWE-416) occurs due to improper synchronization between the network namespace cleanup and the TIPC bearer cleanup work queue. The syzkaller fuzzer reported this issue without a reproducer, identifying the race condition through memory sanitizer instrumentation.
The vulnerability manifests when the following sequence occurs: First, bearer_disable() initiates the cleanup by calling tipc_udp_disable(), which schedules cleanup_bearer() as deferred work. The tipc_exit_net() function waits for pending work by monitoring tipc_net(net)->wq_count. However, the work handler decrements this counter before completing the socket release operation in sock_release(), allowing cleanup_net() to proceed while the socket is still in use.
When the socket is subsequently accessed during udp_lib_unhash(), the network namespace memory has already been freed, resulting in a use-after-free condition that can corrupt the UDP hash table data structures.
Root Cause
The root cause is a premature decrement of the work queue counter in the cleanup_bearer() function. The counter is decremented before the kernel socket is released via sock_release(), creating a window where cleanup_net() can free the network namespace while the socket cleanup is still in progress. The fix involves moving the counter decrement to occur after sock_release() completes, ensuring proper synchronization between the work queue and namespace cleanup.
Attack Vector
This vulnerability requires local access to the system. An attacker must be able to trigger TIPC bearer operations, specifically the enable/disable cycle with UDP transport. The attack exploits the race condition between network namespace teardown and the asynchronous bearer cleanup work, requiring precise timing or repeated attempts to trigger the vulnerable code path.
The vulnerability does not require user interaction and can be exploited by a process running with low privileges that has access to the TIPC netlink interface for bearer configuration.
Detection Methods for CVE-2024-56642
Indicators of Compromise
- Kernel log messages containing "KMSAN: use-after-free in udp_hashslot" or "use-after-free in udp_lib_unhash"
- Unexpected kernel panics or crashes during network namespace cleanup operations
- Stack traces showing cleanup_bearer and process_one_work in the call chain
- Memory corruption warnings from kernel memory sanitizers (KASAN, KMSAN)
Detection Strategies
- Monitor kernel logs for use-after-free warnings related to UDP or TIPC subsystems
- Deploy kernel memory sanitizers (KASAN/KMSAN) on development and staging systems to detect memory corruption
- Implement system crash monitoring to identify patterns associated with TIPC bearer cleanup
- Use kernel tracing (ftrace, BPF) to monitor cleanup_bearer() and tipc_exit_net() function execution
Monitoring Recommendations
- Enable kernel crash dump collection (kdump) to capture memory state during exploitation attempts
- Configure syslog aggregation to centralize kernel warning messages across the fleet
- Monitor for unexpected TIPC netlink activity that could indicate exploitation attempts
- Deploy SentinelOne Singularity Platform for real-time kernel-level threat detection and behavioral analysis
How to Mitigate CVE-2024-56642
Immediate Actions Required
- Apply the latest kernel security patches from your distribution vendor
- If patching is not immediately possible, consider disabling TIPC bearer functionality if not required
- Review systems for signs of exploitation using the detection methods outlined above
- Prioritize patching on systems that expose TIPC netlink interfaces to untrusted users
Patch Information
Multiple patches have been released across Linux kernel stable branches to address this vulnerability. The fix moves the wq_count decrement to occur after the socket is fully released in cleanup_bearer(). Apply the appropriate patch for your kernel version:
- Kernel Patch Commit 4e69457
- Kernel Patch Commit 650ee9a
- Kernel Patch Commit 6a2fa13
- Kernel Patch Commit d00d447
- Kernel Patch Commit d2a4894
- Kernel Patch Commit d62d518
- Kernel Patch Commit e48b211
Debian users should refer to the Debian LTS Security Announcements for distribution-specific updates.
Workarounds
- Disable TIPC kernel module if not required: modprobe -r tipc and blacklist in /etc/modprobe.d/
- Restrict access to TIPC netlink interfaces using network namespace isolation
- Limit local user access on systems where TIPC functionality is critical
- Implement mandatory access control (SELinux/AppArmor) policies to restrict TIPC bearer configuration
# Disable and blacklist TIPC module if not required
modprobe -r tipc
echo "blacklist tipc" >> /etc/modprobe.d/blacklist-tipc.conf
echo "install tipc /bin/false" >> /etc/modprobe.d/blacklist-tipc.conf
# Verify module is not loaded
lsmod | grep tipc
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


