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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

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@prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]