[PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

[PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

[qianjiaru77]

From: qianjiaru <qianjiaru77@gmail.com>

A state management vulnerability exists in the 
`bnxt_hwrm_reserve_vf_rings()` function of the Linux kernel's
bnxt_en network driver. The vulnerability causes incomplete 
resource state updates in SR-IOV Virtual Function (VF) environments,
potentially leading to system instability and resource allocation
 failures in virtualized deployments.

## Root Cause Analysis

The vulnerability exists in the VF resource reservation logic 
where older firmware versions receive incomplete state updates.

## Vulnerability Mechanism

1. **Incomplete State Update**: 
Old firmware path only updates `resv_tx_rings`, 
ignoring other critical fields
2. **Missing Hardware Sync**:
 No call to `bnxt_hwrm_get_rings()` to sync complete state  
3. **Inconsistent Resource Records**: 
`bp->hw_resc` structure contains stale/inconsistent values
4. **False Success**: 
Returns success without performing actual hardware resource reservation

## Missing State Updates

The vulnerable code fails to update these critical fields:

```c
struct bnxt_hw_resc {
    u16 resv_rx_rings;      // NOT UPDATED - stale value
    u16 resv_vnics;         // NOT UPDATED - stale value  
    u16 resv_rsscos_ctxs;   // NOT UPDATED - stale value
    u16 resv_cp_rings;      // NOT UPDATED - stale value
    u16 resv_hw_ring_grps;  // NOT UPDATED - stale value
    u16 resv_tx_rings;      // ONLY field updated
    // ... other resource fields also not updated
};
```

### Attack Scenario

1. **VF Configuration**:
 Administrator reconfigures VF network resources (RX/TX rings)
2. **Partial Update**: 
`bnxt_hwrm_reserve_vf_rings()` only updates TX ring count in `bp->hw_resc`
3. **State Inconsistency**: 
Other resource counters (RX, VNICs, RSS contexts) remain stale
4. **Subsequent Operations**: 
Other driver functions rely on incorrect resource state information
5. **Resource Allocation Failure**: 
Attempts to use resources based on stale state information fail
6. **System Impact**: 
VF network functionality degraded or system crashes

## Comparison with Similar Vulnerabilities

This vulnerability is part of the same 
**firmware compatibility anti-pattern** family as:

- **CVE-2024-44933**:
RSS table mismanagement due to firmware-specific logic
- **bnxt_rfs_capable() bypass**: 
Validation bypassed for old firmware versions

All share the common flaw:
incomplete logic paths for older firmware versions
that compromise system state integrity.

The pattern appears to be systematic in the bnxt driver
where legacy firmware support consistently introduces
 security vulnerabilities.

## Proposed Fix

The vulnerability should be fixed by 
ensuring complete state management 
for all firmware versions:

```c
// Current vulnerable code:
if (!BNXT_NEW_RM(bp)) {
    bp->hw_resc.resv_tx_rings = hwr->tx;
    return 0;
}

// Proposed secure fix:
if (!BNXT_NEW_RM(bp)) {
    // Update all relevant resource state, not just TX rings
    bp->hw_resc.resv_tx_rings = hwr->tx;
    bp->hw_resc.resv_rx_rings = hwr->rx;
    bp->hw_resc.resv_vnics = hwr->vnic;
    bp->hw_resc.resv_rsscos_ctxs = hwr->rss_ctx;
    bp->hw_resc.resv_cp_rings = hwr->cp;
    bp->hw_resc.resv_hw_ring_grps = hwr->grp;
    return 0;
}
```

## References

- **Related CVE**: 
CVE-2024-44933 (bnxt resource management)
- **Linux SR-IOV Documentation**: 
`Documentation/networking/sriov.rst`
- **Broadcom bnxt Driver**: 
`drivers/net/ethernet/broadcom/bnxt/`
- **PCI SR-IOV Specification**: 
PCI-SIG SR-IOV 1.1 specification

Signed-off-by: qianjiaru <qianjiaru77@gmail.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 207a8bb36..2d06b0ddc 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -7801,7 +7801,13 @@ bnxt_hwrm_reserve_vf_rings(struct bnxt *bp, struct bnxt_hw_rings *hwr)
 	int rc;
 
 	if (!BNXT_NEW_RM(bp)) {
+		// Update all relevant resource state, not just TX rings
 		bp->hw_resc.resv_tx_rings = hwr->tx;
+		bp->hw_resc.resv_rx_rings = hwr->rx;
+		bp->hw_resc.resv_vnics = hwr->vnic;
+		bp->hw_resc.resv_rsscos_ctxs = hwr->rss_ctx;
+		bp->hw_resc.resv_cp_rings = hwr->cp;
+		bp->hw_resc.resv_hw_ring_grps = hwr->grp;
 		return 0;
 	}
 
-- 
2.34.1

Re: [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

[Michael Chan]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Tue, Aug 26, 2025 at 9:25 AM <qianjiaru77@gmail.com> wrote:

> ## Root Cause Analysis
>
> The vulnerability exists in the VF resource reservation logic
> where older firmware versions receive incomplete state updates.
>
> ## Vulnerability Mechanism
>
> 1. **Incomplete State Update**:
> Old firmware path only updates `resv_tx_rings`,
> ignoring other critical fields
> 2. **Missing Hardware Sync**:
>  No call to `bnxt_hwrm_get_rings()` to sync complete state
> 3. **Inconsistent Resource Records**:
> `bp->hw_resc` structure contains stale/inconsistent values
> 4. **False Success**:
> Returns success without performing actual hardware resource reservation
>

I will review the driver's code path (!BNXT_NEW_RM(bp)) to support the
older FW that only requires reservations for the TX rings.  This FW is
generally about 7 years old.  More recently added code may not handle
this code path correctly and may have the issue that you pointed out.
Thanks.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4196 bytes --]

Re: [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

[Jakub Kicinski]

On Wed, 27 Aug 2025 00:25:41 +0800 qianjiaru77@gmail.com wrote:
> Subject: [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

If you want this to be merged please read process documentation, 
or at least git history for the relevant code and format the commit
message correctly. I'm dropping your 3 submissions from networking
patch review.