From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
David Ahern <dsahern@kernel.org>,
Martin KaFai Lau <martin.lau@kernel.org>,
Kuniyuki Iwashima <kuni1840@gmail.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
Date: Tue, 15 Oct 2024 10:37:50 -0700 [thread overview]
Message-ID: <27d46d3a-b636-4ccf-adfe-41363ad93946@linux.dev> (raw)
In-Reply-To: <20241014223312.4254-1-kuniyu@amazon.com>
On 10/14/24 3:33 PM, Kuniyuki Iwashima wrote:
> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
>
> """
> We are seeing a use-after-free from a bpf prog attached to
> trace_tcp_retransmit_synack. The program passes the req->sk to the
> bpf_sk_storage_get_tracing kernel helper which does check for null
> before using it.
> """
>
> The commit 83fccfc3940c ("inet: fix potential deadlock in
> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
> small race window.
>
> Before the timer is called, expire_timers() calls detach_timer(timer, true)
> to clear timer->entry.pprev and marks it as not pending.
>
> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
> continue running and send multiple SYN+ACKs until it expires.
>
> The reported UAF could happen if req->sk is close()d earlier than the timer
> expiration, which is 63s by default.
>
> The scenario would be
>
> 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
> but del_timer_sync() is missed
>
> 2. reqsk timer is executed and scheduled again
>
> 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
> reqsk timer still has another one, and inet_csk_accept() does not
> clear req->sk for non-TFO sockets
>
> 4. sk is close()d
>
> 5. reqsk timer is executed again, and BPF touches req->sk
>
> Let's not use timer_pending() by passing the caller context to
> __inet_csk_reqsk_queue_drop().
>
>
> Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()")
> Reported-by: Martin KaFai Lau <martin.lau@kernel.org>
> Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.dev/
> Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.dev/ [1]
> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Martin KaFai Lau <martin.lau@kernel.org>
next prev parent reply other threads:[~2024-10-15 17:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
2024-10-15 7:55 ` Eric Dumazet
2024-10-15 17:37 ` Martin KaFai Lau [this message]
2024-10-16 1:00 ` patchwork-bot+netdevbpf
2024-11-23 13:24 ` liujian (CE)
2024-11-23 17:18 ` Kuniyuki Iwashima
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=27d46d3a-b636-4ccf-adfe-41363ad93946@linux.dev \
--to=martin.lau@linux.dev \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=kuniyu@amazon.com \
--cc=martin.lau@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).