GPU VulnDB

Database/Firmware, BMC & network fabric

OpenBMC slpd-lite (Service Location Protocol daemon, UDP 427): slpd-lite is a small SLP responder that OpenBMC installs

CVSS 9.8CVE-2024-41660Firmware, BMC & network fabricGHSA-wmgv-jffg-v3xrcurated

Impact

slpd-lite is a small SLP responder that OpenBMC installs by default, and it overflows memory on crafted UDP packets. Because it is in the default build, this is not a niche configuration - if your image came from an OpenBMC tree and nobody explicitly removed the package, the daemon is listening. Unauthenticated remote memory corruption in a BMC-resident network daemon is the entry point that everything else in this cluster builds on: get code running on the BMC, then use the LPC-control or crypto kernel bugs to reach BMC root, then write flash and persist across tenant handover.

Who can reach it

Unauthenticated, network, UDP port 427 on the BMC's management interface. Nothing on the host and no credentials required. SLP is a discovery protocol nobody in a modern GPU fleet actually uses, which makes the exposure pure cost.

What to do

Two moves and the cheap one is very cheap. Config-only: block UDP 427 at the management-VLAN boundary and, better, remove slpd-lite from the image or stop and mask the service. It provides nothing an operator needs - Redfish discovery does not depend on it. The durable fix is upstream in the slpd-lite repository and reaches nodes through a BMC firmware flash: per node, out-of-band, ODM-lagged. Do the ACL and service disable now; batch the flash.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-41660https://github.com/openbmc/slpd-lite/security/advisories/GHSA-wmgv-jffg-v3xr

Related entries

All Firmware, BMC & network fabric entries

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.