The previous part focused on bmcweb, which is an HTTPS-facing component. This one is a little different. CVE-2024-41660 is about slpd-lite, a lightweight Service Location Protocol responder.
The scary part is not that SLP is complicated. The scary part is that slpd-lite listens on UDP port 427 and parses unauthenticated packets. There is no TLS handshake, no login screen, and no HTTP session. A datagram arrives, the service parses it, and any parser bug is already in play.
The official OpenBMC advisory rates this as Critical. It states that OpenBMC systems including slpd-lite are affected, and that the package is installed by default when building OpenBMC.
Why This Service Matters
SLP is used for service discovery. In this OpenBMC context, slpd-lite acts as a unicast responder and handles requests such as service requests and service-type requests.
That sounds small, but I would not ignore it:
- UDP services receive data without a connection handshake.
- Discovery services are easy to forget in firewall rules.
- Length fields are attacker-controlled until proven otherwise.
- The parser runs on the BMC management plane.
- A BMC memory corruption bug has a much bigger blast radius than a normal discovery daemon crash.
In other words, this is exactly the kind of “small parser” that deserves extra attention.
SLP Packet Structure
The packet format itself is not the whole bug, but it shows where the bug comes from. Several fields describe lengths or offsets. Those values come from the packet sender.
The header fields highlighted in the slide deck are:
| Field | Offset | Size | Purpose |
|---|---|---|---|
| Version | 0 | 1 byte | SLP version |
| Function-ID | 1 | 1 byte | Message function code |
| Length | 2 | 3 bytes | Total SLP message length |
| Flags | 5 | 2 bytes | Flags and options |
| Next Ext Offset | 7 | 3 bytes | Offset of next extension |
| XID | 10 | 2 bytes | Transaction ID |
| Lang Tag Length | 12 | 2 bytes | Length of the language tag |
| Lang Tag | 14 | variable | Language tag bytes |
The rule should be boring: every claimed length must be checked against the actual received buffer before the parser reads or copies anything.
Normal Packet Versus Bad Packet
This slide is the core idea:
In a normal packet, the declared length and the available data agree. In a malicious packet, the declared length can be much larger than the actual datagram. If the parser trusts that declared length, it walks beyond the received buffer.
The parser entry point then has to be very strict:
Out-Of-Bounds Read
The first vulnerable pattern is in header parsing. The parser reads the language tag length, then uses it to copy the language tag.
If the packet says:
LangTagLen = 65535but the packet only contains:
Language Tag = "en"then the parser has a problem.
The safe check should be conceptually simple:
offset + langtagLen <= received_buffer_sizeBut even that check needs care. The addition must not overflow, and the types need to be wide enough to represent the real range.
Integer Truncation
The second pattern is more subtle, and I like it as a teaching example.
The vulnerable response-building flow calculates a response length, stores it in an 8-bit integer, allocates a buffer using the truncated value, and then copies data using the original larger length.
Here is the type problem:
If a value is stored in uint8_t, it can only represent 0 to 255. A larger value does not magically become safe. It wraps modulo 256.
The slide example uses a language tag length of 300:
Then the next slide shows the consequence:
In text form:
MIN_LEN: 14
langtag length: 300
error size: 2
calculated length: 316
uint8_t stored value: 316 mod 256 = 60
allocated buffer: 60 bytes
copied data length: 316 bytesAllocated size and copied size no longer match. That is an out-of-bounds write.
The slide deck summarizes the impact like this:
I would phrase it a little more carefully: exploitability depends on build settings, memory layout, allocator behavior, and service privileges. But because this is unauthenticated memory corruption on a BMC service, treating it as critical is reasonable.
Patch Direction
The official advisory points to a patch series in openbmc/slpd-lite, ending in commit 20bab74.
The commit message says the important thing directly: there are multiple user-provided length fields, and the parser must ensure those lengths do not exceed the input buffer size.
The patch direction is exactly what I would expect:
- check derived positions before reading
- reject claimed lengths larger than the real buffer
- avoid copying variable-length fields before bounds validation
- add parse errors instead of letting malformed packets continue
- add tests for the malformed cases
This is the same story as the bmcweb parser bug, just over UDP: the parser must trust the buffer size, not the packet’s claimed size.
What I Would Do
The clean fix is to install firmware or an OpenBMC build that includes the upstream slpd-lite patches. If that cannot happen immediately, I would block UDP 427 from untrusted networks. If SLP is not used at all, disabling the service is even better.
For a lab, checking and disabling it looks like this:
systemctl status slpd-lite.servicesystemctl disable --now slpd-lite.serviceFor the code, the rule is: trust the received buffer size, not the packet’s length fields. Check the offset before adding the length, use a type wide enough for the calculation, and never allocate with a truncated value while copying with the original one. That last mismatch is the whole integer-truncation bug in one sentence.
The tests should be just as direct: truncated headers, oversized language tags, maximum values, inconsistent total lengths, and weird offset combinations. If a UDP parser can be reached before authentication, those are not edge cases. Those are the cases.
Small unauthenticated parsers are easy to underestimate. On a BMC, they deserve the same attention as the obvious web interface.