[PATCH 2/6] net: compare received length to sizeof(ip_hdr), not sizeof(ip_udp_hdr)

[Tom Rini]

On Fri, Oct 14, 2022 at 07:43:38PM +0200, Rasmus Villemoes wrote:

> While the code mostly/only handles UDP packets, it's possible for the
> last fragment of a fragmented UDP packet to be smaller than 28 bytes;
> it can be as small as 21 bytes (an IP header plus one byte of
> payload). So until we've performed the defragmentation step and thus
> know whether we're now holding a full packet, we should only check for
> the existence of the fields in the ip header, i.e. that there are at
> least 20 bytes present.
> 
> In practice, we always seem to be handed a "len" of minimum 60 from the
> device layer, i.e. minimal ethernet frame length minus FCS, so this is
> mostly theoretical.
> 
> After we've fetched the header's claimed length and used that to
> update the len variable, check that the header itself claims to be the
> minimal possible length.
> 
> This is probably how CVE-2022-30552 should have been dealt with in the
> first place, because net_defragment() is not the only place that wants
> to know the size of the IP datagram payload: If we receive a
> non-fragmented ICMP packet, we pass "len" to receive_icmp() which in
> turn may pass it to ping_receive() which does
> 
>   compute_ip_checksum(icmph, len - IP_HDR_SIZE)
> 
> and due to the signature of compute_ip_checksum(), that would then
> lead to accessing ~4G of address space, very likely leading to a
> crash.
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221128/84f3952f/attachment.sig>