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

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## PATCH: common/cpt: use timing-safe digest comparison

---

## Summary

The patch correctly replaces `memcmp()` with `rte_memeq_timingsafe()` for authentication tag verification in the CPT (crypto) driver. This addresses a timing side-channel vulnerability where `memcmp()` could leak information about how many bytes of the MAC match through early-return timing.

---

## Review Findings

### Errors

None.

### Warnings

None.

### Info

**1. Return value semantics correctly inverted**

The logic inversion is correct:
- `memcmp()` returns 0 on equal (success)
- `rte_memeq_timingsafe()` returns true (non-zero) on equal (success)

The patch properly inverts the condition from `if (memcmp(...))` (true when different) to `if (rte_memeq_timingsafe(...))` (true when equal).

**2. Appropriate use of constant-time comparison**

This is a MAC verification in a crypto driver completion path. The comparison gates acceptance of crypto operations based on an attacker-influenced MAC value. Using `rte_memeq_timingsafe()` instead of `memcmp()` is required per the cryptographic code guidelines.

**3. v2 changelog note**

The v2 changelog correctly notes that salt and MAC address comparison patches were dropped because those comparisons operate on non-secret data (algorithm parameters, network addresses) where timing-safe comparison is unnecessary. This shows proper understanding of when constant-time comparison is required.

---

## Conclusion

**PASS** - This patch correctly addresses a timing side-channel vulnerability in authentication tag verification. No issues found.