CVE-2026-97979: ice: add missing xa_destroy for sched_node_ids
In the Linux kernel, the following vulnerability has been resolved:
ice: add missing xadestroy for schednodeids
Commit 16dfa49406bc ("ice: Introduce new parameters in iceschednode") added a schednodeids xarray to the port info structure, but never called xadestroy 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 portinfo structure. This appears to have been done because its use is within functions that take the portinfo as a primary argument.
However, this complicates managing the lifecycle of the field. The portinfo structure is allocated in iceinithw() using devm, and it is not released until the devm cleanup when the driver is unloaded.
The iceinithw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout.
Adding a call of xadestroy to the icedeinithw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that portinfo could be a dangling reference.
To handle this, move the schednodeids out of portinfo and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one schednodeids per adapter. While here, remove the overly verbose comment explaining the nature of the schednodeids xarray.
Add the missing xadestroy to the cleanup path and to icedeinithw(), ensuring that we properly release the xarray memory.
This was caught by Sashiko during development of unrelated code.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Move the sched_node_ids xarray from port_info into the hw structure, and call xa_destroy on it in the cleanup path and in ice_deinit_hw() to release xarray internal memory.
Event History
Frequently Asked Questions
Which systems are most likely to accumulate the leaked memory?
Systems using the Linux kernel ice driver are most exposed when ice_init_hw() is invoked repeatedly. The description specifically identifies devlink reload as one such path, and notes that DDP loading after a Tx scheduler layout update may also invoke it.
What can be done if the fix cannot be applied immediately?
Minimize repeated devlink reload operations on affected systems, since they can reinitialize the hardware while the port_info allocation remains until the driver is unloaded. Also review workflows that load DDP packages after Tx scheduler layout changes, as this may be another initialization path.