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. On a KASAN-enabled kernel, a reproducer racing DELPDP against RTM_DELLINK triggered:
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.
Take RTNL around the DELPDP lookup and deletion so that PDP creation, generic-netlink deletion and link teardown use the same serialization domain.
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Qing Ming a0yami@mailbox.org --- drivers/net/gtp.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 427b91aca50d..7c4a99e2fd52 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -2127,6 +2127,8 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) if (!info->attrs[GTPA_VERSION]) return -EINVAL;
+ rtnl_lock(); + rcu_read_lock();
pctx = gtp_find_pdp(sock_net(skb->sk), info->attrs); @@ -2147,6 +2149,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info)
out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; }
On Thu, Aug 06, 2026 at 10:32:26AM +0800, Qing Ming wrote:
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. On a KASAN-enabled kernel, a reproducer racing DELPDP against RTM_DELLINK triggered:
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.
Take RTNL around the DELPDP lookup and deletion so that PDP creation, generic-netlink deletion and link teardown use the same serialization domain.
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Qing Ming a0yami@mailbox.org
Hi,
I think it would be good to mention how this problem was found, and to what extent it has been tested.
You may also want to consider adding an Assisted-by tag as appropriate.
Hi Simon,
On Fri, Aug 07, 2026 at 02:13:35PM +0100, Simon Horman wrote:
On Thu, Aug 06, 2026 at 10:32:26AM +0800, Qing Ming wrote:
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. On a KASAN-enabled kernel, a reproducer racing DELPDP against RTM_DELLINK triggered:
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.
Take RTNL around the DELPDP lookup and deletion so that PDP creation, generic-netlink deletion and link teardown use the same serialization domain.
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Qing Ming a0yami@mailbox.org
Hi,
I think it would be good to mention how this problem was found, and to what extent it has been tested.
I know what it is going on, I can take care of this, thanks!
You may also want to consider adding an Assisted-by tag as appropriate.
Hi,
On Thu, Aug 06, 2026 at 10:32:26AM +0800, Qing Ming wrote:
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. On a KASAN-enabled kernel, a reproducer racing DELPDP against RTM_DELLINK triggered:
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.
Take RTNL around the DELPDP lookup and deletion so that PDP creation, generic-netlink deletion and link teardown use the same serialization domain.
Could please you instead add a mutex to a use it to protect PDP ctx updates? genetlink mutex is not enough, and I'd prefer not to fix this with the rtnl lock.
Please, use this new mutex from gtp_dellink() path to protect the iteration over the hashtable.
gtp_genl_del_pdp() must use it too as well as gtp_pdp_add().
Thanks.
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 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 PDP context updates with a mutex shared by gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink().
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Assisted-by: Codex:gpt-5 Signed-off-by: Qing Ming a0yami@mailbox.org --- v2: - Use a dedicated mutex instead of RTNL. - Protect PDP add, delete, and link teardown with the same mutex. drivers/net/gtp.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 427b91aca50d..161d004e34b6 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -12,6 +12,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h> +#include <linux/mutex.h> #include <linux/skbuff.h> #include <linux/udp.h> #include <linux/rculist.h> @@ -105,6 +106,7 @@ struct gtp_net { };
static u32 gtp_h_initval; +static DEFINE_MUTEX(gtp_pdp_lock);
static struct genl_family gtp_genl_family;
@@ -1546,9 +1548,11 @@ static void gtp_dellink(struct net_device *dev, struct list_head *head) struct pdp_ctx *pctx; int i;
+ mutex_lock(>p_pdp_lock); for (i = 0; i < gtp->hash_size; i++) hlist_for_each_entry_safe(pctx, next, >p->tid_hash[i], hlist_tid) pdp_context_delete(pctx); + mutex_unlock(>p_pdp_lock);
list_del_rcu(>p->list); unregister_netdevice_queue(dev, head); @@ -1820,6 +1824,8 @@ static struct pdp_ctx *gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, __be32 ms_addr; int family;
+ guard(mutex)(>p_pdp_lock); + version = nla_get_u32(info->attrs[GTPA_VERSION]);
if (info->attrs[GTPA_FAMILY]) @@ -2127,6 +2133,8 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) if (!info->attrs[GTPA_VERSION]) return -EINVAL;
+ mutex_lock(>p_pdp_lock); + rcu_read_lock();
pctx = gtp_find_pdp(sock_net(skb->sk), info->attrs); @@ -2147,6 +2155,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info)
out_unlock: rcu_read_unlock(); + mutex_unlock(>p_pdp_lock); return err; }
osmocom-net-gprs@lists.osmocom.org
-
Jakub Kicinski -
Pablo Neira Ayuso -
Qing Ming -
Simon Horman