u-boot.git/net, branch next

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

net: lwip/wget: don't print content size twice

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

If wget_info->silent is set, we should not print anything.

If wget_info->silent we print the received content size.
Printing the value of the Content-Length header is redundant

For chunked transfer no Content-Length header is sent.
The content length is returned as HTTPC_CONTENT_LEN_INVALID by the LwIP
library. In this case we were incorrectly printing '4 GiB'.

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

net: lwip/wget: missing linefeed in diagnostic output

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

With NET_LWIP wget produces this output with an overlong line
and missing white space:

    => wget $kernel_addr_r http://example.com/
    #################################################  4 GiB540 bytes transferred in 2 ms (263.7 KiB/s)
    Bytes transferred = 540 (21c hex)

Removing the condition on inserting a line feed yields:

    => wget $kernel_addr_r http://example.com/
    #################################################  4 GiB
    540 bytes transferred in 2 ms (263.7 KiB/s)
    Bytes transferred = 540 (21c hex)

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

net: nfs: fix buffer overflow in nfs_readlink_reply()

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

nfs_readlink_reply() validates rlen only against the incoming packet
length (inherited from CVE-2019-14195), but not against the destination
buffer nfs_path_buff[2048]. A malicious NFS server can send a valid
READLINK reply where pathlen + rlen exceeds sizeof(nfs_path_buff),
overflowing the BSS buffer into adjacent memory.

The recent fix in fd6e3d34097f addressed the same overflow class in
net/lwip/nfs.c but left the legacy path in net/nfs-common.c unpatched.

Add bounds checks before both memcpy calls in nfs_readlink_reply():
- relative path branch: reject if pathlen + rlen >= sizeof(nfs_path_buff)
- absolute path branch: reject if rlen >= sizeof(nfs_path_buff)

Fixes: cf3a4f1e86 ("net: nfs: Fix CVE-2019-14195")
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Alba Vives 
Reviewed-by: Jerome Forissier

simplify NET_LEGACY || NET_LWIP condition with NET condition

2026-04-27T17:26:40+00:00

Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.

SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.

Signed-off-by: Quentin Schulz 
Reviewed-by: Simon Glass 
Reviewed-by: Peter Robinson 
Reviewed-by: Tom Rini

net: make NET a menuconfig (and downgrade NO_NET to a simple config)

2026-04-27T17:26:40+00:00

This will allow a bunch of simplifications across the code base.
Disabling NET is the equivalent of today's NO_NET choice. This means
that if NET is enabled, either the legacy or lwIP stack is necessarily
selected, which allows us to simplify if NET_LEGACY || NET_LWIP into
if NET in a later commit.

Config fragments - or defconfigs including other defconfigs - setting
the network stack (NET_LEGACY or NET_LWIP) must also set NET (or unset
NO_NET) if the config they apply to - or the included defconfigs -
unsets NET (or selects NO_NET) as otherwise the NET_LEGACY and NET_LWIP
symbols are unreachable. This is the case for the two defconfig modified
in this commit.

NO_NET is now a convenience symbol which hides NET entirely to avoid
modifying many defconfigs. If one selected NO_NET to disable the
networking stack in the past, this will still work for now. Technically,
we should be using the "transitional" Kconfig attribute but that is only
available since Kconfig from Linux kernel v6.18 and we're on 6.1 right
now.

Note that this moves CONFIG_SYS_RX_ETH_BUFFER from under the Network
menu back into the main menu as it seems like it needs to be defined
even when there's no need for NET support at all and menuconfig option
doesn't work the same way as a menu.

Signed-off-by: Quentin Schulz 
Reviewed-by: Simon Glass 
Acked-by: Heinrich Schuchardt 
Reviewed-by: Peter Robinson 
Reviewed-by: Tom Rini

rename NET to NET_LEGACY

2026-04-27T17:26:40+00:00

Highlight that NET really is the legacy networking stack by renaming the
option to NET_LEGACY.

This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise
CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL.

The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is
using the legacy networking app so this seems fine to do.

This also has the benefit of removing potential confusion on NET being a
specific networking stack instead of "any" network stack.

Signed-off-by: Quentin Schulz 
Acked-by: Ilias Apalodimas 
Reviewed-by: Peter Robinson 
Reviewed-by: Tom Rini

move networking menu in net/Kconfig

2026-04-27T17:26:40+00:00

In the main Kconfig, there are only two more menus, General Setup and
Expert, in addition to the net menu. Since the part in the main Kconfig
is mostly about selecting the network stack (legacy or lwIP), and that
we already have a net/Kconfig, let's move those to net/Kconfig to have
everything in the same place.

No intended change in behavior.

Signed-off-by: Quentin Schulz 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Simon Glass 
Reviewed-by: Peter Robinson 
Reviewed-by: Tom Rini

net: lwip: tftp: update image_load_addr after successful transfer

2026-03-31T14:54:49+00:00

do_tftpb() parses the load address into a local variable laddr but
never updates the global image_load_addr. Commands that rely on
image_load_addr as their default address (e.g. 'bmp info')
therefore operate on the wrong address when called without
an explicit argument after tftpboot.

Update image_load_addr to laddr only on a successful transfer, so
that it accurately reflects where data was actually loaded.

Fixes: 4d4d7838127e ("net: lwip: add TFTP support and tftpboot command")
Signed-off-by: Pranav Sanwal 
Reviewed-by: Jerome Forissier

net: bootp: Drop unused code

2026-03-31T14:54:49+00:00

This code is surely unused and there are not even commented out
references to the function name. Drop the code.

Signed-off-by: Marek Vasut 
Reviewed-by: Heiko Schocher 
Reviewed-by: Kory Maincent 
Reviewed-by: Ilias Apalodimas