|WARNING| net/bnxt: fix out-of-bounds read in TCAM get
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Mon Oct 5 19:18:51 CEST 2026
Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/170566
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-05
# DPDK Patch Review: net/bnxt: fix out-of-bounds read in TCAM get
## Summary
This patch fixes a critical buffer overflow vulnerability in the TCAM get operation.
The fix adds proper bounds checking, corrects byte order handling, and ensures early return on error.
---
## Errors
**1. Missing byte order conversion in array index calculation**
The array indexing in the final memcpy operations uses `*key_size` and `*remap_size`,
which now contain host-byte-order converted values.
However, the bounds check validates `resp.dev_data` against converted sizes,
so the memcpy indexing is correct.
Actually, re-reading the code: the memcpy operations are correct.
After the conversions at lines 1173-1174, `*key_size` and `*remap_size` hold host byte order values,
and those are what is used for the memcpy lengths and offsets.
This is correct.
*(Self-correction: this is not an error. Omitting from output.)*
---
## Warnings
**1. Integer overflow in bounds check not prevented by cast alone**
Line 1159-1160:
```c
if ((size_t)rte_le_to_cpu_16(resp.key_size) * 2 +
(size_t)rte_le_to_cpu_16(resp.result_size) > sizeof(resp.dev_data)) {
```
The cast to `size_t` occurs after `rte_le_to_cpu_16()` returns a 16-bit value.
If `resp.key_size` is 0x8000 or larger (from malicious firmware),
`key_size * 2` could overflow before the `size_t` cast,
though this would require a 16-bit overflow which wraps to a small value,
making the check pass when it should fail.
**Suggested fix:** Cast before multiplication:
```c
if ((size_t)rte_le_to_cpu_16(resp.key_size) * 2U +
(size_t)rte_le_to_cpu_16(resp.result_size) > sizeof(resp.dev_data)) {
```
The `2U` ensures the multiplication is performed in `size_t` width.
**2. Inconsistent error message format**
Lines 1161-1162, 1167:
```c
PMD_DRV_LOG_LINE(ERR, "%s: FW sizes exceed TCAM bounds, rc:%d",
__func__, rc);
```
The message says "rc:%d" but `rc` is -EINVAL (a negative error code).
DPDK error messages typically express the error as a positive value
or use the symbolic name.
**Suggested fix:** Either use `%s` with `strerror(-rc)` or positive value:
```c
PMD_DRV_LOG_LINE(ERR, "%s: FW sizes exceed TCAM bounds: %s",
__func__, strerror(-rc));
```
Or drop the rc entirely since it's always -EINVAL in this context:
```c
PMD_DRV_LOG_LINE(ERR, "%s: FW sizes exceed TCAM bounds",
__func__);
```
---
## Info
**1. Consider adding defensive assert on sizeof(resp.dev_data)**
The bounds check assumes `resp.dev_data` is the data array.
If the response structure changes in the future,
the check could silently become incorrect.
Consider adding a compile-time assertion to document the expected size relationship.
**2. Comment explaining the dev_data layout would improve maintainability**
The calculation `key_size * 2 + result_size` encodes the layout
(key, mask, remap) but this is implicit.
A brief comment would help future reviewers:
```c
/* dev_data layout: [key][mask][remap] */
if ((size_t)rte_le_to_cpu_16(resp.key_size) * 2U + ...
```
---
## Positive Observations
- The patch correctly identifies and fixes a serious security vulnerability
(out-of-bounds read, potential buffer overflow)
- Early return pattern on error prevents subsequent memcpy operations
from using invalid lengths
- Byte order conversion is now correctly applied to all uses
of firmware-supplied sizes
- The fix validates both buffer capacity (caller's buffers)
and source bounds (firmware response buffer)
- The cast to `size_t` at line 1159 addresses the `-Wsign-compare` warning
mentioned in the commit message
---
## Final Recommendation
The patch is a significant security improvement and should be merged
after addressing the integer overflow concern in Warning #1.
The message formatting in Warning #2 is a minor style issue.
More information about the test-report
mailing list