Netdev List
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Dudu Lu <phx0fer@gmail.com>
Cc: vinicius.gomes@intel.com, jhs@mojatatu.com, jiri@resnulli.us,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] net/sched: etf: initialise the sock_exterr_skb before filling it
Date: Fri, 23 Oct 2026 12:03:28 +0100	[thread overview]
Message-ID: <20261023110328.GL708417@horms.kernel.org> (raw)
In-Reply-To: <20261021155401.65997-1-phx0fer@gmail.com>

On Wed, Oct 21, 2026 at 11:54:01PM +0800, Dudu Lu wrote:
> report_sock_error() clones the transmitted skb, overlays a
> struct sock_exterr_skb on its control block and fills in the seven
> struct sock_extended_err fields, but never clears addr_offset and port.
> skb_clone() copies cb[] verbatim, so the errqueue entry carries the TX
> skb's stale control block to the receive side, and the ipv4 error-queue
> reader trusts those bytes:
> 
>   net/ipv4/ip_sockglue.c:556
> 	sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
> 					   serr->addr_offset);
> 	sin->sin_port = serr->port;
> 
> The gate that is supposed to guard that read only asks whether an
> address was requested at all:
> 
>   net/ipv4/ip_sockglue.c:484
> 	return serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
> 	       serr->ee.ee_origin == SO_EE_ORIGIN_LOCAL || serr->port;
> 
> SO_EE_ORIGIN_TXTIME is neither ICMP nor LOCAL, so for sch_etf the gate is
> decided by serr->port alone -- by the stale byte pair.  When it is
> non-zero the reader dereferences skb_network_header() + addr_offset with
> an arbitrary offset.  On the TCP path cb[40..44) is not zero: the
> transmit path stored delivered_mstamp there (tcp_rate_skb_sent()), which
> is exactly where addr_offset/port sit in the arm64 struct layout.
> 
> Reached with an unmodified 7.3-rc4 (arm64, KASAN, in-tree modules): a TCP
> socket enables TX-timestamp error reporting (SO_TXTIME with
> SOF_TXTIME_REPORT_ERRORS), a sch_etf qdisc drops the packet, and a
> recvmsg() reaches ip_recv_error():
> 
>   BUG: KASAN: slab-out-of-bounds in ip_recv_error+0x970/0xa0c
>   Read of size 4 at addr ffff0000158ffdd5 by task A-227-A227-1_S2/113
>   ip_recv_error+0x970/0xa0c
>   inet_recv_error+0x94/0xdc
>   tcp_recvmsg+0x378/0x408
>   ...
>   The buggy address is located 149 bytes to the right of
>   allocated 704-byte region
> 
> Zero the whole overlay rather than the two fields individually: the
> errqueue entry is handed to the receive side as a self-contained record,
> which is what every other producer in the tree already does (sch_etf was
> the only error-queue producer that cleared neither field).  This does not
> change what the in-tree selftest observes -- so_txtime.c reads only
> ee_origin/ee_errno/ee_code/ee_data/ee_info, never msg_name or sin_port.
> 
> Fixes: 4b15c7075352 ("net/sched: Make etf report drops on error_queue")
> Assisted-by: LLM
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
> ---
> Tested base
> -----------
> Detected on Linux 7.3-rc4 (commit 93f51579e7df), arm64 QEMU guest.
> Re-checked against mainline f47d223627f8 (v7.3-341): the affected code
> is unchanged between the two, so the bug is still present there.
> Checked against linux-next next-20261021 (commit 9a482184d910): the
> affected code is unchanged there as well, so the bug is still present in
> linux-next too.
> 
> Reproducer status
> -----------------
> A reproducer was written and executed on an arm64 QEMU guest (dummy-virt,
> KASAN kernel) against unmodified 7.3-rc4 in-tree modules; KASAN fired at the
> claimed sink.  The reproducer source is not posted here per
> Documentation/process/security-bugs.rst ("do not publicly share a reproducer");
> it is available on request.
> 
> Triggering conditions
> ---------------------
> CAP_NET_ADMIN to install the etf qdisc; the socket must opt into TX
> timestamp error reporting (SO_TXTIME + SOF_TXTIME_REPORT_ERRORS); a TCP flow
> with a non-empty retransmit queue.  No out-of-tree module is needed.
> 
> Notes
> -----
> Built and checkpatch-clean: this patch was applied on top of 7.3-rc4
> (commit 93f51579e7df) and a full arm64 kernel (defconfig) was built with
> it -- no new warnings or errors.  scripts/checkpatch.pl reports 0 errors,
> 0 warnings.

Reviewed-by: Simon Horman <horms@kernel.org>


  parent reply	other threads:[~2026-10-23 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 15:54 [PATCH net] net/sched: etf: initialise the sock_exterr_skb before filling it Dudu Lu
2026-10-21 15:58 ` netdev-bot+sinfo
2026-10-22  4:44   ` phx
2026-10-23 11:03 ` Simon Horman [this message]
2026-10-24  0:20 ` patchwork-bot+netdevbpf

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=20261023110328.GL708417@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=phx0fer@gmail.com \
    --cc=vinicius.gomes@intel.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