Answer in brief
CVE-2026-68292 records a Unknown severity vulnerability in ice: prevent tstamp ring allocation for non-PF VSI types. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <684d4d0bda95a3fb21b3e29ff0f668f657707b54 || >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <d0a21604c6abfa4956f3a511a1de174cec77a812 || >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <144539bbfd3cea1ab0fb6f5216d6004c1f4f029b | 684d4d0bda95a3fb21b3e29ff0f668f657707b54, d0a21604c6abfa4956f3a511a1de174cec77a812, 144539bbfd3cea1ab0fb6f5216d6004c1f4f029b |
| Linux/Linuxgeneric | 6.18 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-68292 records a Unknown severity vulnerability in ice: prevent tstamp ring allocation for non-PF VSI types. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <684d4d0bda95a3fb21b3e29ff0f668f657707b54 || >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <d0a21604c6abfa4956f3a511a1de174cec77a812 || >=ccde82e909467abdf098a8ee6f63e1ecf9a47ce5 <144539bbfd3cea1ab0fb6f5216d6004c1f4f029b | 684d4d0bda95a3fb21b3e29ff0f668f657707b54, d0a21604c6abfa4956f3a511a1de174cec77a812, 144539bbfd3cea1ab0fb6f5216d6004c1f4f029b |
| Linux/Linuxgeneric | 6.18 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.
Quoted source text, attributed separately from HOL analysis.