mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: qianjiaru77@gmail.com
To: michael.chan@broadcom.com, pavan.chebbi@broadcom.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, andrew+netdev@lunn.ch
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	qianjiaru <qianjiaru77@gmail.com>
Subject: [PATCH 1/1] VF Resource State Inconsistency Vulnerability in Linux bnxt_en Driver
Date: Wed, 27 Aug 2025 00:25:41 +0800	[thread overview]
Message-ID: <20250826162541.34705-1-qianjiaru77@gmail.com> (raw)

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


             reply	other threads:[~2025-08-26 16:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26 16:25 qianjiaru77 [this message]
2025-08-26 23:32 ` Michael Chan
2025-08-27  0:02 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250826162541.34705-1-qianjiaru77@gmail.com \
    --to=qianjiaru77@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®