CVE-2026-74255 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix UAF in tipc_l2_send_msg()

Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg().

The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers.

Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net().

This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 ("tipc: make bearer packet filtering generic") to call tipc_node_delete_links() (which needs the pointer) before disable_media().

https: //lore.kernel.org/netdev/[email protected]/T/#u

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 08/15/2026

The vulnerability identified in the Linux kernel represents a critical use-after-free condition within the TIPC (Transparent Inter-Process Communication) subsystem, specifically affecting the tipc_l2_send_msg() function. This issue manifests as a slab-use-after-free error reported by Syzbot, a sophisticated fuzzing system designed to identify kernel vulnerabilities. The flaw occurs during network packet processing when the ipvlan_hard_header() function is invoked from within tipc_l2_send_msg(), creating a scenario where memory that has been freed is still being accessed by concurrent readers.

The technical root cause stems from improper synchronization mechanisms within the TIPC bearer management code. When tipc_disable_l2_media() executes, it calls synchronize_net() while the b->media_ptr structure pointer remains valid and accessible to concurrent RCU (Read-Copy-Update) readers. This timing issue creates a race condition where readers can obtain references to the device pointer after synchronize_net() has completed but before the pointer is actually cleared in the subsequent bearer_disable() function. The sequence of operations allows for the device memory to be freed while still being actively referenced by existing RCU readers, leading to undefined behavior and potential system instability.

The vulnerability directly maps to CWE-416, which describes Use After Free conditions where a pointer is used after the memory it points to has been freed. This represents a classic race condition in concurrent programming where proper synchronization barriers are missing between memory deallocation and subsequent access operations. The fix implementation addresses this by reordering the sequence of operations within the TIPC subsystem, ensuring that b->media_ptr is cleared in tipc_disable_l2_media() before calling synchronize_net(). This approach aligns with ATT&CK technique T1059.006 for system binary manipulation and T1484.001 for privilege escalation through kernel exploits.

The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling attackers to execute arbitrary code within the kernel context or cause system crashes that could lead to denial-of-service conditions. The fix leverages a specific ordering change introduced in commit 0d051bf93c06 which restructured bearer_disable() to call tipc_node_delete_links() before disable_media(), making it safe to clear the media pointer earlier in the process. This change demonstrates the importance of proper function call sequencing and synchronization in kernel-level programming where timing-sensitive operations can create exploitable race conditions that compromise system security and stability. The solution represents a defensive programming approach that prevents concurrent access to freed memory resources by ensuring proper ordering of cleanup operations and eliminating the window of vulnerability between pointer invalidation and actual memory deallocation.

Responsible

Linux

Reservation

08/15/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!