CVE-2026-65200 in openBMC
Summary
by MITRE • 10/13/2026
The openUBMC device-management process parses PLDM-over-MCTP and NCSI-over-MCTP responses from on-bus devices, and three response parsers in the shared transport libraries subtract a fixed header or reserved-field size from a device-supplied response length without a lower-bound check. An undersized response wraps the unsigned length difference to a very large value, and the parser then reads far past the response buffer. The affected code sits in the base (non-vendor) PLDM control class and the Huawei NCSI driver, so it is reachable for any PLDM endpoint or Huawei NIC on the internal management bus, unlike the vendor-specific wangxun parser tracked separately.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability resides within the openUBMC device-management process, specifically affecting its handling of Protocol Data Unit over Management Component Transport Protocol (PLDM-over-MCTP) and Network Controller Sideband Interface over MCTP responses from on-bus devices. The core technical flaw is located in shared transport libraries that contain three distinct response parsers responsible for processing these incoming messages. These parsers are designed to extract payload data by subtracting a fixed header size or reserved field length from the total device-supplied response length to determine the valid payload boundary. However, this arithmetic operation lacks any validation logic to ensure the resulting value remains non-negative. This absence of a lower-bound check creates a critical integer underflow condition when an attacker supplies a malformed response with a length smaller than the fixed header size being subtracted.
When such an undersized response is processed, the unsigned integer subtraction wraps around to produce a very large positive value due to standard two's complement arithmetic behavior in C-based systems. Consequently, the parser interprets this wrapped value as the legitimate length of data to read from the buffer. This leads directly to a heap or stack out-of-bounds read vulnerability, where the application attempts to access memory locations far beyond the allocated response buffer boundaries. The affected code is situated within the base non-vendor PLDM control class and the Huawei NCSI driver, making it broadly applicable across various hardware configurations that utilize these standard drivers rather than being limited to specific vendor implementations like the wangxun parser which was tracked separately.
From an operational impact perspective, this vulnerability allows for potential information disclosure if the out-of-bounds read accesses sensitive memory contents such as kernel pointers or cryptographic keys stored in adjacent buffers. Furthermore, depending on the exact memory layout and subsequent usage of the corrupted data pointer, it may facilitate remote code execution by allowing an attacker to influence control flow through carefully crafted malformed packets sent over the internal management bus. Since PLDM endpoints and Huawei NICs are accessible via the out-of-band management interface, this vulnerability can potentially be exploited remotely if the BMC network is exposed or compromised, posing a significant risk to server infrastructure security.
This flaw aligns with Common Weakness Enumeration CWE-190 (Integer Overflow or Wraparound) as the root cause and leads to CWE-125 (Out-of-bounds Read) in terms of exploitation mechanics. In the context of the MITRE ATT&CK framework, this vulnerability supports techniques related to Discovery for information gathering via memory scraping and potentially Execution if the out-of-bounds read is leveraged for arbitrary code execution through heap or stack corruption. Mitigation strategies should prioritize applying vendor-provided patches that introduce strict bounds checking before performing length calculations in the PLDM and NCSI parsers. Additionally, implementing input validation at the MCTP transport layer to reject messages with invalid lengths can provide defense-in-depth. Security teams should also consider network segmentation for BMC interfaces to limit exposure of these management protocols to untrusted networks until patches are deployed.