All of lore.kernel.org
 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 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.