CVE-2026-89789: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free
In the Linux kernel, the following vulnerability has been resolved:
gtp: add synchronizenet() in gtpnewlink() error path to prevent use-after-free
gtpnewlink()'s error path frees tidhash and addrhash without waiting for an RCU grace period after clearing skuserdata. A concurrent gtpencaprecv() in softirq may still hold the gtpdev pointer obtained via rcudereferenceskuserdata() and access the freed memory.
BUG: KASAN: slab-use-after-free in gtp0pdpfind+0x1f6/0x200 (gtp.c:152) Call Trace: <IRQ> gtp0pdpfind+0x1f6/0x200 gtpencaprecv+0x527/0x24b0 udpqueuercvoneskb+0x75f/0xc10
Add synchronizenet() before the kfree calls in outhashtable, which covers all error paths from both gtpencapenable() and gtpcreatesockets().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In gtp.c, add synchronize_net() before the kfree calls in out_hashtable (and gtp_newlink() error path) to prevent KASAN slab-use-after-free involving gtp0_pdp_find.
Linux kernel gtp (gtp.c) Insert synchronize_net() before kfree calls in out_hashtable/gtp_newlink() error path = Add synchronize_net() before the kfree calls - Operational
Ensure the patch is applied so the gtp_newlink() error path waits for an RCU grace period by clearing sk_user_data and using synchronize_net() before freeing tid_hash and addr_hash.
Event History
Frequently Asked Questions
When can this race be triggered?
It requires concurrent packet reception in gtp_encap_recv() while gtp_newlink() is taking an error path after clearing sk_user_data and freeing the GTP hash tables. The receive path runs in softirq context and may retain a GTP device pointer obtained through RCU.
Which setup or operations are implicated?
The affected cleanup path covers errors originating from both gtp_encap_enable() and gtp_create_sockets(). The issue is therefore associated with GTP device creation that fails while GTP encapsulation receive processing can run concurrently.
What does the fix change?
The fix adds synchronize_net() before freeing tid_hash and addr_hash in the out_hashtable cleanup path. This waits for the relevant network RCU grace period so concurrent receive processing cannot access the freed GTP device data.