linux-kernel - [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250826162541.34705-1-qianjiaru77@gmail.com>
Date: Wed, 27 Aug 2025 00:25:41 +0800
From: qianjiaru77@...il.com
To: michael.chan@...adcom.com,
	pavan.chebbi@...adcom.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	andrew+netdev@...n.ch
Cc: netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	qianjiaru <qianjiaru77@...il.com>
Subject: [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver

From: qianjiaru <qianjiaru77@...il.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@...il.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