From: Yuqi Xu <xuyuqiabc@gmail.com>
To: netdev@vger.kernel.org
Cc: David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
stable@vger.kernel.org, Vega <vega@nebusec.ai>,
Ren Wei <weir@nebusec.ai>,
xuyq21@lenovo.com
Subject: Re: [PATCH net 1/1] net: ipconfig: bound DHCP option construction
Date: Sun, 20 Sep 2026 15:25:03 +0800 [thread overview]
Message-ID: <20260920072503.60706-1-xuyuqiabc@gmail.com> (raw)
In-Reply-To: <7808dfbfa2162dfd0b19f59aff5742d6e0db2abb.1789798023.git.xuyuqiabc@gmail.com>
Sashiko reported the following finding on the patchset page; it has not
been posted to lore:
> Blind copies in BOOTP extension parsing (`ic_do_bootp_ext`) cause
> out-of-bounds reads if an attacker provides a truncated option length.
> location: net/ipv4/ipconfig.c
This finding is about the receive path, not the code this patch changes.
It is a real, pre-existing issue; this series does not introduce it.
This series only touches the transmit side, ic_dhcp_init_options()
(net/ipv4/ipconfig.c:698) and the new ic_dhcp_add_option() helper
(net/ipv4/ipconfig.c:680). The function named in the finding,
ic_do_bootp_ext() (net/ipv4/ipconfig.c:919), is reached only from
ic_bootp_recv() (net/ipv4/ipconfig.c:1156) and is not modified here; the
diff contains no receive-path hunks, so this series neither introduces
nor worsens the issue.
The receive loop is:
u8 *opt = ext++;
if (*opt == 0)
continue;
ext += *ext + 1;
if (ext < end)
ic_do_bootp_ext(opt);
with end = (u8 *)b + ntohs(b->iph.tot_len) (net/ipv4/ipconfig.c:1078).
An option whose length byte overruns the remaining space drives ext to
or past end and is skipped. That is not the case the finding describes.
The truncated length in the finding is a short option length, not a
length greater than the remaining space. After switch (*ext++), ext
points at the length byte; the copies ignore it and memcpy a fixed-size
value at ext+1. Option 1 and 3 always memcpy 4 bytes
(net/ipv4/ipconfig.c:935 and :939); option 26 always memcpy 2 bytes
(:968). When that option still satisfies ext < end, those copies can
read past the declared option and past end. Options 1 and 3 do so even
at length 2; option 26 only at length 0 with 3 bytes remaining. With
skb->len == tot_len that is a real KASAN out-of-bounds read. It
predates this patch.
Since the receive-path issue is independent of the send-side overflow
addressed here, we have kept it out of this series.
Best regards,
Yuqi Xu
next prev parent reply other threads:[~2026-09-20 7:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 8:45 [PATCH net 0/1] net: ipconfig: bound DHCP option construction Yuqi Xu
2026-09-19 8:45 ` [PATCH net 1/1] " Yuqi Xu
2026-09-20 7:25 ` Yuqi Xu [this message]
2026-09-23 14:54 ` Simon Horman
2026-09-24 9:10 ` [PATCH net 0/1] " 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=20260920072503.60706-1-xuyuqiabc@gmail.com \
--to=xuyuqiabc@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=vega@nebusec.ai \
--cc=weir@nebusec.ai \
--cc=xuyq21@lenovo.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