From: Sabrina Dubroca <sd@queasysnail.net>
To: Hyunwoo Kim <imv4bel@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Julia.Lawall@inria.fr,
linux@treblig.org, nate.karstens@garmin.com,
netdev@vger.kernel.org
Subject: Re: [PATCH net v2] strparser: Fix race condition in strp_done()
Date: Mon, 23 Feb 2026 18:20:58 +0100 [thread overview]
Message-ID: <aZyMejqTbkI7o_VM@krikkit> (raw)
In-Reply-To: <aZgpkyTDU3aXe_V0@v4bel>
2026-02-20, 18:29:55 +0900, Hyunwoo Kim wrote:
> This issue was discovered during a code audit.
>
> When strp_stop() and strp_done() are called without holding lock_sock(),
> they can race with worker-scheduling paths such as the Delayed ACK handler
> and ksoftirqd.
> Specifically, after cancel_delayed_work_sync() and cancel_work_sync() are
> invoked from strp_done(), the workers may still be scheduled.
> As a result, the workers may dereference freed objects.
>
> The following is a simple race scenario:
>
> cpu0 cpu1
>
> espintcp_close()
> espintcp_data_ready()
> strp_data_ready()
> if (unlikely(strp->stopped)) return;
> strp_stop()
> strp->stopped = 1;
> strp_done()
> cancel_delayed_work_sync(&strp->msg_timer_work);
> strp_read_sock()
> tcp_read_sock()
> __tcp_read_sock()
> strp_recv()
> __strp_recv()
> strp_start_timer()
> mod_delayed_work(&strp->msg_timer_work);
>
> To prevent these races, the cancellation APIs are replaced with
> worker-disabling APIs.
I'm still not totally convinced by this patch. The comment for
strp_done says the function expects to be called at a time when
strp_recv cannot happen in parallel:
strp must already be stopped so that strp_recv will no longer be called
"strp stopped" is not really enough, I think we'd also need to reset
the CBs, and then grab bh_lock_sock to make sure a previously-running
->sk_data_ready has completed. This is what kcm does, at least.
Without that, if strp_recv runs in parallel (not from strp->work) with
strp_done, cleaning up skb_head in strp_done seems problematic.
--
Sabrina
next prev parent reply other threads:[~2026-02-23 17:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 9:29 [PATCH net v2] strparser: Fix race condition in strp_done() Hyunwoo Kim
2026-02-23 17:20 ` Sabrina Dubroca [this message]
2026-02-26 21:51 ` Hyunwoo Kim
2026-03-02 23:10 ` Sabrina Dubroca
2026-03-03 1:50 ` Hyunwoo Kim
2026-03-05 23:35 ` Sabrina Dubroca
2026-03-06 0:11 ` Hyunwoo Kim
2026-03-06 10:13 ` Sabrina Dubroca
2026-03-06 11:41 ` Hyunwoo Kim
2026-03-11 4:13 ` Hyunwoo Kim
2026-03-20 19:07 ` Hyunwoo Kim
2026-03-11 6:34 ` Jiayuan Chen
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=aZyMejqTbkI7o_VM@krikkit \
--to=sd@queasysnail.net \
--cc=Julia.Lawall@inria.fr \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=imv4bel@gmail.com \
--cc=kuba@kernel.org \
--cc=linux@treblig.org \
--cc=nate.karstens@garmin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox