CVE-2026-80851: gtp: serialize PDP context updates
In the Linux kernel, the following vulnerability has been resolved:
gtp: serialize PDP context updates
PDP contexts can be deleted through GTPCMDDELPDP 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 GTPCMDDELPDP against RTMDELLINK:
Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtpgenldelpdp+0x1c1/0x420 [gtp] RBP: dead000000000122
The second deletion dereferenced the poisoned hlist pprev pointer.
Serialize gtppdpadd(), gtpgenldelpdp(), and gtpdellink() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Change the GTP PDP context update code to serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex, and ensure the NEWPDP/DELPDP handling keeps the RCU read-side section around the complete PDP context use (including DELPDP paths) to prevent concurrent deletion while another path still dereferences the poisoned hlist pprev pointer.
Linux kernel (GTP/gtp module) gtp PDP context update serialization = Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex
Event History
Frequently Asked Questions
What access and conditions are needed to trigger the issue?
The race requires concurrent deletion of the same PDP context through the GTP generic-netlink GTP_CMD_DELPDP path and GTP device unregistration through RTM_DELLINK. The affected operations must overlap; either deletion path alone is not the described trigger.
How might this appear on an affected system?
The reported result is a kernel general protection fault with KASAN indicating a possible wild-memory access in gtp_genl_del_pdp. The fault occurs when a second deletion dereferences a poisoned hlist pprev pointer.
What change resolves the race?
The fix serializes PDP context creation, generic-netlink deletion, and GTP device deletion with a shared mutex. It also extends mutex and RCU protection so PDP contexts remain protected through their final use in the relevant NEWPDP and DELPDP paths.