The CVSS 9.8 rating for CVE-2026-74406 needs recalibration before you allocate patch resources. The vulnerability — a race between udp_tunnel_sock_release() and vxlan_gro_prepare_receive() during GRO batch processing — is real, but the severity score assumes arbitrary code execution from the null dereference. That assumption is wrong for this specific code path.
The practical failure mode here is kernel panic, not controlled exploitation. During active GRO session processing, the kernel's reference counting and RCU grace periods make the race window's interior state unpredictable to an attacker. You're not looking at a use-after-free where you can engineer controlled allocations — you're looking at a null dereference that crashes the kernel, period. This transforms the CVE from an RCE candidate into a remote DoS vector.
That distinction matters operationally. VXLAN underpins overlay networks in data centers, cloud providers, and virtualized infrastructure. A remote peer sending crafted VXLAN-encapsulated packets into a GRO session mid-teardown can panic a hypervisor, collapsing tenant connectivity across the entire host. The blast radius of a non-exploitable panic in this path dwarfs the blast radius of a local privilege escalation in userspace — one packet, one host down, tenants offline.
Patch anyway, but understand what you're defending against: not code execution, but repeatable kernel panics that could be weaponized through DoS-as-a-service models in multi-tenant environments. The EPSS 0.00497 likely captures 'no reliable RCE exploit' correctly while missing the DoS axis entirely.
One more thing: this is the fourth or fifth instance of the sk_user_data race pattern in kernel GRO paths across recent release cycles. Each fix is a NULL check in a different tunnel protocol's GRO handler. The straightforward fix pattern — adding a NULL check after skb_gro_remcsum_init() — suggests this was caught in code review, not fuzzing, and likely represents a recent refactor introducing the race rather than a long-dormant flaw. Other GRO receive paths (GUE, GENEVE) likely carry the same structural debt. Prioritize this patch, but treat it as a canary: if this pattern keeps surfacing, your monitoring should alert on kernel panics in any VXLAN or tunnel GRO path, not just this specific CVE.