|WARNING| [v2] net/bnxt/tf_core: fix TCAM alloc-set key copy

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Tue Oct 20 09:19:23 CEST 2026


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

_AI Code Review_

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

## Review of DPDK Patch: net/bnxt/tf_core: fix TCAM alloc-set key copy

### ERRORS

**Error 1: Buffer overflow and incorrect copy**

The original code performs out-of-bounds reads and copies wrong amounts of data:

```c
memcpy(&data[0], &key, key_size * sizeof(uint32_t));
memcpy(&data[key_size], &mask, key_size * sizeof(uint32_t));
memcpy(&data[key_size * 2], &remap, remap_size * sizeof(uint32_t));
```

This is a serious correctness bug:
1. `&key` copies the pointer variable's address, not the data it points to
2. `key_size * sizeof(uint32_t)` multiplies byte counts by 4, copying 4x the intended amount
3. The destination offsets (`&data[key_size]`, `&data[key_size * 2]`) also use byte counts as array indices on a `uint8_t` array, which happens to be correct, but the copy lengths are still wrong

The fix correctly copies from the buffers and uses byte sizes:

```c
memcpy(&data[0], key, key_size);
memcpy(&data[key_size], mask, key_size);
memcpy(&data[key_size * 2], remap, remap_size);
```

However, the patch should verify that the total size `2 * key_size + remap_size` does not exceed the available space in `req.dev_data[]`. The original overflow would have been caught at runtime if bounds checking were enabled, but the fix removes that symptom without adding explicit validation.

**Suggested addition** (separate patch or additional change):

```c
if (2 * key_size + remap_size > sizeof(req.dev_data)) {
    PMD_DRV_LOG(ERR, "TCAM data size %u exceeds buffer capacity %zu\n",
                2 * key_size + remap_size, sizeof(req.dev_data));
    return -EINVAL;
}
```

This would prevent silent truncation if the HWRM request buffer is too small.

---

### WARNINGS

None.

---

### INFO

**Info 1: Pre-existing - Missing validation of buffer sizes**

The function does not validate that `key_size` and `remap_size` are reasonable values before performing the memcpy operations. If these are supplied by untrusted input (firmware, device descriptors, or user API), they should be bounds-checked against the available buffer space. This is pre-existing and not introduced by this patch.

**Info 2: Pre-existing - Inconsistent pointer/offset arithmetic**

The destination offset calculation uses byte counts as array indices (`&data[key_size]`), which works correctly because `data` is `uint8_t *`. However, the original code's use of `sizeof(uint32_t)` multiplier suggests the author may have been confused about units. Adding a comment explaining the offset calculation would improve clarity. This is pre-existing and not introduced by this patch.

---

### SUMMARY

The patch correctly fixes a critical bug where:
- Wrong source addresses (pointer variables instead of buffers) were copied
- Wrong lengths (4x the intended size) were used

The fix is correct as far as it goes, but consider adding bounds validation in a follow-up patch to prevent buffer overflows if `key_size` or `remap_size` are unexpectedly large.

Review-Result: ERROR


More information about the test-report mailing list