GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF: LWT_SEG6LOCAL program can leave a dangling SRH pointer via bpf_skb_pull_data()

UnscoredCVE-2026-98383Kernel, userspace & hypervisorcurated

Impact

An LWT_SEG6LOCAL program could invalidate its cached segment-routing header with bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(), which may reallocate skb->head and leave the per-CPU SRH pointer dangling. Post-program SRH validation then writes through that freed pointer - a kernel write to stale memory on the packet path. The fix makes the verifier reject the helper combination for this program type; other LWT program types keep the helper. Exposure is narrow in practice: it needs SRv6 lightweight-tunnel routes with seg6local BPF actions configured, which most GPU fleets do not run. Where an operator does use SRv6 in the fabric or overlay, this is a kernel-memory-corruption bug on the datapath of the nodes carrying that routing.

Who can reach it

Local and privileged - loading an LWT_SEG6LOCAL program and installing the lightweight tunnel route requires CAP_BPF/CAP_NET_ADMIN in the host network namespace. Not reachable from a tenant GPU pod without those capabilities, and not reachable at all on hosts with no seg6local BPF routes.

What to do

Update to a stable kernel with the verifier fix (commits linked in the record) and reboot the affected nodes. If SRv6/seg6local is not in use - the common case - there is nothing to trigger and this can ride along with routine kernel maintenance. Otherwise prioritize the nodes carrying seg6local routes and keep CAP_NET_ADMIN off tenant workloads.

References

Related entries

All Kernel, userspace & hypervisor entries

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.