public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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

  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