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.
