[DPDK/cryptodev Bug 2000] OpenSSL PMD SM2 overflow

[bugzilla@dpdk.org]

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: dev@dpdk.org
          Reporter: thomas@monjalon.net
  Target Milestone: ---
             Group: security

Report date: 2026-03-11
Reported by: pengpeng <pengpeng@iscas.ac.cn>

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.