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

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