OpenSSL PMD SM2 overflow

https://bugs.dpdk.org/show_bug.cgi?id=2000

Bug ID: 2000
Summary: OpenSSL PMD SM2 overflow
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: cryptodev
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Group: security

Report date: 2026-03-11
Reported by: pengpeng <[email protected]>

Hello DPDK maintainers, I would like to report what appears to be a real current-head overflow in the OpenSSL PMD SM2 setup path. I rechecked current upstream head on 2026-03-10 before writing this report. The vulnerable code is:
```c uint8_t pubkey[65]; size_t len = 0; memset(pubkey, 0, sizeof(pubkey)); pubkey[0] = 0x04; len += 1; memcpy(&pubkey[len], xform->ec.q.x.data, xform->ec.q.x.length); len += xform->ec.q.x.length; memcpy(&pubkey[len], xform->ec.q.y.data, xform->ec.q.y.length); len += xform->ec.q.y.length; ``` The generic EC point type used here is: ```c struct rte_crypto_ec_point {
rte_crypto_param x; rte_crypto_param y; }; typedef struct { ...
size_t length; } rte_crypto_param; ``` So at this layer, the coordinate lengths are generic size_t values. I do not see a hard current-head type-level invariant in the generic API that forces both SM2 coordinates to be 32 bytes before this PMD code runs. I also checked the DPDK core asym session setup path, and it still directly dispatches to the PMD: ```c ret = dev->dev_ops->asym_session_configure(dev, xforms, sess); ``` That is why I do not think capability tables or helper APIs are enough to refute the bug. The PMD itself still appends x and y into a fixed pubkey[65] buffer with no local bound such as 1 + xlen + ylen <= sizeof(pubkey). Why I think this is a real current-head bug: - fixed stack buffer pubkey[65] - unchecked copies using caller-supplied coordinate lengths - generic create path still reaches the PMD directly - the overflow occurs before OpenSSL parameter building completes I am keeping the claim narrow: this is an SM2 PMD parameter-setup bug, not a claim that the generic API contract itself is invalid. The direct fix is to reject any coordinate pair where 1 + xform->ec.q.x.length + xform->ec.q.y.length > sizeof(pubkey) before the copies.

You are receiving this mail because:
You are the assignee for the bug.