Linux kernel ice: failed Tx scheduler config during XDP attach leaves stale rings and crashes in NAPI

CVSS 5.5CVE-2025-38127Kernel, userspace & hypervisorcurated

Impact

Attaching an XDP program to an Intel E810-class NIC adds Tx queues and must tell the Tx scheduler about them. When that configuration failed the driver did not unwind everything it had already changed: XDP queues stayed mapped to q_vectors and the xdp_rings pointer was left dangling, and the next ice_napi_poll() dereferenced it, producing a general protection fault and a host panic (trace from a two-socket Xeon server in the record). On a GPU node these are the datacenter NICs carrying tenant and storage traffic, and a panic takes the whole node and its resident jobs with it. The failure is in error handling, so it needs the scheduler config to fail; the record shows a crash, not a controllable write.

Who can reach it

Local privileged operation - loading or replacing an XDP program on an ice interface, which requires CAP_NET_ADMIN in the host network namespace. Not a tenant-reachable path on a normal node; the risk is to operators running XDP-based load balancers or observability on these NICs.

What to do

Update to a kernel with the fix (the linked commits unmap XDP queues from q_vectors, clear the rings pointer, and bail out immediately on ring-prep failure) and reboot the node. Until then treat XDP attach/detach on ice interfaces as a maintenance-window operation rather than something done on a node carrying live jobs. No separate vendor advisory in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-38127 https://git.kernel.org/stable/c/6bea620584f079d7aa3924ee191ea7ba25e02fc2 https://git.kernel.org/stable/c/1d3c5d0dec6797eca3a861dab0816fa9505d9c3e

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.