Database/Firmware, BMC & network fabric

Intel Xeon system firmware: insufficient input validation lets a privileged local user escalate out of the OS
Impact
Insufficient input validation in Intel system firmware (UEFI, 2019.2 IPU) on Xeon Scalable, Xeon D, Xeon E5/E7 v4 and Atom C parts lets a privileged local user escalate privilege, cause denial of service, or disclose information. The CVSS scope-change flag (S:C) means the effect reaches past the OS boundary - a root or ring-0 attacker on a GPU host can reach firmware-level state the host OS is supposed to be unable to touch, which undermines any trust an operator places in host attestation or in reimaging a node to clean it. On a GPU fleet this matters most for nodes that are rented out bare metal or re-tenanted between customers: a previous tenant who obtained host privilege could leave persistence that survives a reinstall. The record is the generic Intel SA-00280 wording and does not name a specific firmware module or exploitation path.
Who can reach it
Local, authenticated, and already privileged on the host (root/administrator or equivalent ring-0 access). Not reachable by an unprivileged tenant process or over the network; relevant on bare-metal nodes handed to customers, or as a post-exploitation step after any host-level compromise.
What to do
Apply the OEM BIOS/system-firmware update that carries the Intel 2019.2 IPU microcode and firmware package - Intel does not ship it to end users directly, so the fix arrives as a vendor BIOS release (HPE published emr_na-hpesbhf03967en_us, other OEMs equivalently). This is a firmware flash per node: take the node out of service, flash BIOS, reboot, and verify the firmware version afterwards. There is no runtime mitigation; the only partial control is denying untrusted parties host-privileged access in the first place. This is a 2019 advisory, so most fleets will already be past it - verify the installed BIOS version rather than assuming.
References
Related entries
- GRUB2: Buffer overflow in `grub.cfg` parsing allowing Secure Boot bypass and arbitrary code execution inside GRUBCVE-2020-10713 · GRUB2High
- GRUB2 (direct kernel boot without shim): When GRUB is booted directly by UEFI rather than chained through shim, it doesCVE-2020-15705 · GRUB2 (direct kernel boot without shim)High
- Cisco NX-OS (BGP MD5 authentication): BGP MD5 authentication can be bypassed, so an attacker can bring up a BGP sessionCVE-2020-3165 · Cisco NX-OS (BGP MD5 authentication)High
- Dell client and server BIOS - NVMe drive password (SED credential) defeated by resetting the BIOS passwordCVE-2021-21522 · Dell client and server BIOS - NVMe drive password (SED credential) defeated by resetting the BIOS password via the…High
- Insyde InsydeH2O (FwBlockServiceSmm): Software SMI services reachable through EFI_SMM_COMMUNICATION_PROTOCOL neverCVE-2021-33627 · Insyde InsydeH2O (FwBlockServiceSmm)High
- InsydeH2O: HDD password is stored in plaintext in a UEFI variable readable from the OSCVE-2021-38489 · InsydeH2O UEFI firmware (HDD password stored in a UEFI variable)High
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.