Re: [PATCH net 1/1] net: ipconfig: bound DHCP option construction

[Simon Horman <horms@kernel.org>]

On Sun, Sep 20, 2026 at 03:25:03PM +0800, Yuqi Xu wrote:
> 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.

Yes, agreed.

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