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
next 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®