u-boot-toradex.git/net, branch master

net: cdp: reject CDP TLVs with a length below the 4-byte header

2026-06-23T11:13:16+00:00

cdp_receive() reads a 16-bit TLV length (tlen) from the packet and only
checks that it does not exceed the remaining buffer (tlen > len). It then
unconditionally does "tlen -= 4" to skip the TLV header. As tlen is a
u16, a crafted TLV with a length of 0..3 underflows tlen to ~65532-65535.

For a CDP_APPLIANCE_VLAN_TLV the underflowed length then drives the inner
"while (tlen > 0)" loop, which walks ~64KB past the receive buffer reading
*ss each step -> out-of-bounds read (crash / info-influence). A length of
0 additionally fails to advance pkt/len, hanging the parse loop.

Reject any TLV whose declared length is smaller than its own 4-byte
header. This is the same class of bug as the recent bootp/dhcpv6/sntp/nfs
fixes (unchecked length field), in a sibling LAN parser that was missed.

Verified with a standalone AddressSanitizer harness using the verbatim
cdp_receive()/cdp_compute_csum() routines: a 16-byte CDP frame with an
appliance-VLAN TLV of length 3 triggers a heap-buffer-overflow READ that
the check eliminates.

Fixes: f575ae1f7d39 ("net: Move CDP out of net.c")
Cc: stable@vger.kernel.org
Signed-off-by: Piyush Paliwal 
Reviewed-by: Jerome Forissier

net: lwip: introduce net_lwip_eth_stop() function

2026-06-23T11:13:16+00:00

Add a introduce net_lwip_eth_stop() function and use that to stop the
network interface after each command that uses the network.

This makes the behavior the same as the legacy net code and avoids
potential issues with the network interface being left in an active
state after a command finishes.

The start/stop is reference-counted since there is at least one command
(dhcp) that calls another command (tftp) to avoid starting and stopping
the network interface multiple times in a single command.

Signed-off-by: David Lechner 
Reviewed-by: Jerome Forissier

net: lwip: wget: return errno codes from wget_do_request()

2026-06-23T11:13:16+00:00

Change the return values of the lwip implementation of wget_do_request()
to be errno codes instead of command return codes.

wget_do_request() is not a command, so it does not make sense to return
command return codes from it. Also, the legacy network implementation of
wget_do_request() already returns errno codes so it is logical for the
lwip implementation to do the same.

This fixes a bug in try_load_from_uri_path() in efi_manager.c where it
checks that the return value of wget_do_request() is < 0. Before this
change, CMD_RET_FAILURE would not be considered an error since it has a
value of 1.

The value of ENODEV is used in places where there could actually be a
number of different causes of failure and it isn't possible to
discriminate (i.e. failing function returns NULL for all errors). Since
all callers of wget_do_request() don't propagate the error code, it
doesn't matter so much that this is not ideal, at least at this point in
time.

Fixes: 3c656c928bd7 ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier 
Signed-off-by: David Lechner

net: lwip: wget: fix error handling in wget_do_request()

2026-06-23T11:13:16+00:00

Split wget_do_request() into two functions to make error handling less
error-prone.

After a successful call to net_lwip_new_netif(), net_lwip_remove_netif()
must always be called to prevent leaks. This was missed in the CACERT
section of the code where we returned on error without cleaning up.

Instead of adding more calls to net_lwip_remove_netif(), refactor the
code into two functions. The outer function handles managing the netif
lifecycle. The inner function no longer has to worry about cleaning up
before returning on error.

To keep things simple, the `path` local variable is removed during the
refactoring. Instead, ctx.path is used directly everywhere.

Fixes: 3c656c928bd7 ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier 
Acked-by: Ilias Apalodimas 
Signed-off-by: David Lechner

net: clear IP defragmentation state after returning a complete packet

2026-06-23T11:13:16+00:00

During the IP defragmentation process, after the reassembly is finished
with the last packet arriving with MF=0, the reassembly state wrt.
static counters is not cleared. In case this last arriving packet with
MF=0 gets duplicated, payload bytes are mistakenly treated as hole data.

A malicious actor who can deliver fragmented IP traffic to a U-Boot
instance with CONFIG_IP_DEFRAG=y can corrupt memory via out-of-bound
writes and redirect control flow into attacker-supplied payload bytes
that already sit in `pkt_buff[]`.

Publicly available AI models are able to generate a reproducer based
on the provided information.

Fix: once the assembled packet has been handed back to the caller, mark
the reassembly state empty so that any further fragment (duplicate,
replay, or a brand-new datagram that happens to reuse the `ip_id`) goes
through the normal re-init path and rebuilds a clean hole list instead
of dereferencing payload bytes as struct hole.

Fixes: 5cfaa4e54d0e ("net: defragment IP packets")
Reported-by: Mariusz Madej 
Reviewed-by: Simon Glass 
Acked-by: Alessandro Rubini 
Signed-off-by: Mateusz Furdyna

net: bootp: Prevent out-of-bounds read in dhcp_message_type

2026-06-03T15:22:24+00:00

dhcp_message_type() scans DHCP options looking for a 0xff
end-of-options marker with no check that the scan pointer stays
within the received packet. A server can send a crafted OFFER with
no 0xff terminator and large option length fields, advancing the
pointer past bp_vend[312] into adjacent heap memory.

This is the same class of bug as CVE-2024-42040, which fixed the
related bootp_process_vendor() call site. Fix it by adding an end
parameter to dhcp_message_type() and checking that popt is lower
than end.

Signed-off-by: Francois Berder 
Reviewed-by: Jerome Forissier

net: dhcpv6: Prevent out-of-bounds reads while parsing options

2026-06-03T15:22:24+00:00

dhcp6_parse_options() verifies that an option's declared data fits
within the packet, but does not check that option_len is large
enough for the fixed-size read each case performs. A malicious
DHCP server can send an ADVERTISE with a zero-length IA_NA,
STATUS_CODE, SOL_MAX_RT, or BOOTFILE_PARAM option, causing the
parser to read 2-4 bytes past the option's declared data.

Check option_len value before each dereference of option_ptr.

Signed-off-by: Francois Berder

net: dhcpv6: Prevent buffer overflow during BOOTFILE_URL parsing

2026-06-03T15:22:24+00:00

The net_boot_file_name is a 1024 byte buffer.
However, based on DHCPv6 RFC, bootfile-url length is
specified by option_len, a 16-bit unsigned integer
(valid range: 0-65535).
Hence, one needs to make sure that option_len is less
than the size of net_boot_file_name array before copying
bootfile-url to net_boot_file_name.

Signed-off-by: Francois Berder 
Reviewed-by: Jerome Forissier

net: sntp: Check packet length in sntp_handler

2026-06-03T15:22:24+00:00

Currently, the sntp_handler uses data in the UDP packet
regardless of the actual packet size. A OOB read can occur
if the packet is too small.
Fix it by checking the packet length before extracting
seconds from a SNTP packet.

Signed-off-by: Francois Berder 
Reviewed-by: Jerome Forissier

net: lwip/wget: don't print progress bar when silent

2026-05-06T09:07:22+00:00

When the EFI sub-system request to silence output, do not output a progress
bar.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Jerome Forissier