All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  parent reply	other threads:[~2026-10-09  2:24 UTC|newest]

Thread overview: 5+ 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]
2026-10-11 23:02 ` netdev-bot+sashiko
2026-10-12  7:44   ` Eric Dumazet

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 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.