U-Boot: malicious NFS server overflows the boot-time NFS read buffer

CVSS 8.8CVE-2026-74220Firmware, BMC & network fabriccurated

Impact

A host that netboots over NFS trusts the reply lengths the server sends. Signed integer handling in nfs_read_reply() lets a malicious or impersonating NFS server bypass the length check and write far past the destination buffer, crashing the bootloader or corrupting pre-OS memory before any OS integrity control exists. On fleets where ARM control nodes, DPUs and diskless compute nodes PXE/NFS-boot from a provisioning network, whoever can answer as the NFS server - or sit in the path - influences code execution in the boot environment. Recovery is a console-level operation, not a reboot.

Who can reach it

Network position: whoever operates or can spoof the NFS server the node boots from, on the provisioning/management network. No authentication of the server is involved - U-Boot's NFS client trusts the reply.

What to do

Update U-Boot to 2026.10-rc5 or later, or backport commit 0bbf09859658. That means building and flashing the bootloader on each affected board with the node out of service, so it is a scheduled maintenance item per node, not a rolling restart. Until then, keep the NFS boot server on an isolated provisioning VLAN and prefer boot paths that do not use U-Boot's NFS client.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-74220 https://github.com/u-boot/u-boot/commit/0bbf09859658b8cc9ac13be41af23b516b8ef69a https://www.vulncheck.com/advisories/u-boot-before-2026.10-rc5-buffer-overflow-via-nfs-read-reply

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.