|WARNING| [v2] common/cpt: use timing-safe digest comparison

[dpdklab at iol.unh.edu]

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

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-08-17

# DPDK Patch Review: common/cpt: use timing-safe digest comparison

## Summary
This patch addresses a timing side-channel vulnerability in MAC verification by replacing `memcmp()` with `rte_memeq_timingsafe()`. The change is correct and necessary for cryptographic code.

---

## Errors

None.

---

## Warnings

**Missing release notes (Warning)**

This is a security fix for a cryptographic timing vulnerability. While it touches driver code, security fixes of this nature should be documented in the release notes to inform users of the improved security posture.

Add an entry to `doc/guides/rel_notes/release_<version>.rst` in the "Fixed Issues" section:

```rst
* **common/cpt: Fixed timing side-channel in MAC verification**

  Fixed a timing side-channel vulnerability in MAC verification where
  ``memcmp()`` could leak information about the number of matching bytes
  in the authentication tag. Replaced with constant-time comparison.
```

---

## Info

None - the patch is technically correct and follows the guidelines for cryptographic code review.

---

## Correctness Analysis

The patch correctly addresses the timing side-channel issue:

1. **Before**: `memcmp(mac, gen_mac, mac_len)` returns early on first differing byte, leaking timing information about how many leading bytes matched
2. **After**: `rte_memeq_timingsafe()` performs constant-time comparison, preventing timing analysis

The return value semantics are correctly inverted:
- `memcmp()` returns 0 when buffers match - success when result is false (`!memcmp()`)
- `rte_memeq_timingsafe()` returns true when buffers match - success when result is true

The status assignment logic is properly updated to reflect this.

---

## Removed Items from v1

The commit message indicates v2 dropped salt and MAC address comparison patches because those operate on non-secret data. This is the correct decision per the guidelines: timing-safe comparison is only required for comparisons that gate acceptance of attacker-influenced secret data (authentication tags, digests, MACs, ICVs). Salt values and MAC addresses are not secrets.