GHSA-FPH8-8R8J-JWFP
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-10 15:33In 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.
{
"affected": [],
"aliases": [
"CVE-2026-68292"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:20:18Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: prevent tstamp ring allocation for non-PF VSI types\n\nThe pf-\u003etxtime_txqs bitmap tracks which Tx queues have ETF (Earliest\nTxTime First) offload enabled. This bitmap is indexed by queue number\nand is set by ice_offload_txtime(), which only operates on PF VSI\nqueues.\n\nHowever, ice_is_txtime_ena() does not check the VSI type before\nconsulting the bitmap. When ETF offload is enabled on PF Tx queue 0,\nbit 0 is set in pf-\u003etxtime_txqs. During a subsequent PCI reset\nrebuild, the CTRL VSI\u0027s Tx queue 0 is reconfigured and\nice_is_txtime_ena() is called for that ring. Since it only checks\npf-\u003etxtime_txqs by queue index without distinguishing VSI type, it\nfinds bit 0 set and returns true, matching the PF VSI\u0027s ETF queue,\nnot the CTRL VSI\u0027s. This causes ice_vsi_cfg_txq() to spuriously\nallocate a tstamp_ring for the CTRL VSI ring.\n\nSince CTRL VSI rings have no associated netdev, ice_clean_tx_ring()\ntakes an early return at the !netdev check before reaching\nice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset\nleaks one 64-byte tstamp_ring.\n\nFix this by restricting ice_is_txtime_ena() to return true only for\nPF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.",
"id": "GHSA-fph8-8r8j-jwfp",
"modified": "2026-08-10T15:33:45Z",
"published": "2026-08-10T15:33:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68292"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/144539bbfd3cea1ab0fb6f5216d6004c1f4f029b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/684d4d0bda95a3fb21b3e29ff0f668f657707b54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0a21604c6abfa4956f3a511a1de174cec77a812"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.