From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Theodor Arsenij Larionov Trichkine <theodorlarionov@gmail.com>,
edumazet@kernel.org, ncardwell@google.com, kuniyu@google.com,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com
Cc: horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] tcp: do not send a SYNACK to a broadcast or multicast address
Date: Fri, 9 Oct 2026 10:23:53 +0800 [thread overview]
Message-ID: <9bed4cb1-7b56-4580-89ad-d8a5b427aae8@linux.dev> (raw)
In-Reply-To: <20261008114942.1376889-1-theodorlarionov@gmail.com>
On 10/8/26 7:49 PM, Theodor Arsenij Larionov Trichkine wrote:
> tcp_v4_conn_request() drops a SYN sent to a broadcast or multicast
> address. The SYNACK route has no such check. A SYN with a multicast
> source address can reach a listener when it is looped back with its
> dst attached: ip_rcv_finish_core() then skips ip_route_input_noref()
> and its martian source check. A raw IP_HDRINCL socket sending to a
> local address does this, as does re-injection by nft dup or the
> iptables TEE target.
>
> If the SYN destination is an address on a non-loopback device and the
> source is a group joined there (such as 224.0.0.1), the SYNACK route
> has RTCF_MULTICAST and RTCF_LOCAL set, and ip_build_and_send_pkt()
> sends it through ip_mc_output(). skb->sk of a SYNACK is the request
> socket, so sk_mc_loop() reads inet_flags past the end of it:
>
> BUG: KASAN: slab-out-of-bounds in sk_mc_loop+0x111/0x170
> Read of size 8 at addr ffff88800f2b7f10 by task repro-raw/470
> Call Trace:
> <IRQ>
> sk_mc_loop+0x111/0x170
> ip_mc_output+0x355/0x930
> ip_build_and_send_pkt+0xb87/0xc50
> tcp_v4_send_synack+0x500/0x6f0
> tcp_conn_request+0x2135/0x2d90
> tcp_v4_conn_request+0xa5/0x210
> tcp_rcv_state_process+0x136e/0x6920
> tcp_v4_do_rcv+0x339/0xb10
> tcp_v4_rcv+0x34ab/0x3ab0
> ip_protocol_deliver_rcu+0x6e/0x3e0
> ip_local_deliver_finish+0x34d/0x510
> ip_local_deliver+0x1bc/0x310
> ip_rcv+0x390/0x410
> __netif_receive_skb_one_core+0x199/0x1e0
> process_backlog+0x239/0x680
> __napi_poll+0xb5/0x650
> net_rx_action+0x980/0xd60
> handle_softirqs+0x17f/0x590
> do_softirq+0x3f/0x60
> </IRQ>
> <TASK>
> __local_bh_enable_ip+0x66/0x80
> __dev_queue_xmit+0xa65/0x3520
> ip_finish_output2+0xb00/0x16f0
> ip_output+0x2ad/0x4a0
> raw_sendmsg+0x245b/0x28e0
> inet_sendmsg+0x121/0x150
> __sys_sendto+0x450/0x4e0
> do_syscall_64+0xf6/0x500
> </TASK>
>
> Allocated by task 470:
> inet_reqsk_alloc+0x97/0x6f0
> tcp_conn_request+0x4c6/0x2d90
> tcp_v4_conn_request+0xa5/0x210
>
> The buggy address belongs to the object at ffff88800f2b7d60
> which belongs to the cache request_sock_TCP of size 312
> The buggy address is located 120 bytes to the right of
> allocated 312-byte region [ffff88800f2b7d60, ffff88800f2b7e98)
>
> Apply the same check to the SYNACK route in inet_csk_route_req().
>
> Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
> Suggested-by: Eric Dumazet <edumazet@kernel.org>
> Signed-off-by: Theodor Arsenij Larionov Trichkine <theodorlarionov@gmail.com>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> v2:
> - Reject broadcast/multicast SYNACK routes in inet_csk_route_req() (Eric Dumazet).
> - Describe how the SYN reaches the listener; add KASAN splat and repro.
> v1: https://lore.kernel.org/netdev/20261008100423.1256884-1-theodorlarionov@gmail.com/
I think SYN with 192.x.x.255 as source can also tirgger this warning
when rp_filter is disabled.
prev parent reply other threads:[~2026-10-09 2:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 11:49 [PATCH net v2] tcp: do not send a SYNACK to a broadcast or multicast address Theodor Arsenij Larionov Trichkine
2026-10-08 11:56 ` netdev-bot+sinfo
2026-10-09 2:23 ` Jiayuan Chen [this message]
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=9bed4cb1-7b56-4580-89ad-d8a5b427aae8@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=theodorlarionov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox