GHSA-F354-573P-458P
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In the Linux kernel, the following vulnerability has been resolved:
ice: add missing xa_destroy for sched_node_ids
Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it.
Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed.
The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument.
However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded.
The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout.
Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference.
To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray.
Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory.
This was caught by Sashiko during development of unrelated code.
{
"affected": [],
"aliases": [
"CVE-2026-97979"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:25Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: add missing xa_destroy for sched_node_ids\n\nCommit 16dfa49406bc (\"ice: Introduce new parameters in ice_sched_node\")\nadded a sched_node_ids xarray to the port info structure, but never called\nxa_destroy on it.\n\nSince xarrays can allocate internal memory, this can result in a memory\nleak even if every element in the xarray has been removed.\n\nThe xarray is currently embedded in the port_info structure. This appears\nto have been done because its use is within functions that take the\nport_info as a primary argument.\n\nHowever, this complicates managing the lifecycle of the field. The\nport_info structure is allocated in ice_init_hw() using devm, and it is\nnot released until the devm cleanup when the driver is unloaded.\n\nThe ice_init_hw() function is called in many places, including devlink\nreload, and possibly during DDP load after updating the Tx scheduler\nlayout.\n\nAdding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise\nmultiple concerns due to potential ordering issues and possible ways that\nport_info could be a dangling reference.\n\nTo handle this, move the sched_node_ids out of port_info and into the hw\nstructure. All users of the array already have a pointer to hw anyways, and\nthere is only one sched_node_ids per adapter. While here, remove the overly\nverbose comment explaining the nature of the sched_node_ids xarray.\n\nAdd the missing xa_destroy to the cleanup path and to ice_deinit_hw(),\nensuring that we properly release the xarray memory.\n\nThis was caught by Sashiko during development of unrelated code.",
"id": "GHSA-f354-573p-458p",
"modified": "2026-09-25T12:31:31Z",
"published": "2026-09-25T12:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97979"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44cdd6b7e036303f7fecf841cf23c05a4a4faf2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53432c4c3e869076350aef319534431af8ba99c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6f38fb12069fb1edf762962b5fcf3f42d643b47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5463bc124c0d6f922e272336584730c5c61c4f1"
}
],
"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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.