From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
andrew+netdev@lunn.ch, horms@kernel.org,
Jakub Kicinski <kuba@kernel.org>,
Yiming Qian <yimingqian591@gmail.com>,
daniel.zahka@gmail.com, willemdebruijn.kernel@gmail.com
Subject: Re: [PATCH net] net: psp: check for device unregister when creating assoc
Date: Tue, 24 Mar 2026 18:40:00 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.39ac32125c0cc@gmail.com> (raw)
In-Reply-To: <20260324205107.318303-1-kuba@kernel.org>
Jakub Kicinski wrote:
> psp_assoc_device_get_locked() obtains a psp_dev reference via
> psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU);
> it then acquires psd->lock and drops the reference. Before
> the lock is taken, psp_dev_unregister() can run to completion:
> take psd->lock, clear out state, unlock, drop the registration
> reference.
>
> The expectation is that the lock prevents device unregistration,
> but much like with netdevs special care has to be taken when
> "upgrading" a reference to a locked device. Add the missing
> check if device is still alive. psp_dev_is_registered() exists
> already but had no callers, which makes me wonder if I either
> forgot to add this or lost the check during refactoring...
>
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Fixes: 6b46ca260e22 ("net: psp: add socket security association code")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
> ---
> CC: daniel.zahka@gmail.com
> CC: willemdebruijn.kernel@gmail.com
> ---
> net/psp/psp_nl.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/psp/psp_nl.c b/net/psp/psp_nl.c
> index 6afd7707ec12..c7c377a7790d 100644
> --- a/net/psp/psp_nl.c
> +++ b/net/psp/psp_nl.c
> @@ -320,6 +320,11 @@ int psp_assoc_device_get_locked(const struct genl_split_ops *ops,
> id = info->attrs[PSP_A_ASSOC_DEV_ID];
> if (psd) {
> mutex_lock(&psd->lock);
> + if (!psp_dev_is_registered(psd)) {
> + mutex_unlock(&psd->lock);
> + err = -ENODEV;
> + goto err_psd_put;
> + }
This ensures that psd is valid for this caller of psp_dev_get_for_sock
and psp_dev_tryget, which is its only one (for now).
But is it confusing that psd can be cleared out while a reference is
held? Is the assumption that psp_dev_unregister usually holds the last
reference and its psp_dev_put will complete the clean up by calling
psp_dev_free. If so, would it make sense to defer everything
to psp_dev_free?
This is a simpler changes and fixes the issue for the only caller, so
LGTM. Just curious.
> if (id && psd->id != nla_get_u32(id)) {
> mutex_unlock(&psd->lock);
> NL_SET_ERR_MSG_ATTR(info->extack, id,
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-03-24 22:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 20:51 [PATCH net] net: psp: check for device unregister when creating assoc Jakub Kicinski
2026-03-24 22:40 ` Willem de Bruijn [this message]
2026-03-26 20:04 ` Jakub Kicinski
2026-03-26 20:46 ` Willem de Bruijn
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=willemdebruijn.kernel.39ac32125c0cc@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yimingqian591@gmail.com \
/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.