CVE-2026-80851 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
gtp: serialize PDP context updates
PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU.
Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK:
Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp]
RBP: dead000000000122
The second deletion dereferenced the poisoned hlist pprev pointer.
Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within the Linux kernel's GTP (GPRS Tunneling Protocol) implementation stems from a critical race condition involving concurrent access to Packet Data Protocol contexts. Specifically, the issue arises when two distinct deletion paths operate simultaneously without adequate synchronization mechanisms. The first path involves deleting PDP contexts via the generic-netlink interface using the GTP_CMD_DELPDP command, which relies on Read-Copy-Update (RCU) primitives for serialization. The second path occurs during the unregistration of the GTP network device, a process that is properly serialized by the RTNL lock. Because these two mechanisms employ different locking strategies and do not coordinate with each other, it becomes possible for both paths to attempt deletion of the same PDP context at nearly the same time. This lack of mutual exclusion creates a window where shared data structures are modified concurrently without proper protection, leading to memory corruption and system instability.
The technical flaw is rooted in the inconsistent locking granularity between the generic-netlink delete path and the device unregistration path. While RTNL serialization ensures that only one thread can unregister the network interface at a time, it does not protect against concurrent operations initiated through the netlink socket interface. When GTP_CMD_DELPDP is executed while the device is being torn down, both threads may proceed to free or manipulate the same PDP context structure. Static analysis tools initially flagged this concurrency issue, and subsequent reproduction using Kernel Address Sanitizer (KASAN) confirmed that racing these operations results in a general protection fault. The crash occurs because one thread dereferences an hlist pprev pointer after it has been poisoned by KASAN during the initial deletion attempt by the other thread. This indicates use-after-free behavior where memory previously allocated for the context is accessed after being freed, leading to wild-memory-access errors and potential kernel panics.
From a security perspective, this vulnerability represents a significant risk as it can lead to denial of service conditions through system crashes or potentially more severe exploitation scenarios if an attacker can control the state of the PDP context prior to deletion. The race condition allows for arbitrary code execution possibilities depending on how the corrupted memory is utilized by subsequent kernel operations. In terms of industry standards, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). Furthermore, it relates to CWE-416: Use After Free, as evidenced by the dereferencing of a poisoned pointer after the resource has been released. The attack vector is classified under ATT&CK technique T1059.007: Command and Scripting Interpreter via Netlink sockets, allowing local or remote attackers with appropriate privileges to trigger the race condition through crafted netlink messages.
The resolution involves implementing proper synchronization primitives to serialize access to PDP context modifications across all relevant code paths. A shared mutex is introduced to protect gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() functions, ensuring that only one thread can modify or delete a PDP context at any given moment. The implementation strategy carefully balances performance with safety by holding the mutex until the final use of a PDP context in the NEWPDP path. Additionally, for the DELPDP path, the RCU read-side section is maintained around the complete usage of the PDP context to ensure safe access during grace periods while still preventing concurrent deletions via the mutex. This dual-layer approach ensures that both addition and deletion operations are mutually exclusive where necessary, eliminating the race condition entirely.
To mitigate this vulnerability in affected systems, administrators should apply the latest kernel updates provided by their distribution vendors as soon as they become available. For environments running custom or unpatched kernels, monitoring for unusual system crashes related to GTP interfaces can serve as an indicator of attempted exploitation. Network segmentation and strict access controls on netlink sockets can also reduce the attack surface by limiting which users or processes are permitted to send commands that interact with GTP device management functions. Continuous integration testing should include concurrency checks using tools like KASAN and lockdep to detect similar race conditions in other network protocol implementations within the kernel, ensuring robust synchronization across all shared resource access points.