From: Simon Horman <horms@kernel.org>
To: Xuanqiang Luo <xuanqiang.luo@linux.dev>
Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, aleksander.lobakin@intel.com,
wojciech.drewek@intel.com, marcin.szycik@linux.intel.com,
linux-kernel@vger.kernel.org,
Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Subject: Re: [PATCH net v1] pfcp: fix socket lifetime on netdevice registration failure
Date: Wed, 23 Sep 2026 10:29:50 +0100 [thread overview]
Message-ID: <20260923092638.GS13925@horms.kernel.org> (raw)
In-Reply-To: <20260918123158.5631-1-xuanqiang.luo@linux.dev>
On Fri, Sep 18, 2026 at 08:31:58PM +0800, Xuanqiang Luo wrote:
> From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>
> pfcp_newlink() creates the UDP socket before register_netdevice().
> If registration fails after pfcp_dev_init() succeeds, the core calls
> pfcp_dev_uninit(), which releases the socket and clears pfcp->sk.
> The newlink error path then releases it again, causing a NULL pointer
> dereference. This was observed with failslab fault injection:
>
> FAULT_INJECTION: forcing a failure.
> kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net)
> BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50
> Read of size 8 at addr 0000000000000120 by task ip/1037
> Call trace:
> show_stack+0x18/0x24 (C)
> dump_stack_lvl+0x78/0x90
> print_report+0x468/0x5cc
> kasan_report+0xa4/0xf0
> __asan_load8+0x7c/0xd0
> udp_tunnel_sock_release+0x1c/0x50
> pfcp_newlink+0x128/0x184
> rtnl_newlink+0x848/0xe44
> rtnetlink_rcv_msg+0x468/0x514
> netlink_rcv_skb+0xc0/0x1f0
> rtnetlink_rcv+0x18/0x24
> netlink_unicast+0x4b8/0x558
> netlink_sendmsg+0x2b8/0x584
> ...
>
> Create the socket in pfcp_dev_init() after initializing the GRO cells,
> and let pfcp_dev_uninit() release it on registration failure or removal.
>
> Move the RCU wait into pfcp_dev_uninit(), using synchronize_net() after
> socket release to drain receive callbacks before destroying the GRO cells.
>
> Fixes: 76c8764ef36a5 ("pfcp: add PFCP module")
> Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
> ---
> A NULL check would fix the crash. Moving socket creation into ndo_init
> also removes the duplicate cleanup and ensures the receive state is
> initialized before enabling the socket's receive callback.
Assuming the NULL check is significantly simpler than this patch,
and that it resolves the bug, think that we should consider:
1. A patch that minimal NULL check for net
2. Follow-up with the approach taken by this patch in net-next
I say this because this seems to be lower risk than skipping to applying
2 to net.
Also, please consider CCing stable on bug fixes.
Link: https://docs.kernel.org/process/maintainer-netdev.html#stable-tree
next prev parent reply other threads:[~2026-09-23 9:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 12:31 [PATCH net v1] pfcp: fix socket lifetime on netdevice registration failure Xuanqiang Luo
2026-09-23 9:29 ` Simon Horman [this message]
2026-09-23 9:57 ` Xuanqiang Luo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923092638.GS13925@horms.kernel.org \
--to=horms@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luoxuanqiang@kylinos.cn \
--cc=marcin.szycik@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=wojciech.drewek@intel.com \
--cc=xuanqiang.luo@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.