|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