|WARNING| crypto/cnxk: changes to align with zuc256 v2 auth

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Summary

This patch modifies the crypto/cnxk driver to align with ZUC-256 v2 authentication microcode support. I have identified several issues below.

---

## ERRORS

### 1. Missing array bounds check in `cpt_zuc_const_update()`

**Location:** `drivers/common/cnxk/roc_se.c:258`

```c
if (key_len == 32 && roc_model_is_cn20k()) {
    memcpy(zuc_const, zuc_key256_v2, 16);
    return;
}
```

The code copies 16 bytes from `zuc_key256_v2` into `zuc_const`, but neither the size of `zuc_key256_v2` nor the size of `zuc_const` is verified. If `zuc_key256_v2` is smaller than 16 bytes or if `zuc_const` buffer is smaller than 16 bytes, this results in a buffer overflow.

**Required:** Verify that both arrays are at least 16 bytes, or document the required buffer sizes in the function comment.

---

### 2. Undefined symbol `zuc_key256_v2`

**Location:** `drivers/common/cnxk/roc_se.c:258`

```c
memcpy(zuc_const, zuc_key256_v2, 16);
```

The symbol `zuc_key256_v2` is used but is not defined anywhere in this patch. This will cause a compilation failure unless it exists in code not shown in this patch.

**Required:** Either:
- Define `zuc_key256_v2` in this patch, or
- Ensure the patch series includes its definition in a preceding patch, or
- Provide evidence that this symbol already exists in the codebase

---

### 3. Inconsistent PDCP IV configuration between initialization and capability advertisement

**Location:** `drivers/crypto/cnxk/cnxk_cryptodev_ops.c:675-676`

The patch changes the initialization:
```c
sess->roc_se_ctx->pdcp_iv_offset = 16;
sess->roc_se_ctx->pdcp_iv_len = 32;
```

But the capability update in `cnxk_cryptodev_capabilities.c:2094-2097` sets:
```c
if (roc_model_is_cn20k())
    caps->sym.auth.iv_size.max = 16;
else
    caps->sym.auth.iv_size.max = 25;
```

The capability advertises `iv_size.max = 16` for cn20k, but the session initialization sets `pdcp_iv_len = 32`. This is a mismatch: the driver advertises support for up to 16-byte IVs but internally configures 32 bytes. Applications relying on the capability will be misled.

**Required:** Either:
- Change `caps->sym.auth.iv_size.max` to 32 to match the internal configuration, or
- Change `pdcp_iv_len` to 16 to match the advertised capability, or
- Explain why these values differ and document the relationship

---

## WARNINGS

### 1. Missing release notes update

**Location:** Entire patch

This patch changes driver behavior for ZUC-256 authentication on cn20k hardware, including changes to supported IV sizes and internal configuration. This is a functional change that affects applications.

**Required:** Add a release notes entry in `doc/guides/rel_notes/release_XX_YY.rst` documenting:
- The ZUC-256 v2 authentication support
- The change in IV size handling for cn20k
- Any implications for existing applications

---

### 2. Capability change without deprecation notice

**Location:** `drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c:2094-2097`

The patch reduces the maximum IV size for ZUC-EIA3 authentication from 25 bytes to 16 bytes on cn20k:
```c
if (roc_model_is_cn20k())
    caps->sym.auth.iv_size.max = 16;  /* was 25 */
else
    caps->sym.auth.iv_size.max = 25;
```

This is a capability reduction that could break existing applications that were using IV sizes between 17 and 25 bytes.

**Required:** Either:
- Document this as a breaking change in release notes, or
- Provide evidence that IV sizes > 16 were never functional on cn20k, making this a bug fix rather than a capability reduction

---

### 3. Magic numbers without explanation

**Location:** `drivers/crypto/cnxk/cnxk_cryptodev_ops.c:675-676`

```c
sess->roc_se_ctx->pdcp_iv_offset = 16;
sess->roc_se_ctx->pdcp_iv_len = 32;
```

The values 16 and 32 are hardcoded without explanation. Previously the code had `pdcp_iv_len = 40` and `pdcp_iv_offset = 16`. The change from 40 to 32 is not explained.

**Suggested:** Add a comment explaining why cn20k requires these specific offset and length values, and how they relate to the ZUC-256 v2 specification.

---

## INFO

### 1. Code structure note

The early return in `cpt_zuc_const_update()` at line 260 is good practice for the new cn20k path. However, readers should note that this changes the function's control flow such that when `key_len == 32` on cn20k, the subsequent `else if (key_len == 32)` branch at line 266 becomes unreachable for cn20k, which is the intended behavior.

---

## FINAL CHECK

**Evidence verification:**
- Error 1: The `memcpy()` at line 258 is in the patch; buffer size verification is missing
- Error 2: `zuc_key256_v2` usage at line 258 is in the patch; definition is not visible
- Error 3: IV size mismatch between lines in cnxk_cryptodev_capabilities.c:2094 and cnxk_cryptodev_ops.c:676
- Warning 1: No release notes file present in this patch
- Warning 2: Capability reduction at line 2095 changes advertised max from 25 to 16
- Warning 3: Magic numbers at lines 675-676 lack explanation

All findings rest on code present in the patch or its absence where required.

---

Review-Result: ERROR