Products
| Product | |
| 1 | Huawei openUBMC 26.06 |
CVE
CVE-2026-65198, CVE-2026-65199, CVE-2026-65200Executive summary #
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.
This issue is an instance of CWE-191 (Integer Underflow), has an estimated CVSSv3.1 score of CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L (3.5, Low), and current SSVC vectors of "Exploitation: PoC" and "Technical Impact: Partial."
Technical details #
Each affected parser guards the response length only against zero (or against the header size) and then subtracts a larger fixed amount, so a response just above the header size underflows the unsigned difference.
In pldm_over_mctp/pldm_base_over_mctp.cpp, pldm_base_over_mctp::pldm_base_get_ver_single_requst validates only rsp_str.size() >= sizeof(pldm_get_ver_rsp_dat_t) and then passes data_len = rsp_str.size() - sizeof(pldm_get_ver_rsp_dat_t) (which may be 1 to 3) into two helpers. pldm_base_check_version_valid computes crc32_pldm(0xFFFFFFFF, version_data, data_len - 4) and dereferences &version_data[data_len - 4] after checking only data_len == 0, so data_len of 1 to 3 makes data_len - 4 a value near 2^32 and the CRC routine reads far past the buffer. fill_version_table computes size_t remaining_len = data_len - 4 before its remaining_len < 4 guard, so the wrapped value passes the guard and the for (uint8_t i = 0; i < remaining_len / 4; i++) version_entries.push_back(data_ptr[i]); loop reads out of bounds until the uint8_t counter wraps at 256, roughly one kilobyte past version_data.
In ncsi_over_mctp/ncsi_over_mctp_huawei.cpp, the OEM GET_LOG reassembler guards only response.size() >= sizeof(oem_huawei_public_rsp_t) and then computes size_t actual_data_size = response.size() - sizeof(oem_huawei_public_rsp_t) - 7. A response length in [sizeof(oem_huawei_public_rsp_t), sizeof(oem_huawei_public_rsp_t) + 6] wraps actual_data_size, passes the following actual_data_size > 0 check, and log_data.append(reinterpret_cast<const char*>(log_rsp->data), actual_data_size) performs a large out-of-bounds heap read.
PLDM GET_PLDM_VERSION response:
total length = sizeof(pldm_get_ver_rsp_dat_t) + 1..3 bytes
parser result = data_len - 4 wraps; crc32_pldm and fill_version_table read out of bounds
NCSI OEM GET_LOG response:
total length = sizeof(oem_huawei_public_rsp_t) + 0..6 bytes
parser result = actual_data_size wraps; log_data.append reads out of boundsAttacker value #
An attacker controlling a peripheral’s responses on the internal MCTP bus can likely cause repeatable denial of service by returning undersized PLDM or Huawei NCSI replies during device discovery or log collection. The resulting length underflows can trigger invalid memory reads or resource exhaustion, potentially crashing the BMC device-management service whenever the peripheral is queried. A Heartbleed-style disclosure of BMC heap contents is a possible secondary impact, but requires out-of-bounds data to reach an attacker-accessible output; no such disclosure has been demonstrated. No arbitrary memory-write or code-execution capability has been established.
Credit #
This issue was discovered by HD Moore with the help of AI tools. Disclosure was coordinated by Tod Beardsley.
Timeline #
- 2026-07-18: Initial findings discovered and documented
- 2026-07-21: CVE-2026-65200 reserved
- 2026-08-05: Disclosed to CISA (VU#415695)
- 2026-08-28: CISA declined to pursue coordination with a sanctioned entity
- 2026-10-13: Public disclosure