|WARNING| crypto/openssl: fix SM2 encryption output length

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Mon Oct 26 15:44:45 CET 2026


Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/172085

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-26

# DPDK Patch Review

## Correctness Issues

### Error: Uninitialized variable in new code path

```c
if (!EVP_PKEY_encrypt(cctx, NULL, &output_len,
        op->sm2.message.data, op->sm2.message.length))
    goto err_sm2;
```

The variable `output_len` is used here without being initialized. This is a local variable that must be set to a meaningful value before being passed to `EVP_PKEY_encrypt()` as an output parameter.

Looking at the surrounding code context, `output_len` should be initialized to the size of the output buffer before the first call (to query the required length), or declared/set just before use. The RSA path mentioned in the commit message likely declares it as `size_t output_len = 0;` or similar before the length query.

**Suggested fix:**
```c
output_len = 0;  /* or op->sm2.cipher.length if available */
if (!EVP_PKEY_encrypt(cctx, NULL, &output_len,
        op->sm2.message.data, op->sm2.message.length))
    goto err_sm2;
```

However, I cannot see the full function context to verify where `output_len` is declared or if there's a prior initialization that makes this safe. If `output_len` is already initialized earlier in the function (before this encryption operation), this finding is incorrect. But from the patch alone, the added code appears to use an uninitialized variable.

## Style and Process

### Info: Consider bounds check on queried length

After querying the required output length, consider verifying that `output_len` does not exceed `op->sm2.cipher.length` before the actual encryption call. This would be consistent with defensive programming practices for crypto operations where buffer sizes are externally controlled.

This is a hardening suggestion, not a required fix, as the OpenSSL API should handle this, but explicit validation prevents silent truncation or buffer issues.

---

**Note:** The patch addresses a real OpenSSL compatibility issue (buffer size query requirement in 3.6.3+). The core fix is correct in principle--querying the required length before calling with the actual buffer matches the RSA pattern. The only concern is the initialization state of `output_len` at the point of the new call.

Review-Result: ERROR


More information about the test-report mailing list