Linux Kernel EUVD-2026-86682

Requires: (1) physical or provisioned Netronome/Corigine NFP SmartNIC hardware with the nfp driver loaded; (2) an administrator (CAP_NET_ADMIN) to have previously installed ethtool ntuple/flow-steering rules into nn->fs.list - with zero installed rules there is nothing to over-read; (3) local access for an unprivileged user to issue the ETHTOOL_GRXCLSRLALL ioctl, which itself needs no CAP_NET_ADMIN and sizes the buffer from the userspace-supplied rule_cnt. Limiting factors: the vulnerable path only triggers when the caller's rule_cnt is smaller than the number of installed rules, the attacker does not control whether rules are installed (AC:H), and the whole issue is confined to hosts with this specific SmartNIC, sharply narrowing real-world exposure.

The provided CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.0) is internally consistent on access - this is a LOCAL, low-privilege issue, not remote - but the C:H/I:H/A:H triad is overstated. The real primitive is an out-of-bounds write in nfp_net_get_fs_loc() plus a NULL-pointer dereference when rule_cnt=0, which is crash-dominant (A:H credible) with only bounded, incidental disclosure of stale rule-location slots (C:L/I:L at most, not C:H/I:H). No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active or imminent exploitation. AC:H is justified: an administrator with CAP_NET_ADMIN must first install flow-steering (ntuple) rules before any unprivileged user can trigger the walk via ETHTOOL_GRXCLSRLALL - the attacker does not control that precondition. Bottom line: this is a high-CVSS-but-low-real-risk item - a genuine kernel bug worth patching, but gated behind niche Netronome/Corigine NFP SmartNIC hardware and a non-attacker-controlled admin configuration, making it a low operational priority for most fleets.

On a host with a Netronome/Corigine NFP SmartNIC where an administrator has already installed ethtool ntuple flow-steering rules, a local unprivileged user issues an ETHTOOL_GRXCLSRLALL ioctl requesting fewer location slots (or zero) than the number of installed rules. The kernel walks the full nn->fs.list into the too-small rule_locs[] buffer, writing past the allocation (or dereferencing a NULL buffer when rule_cnt=0), corrupting memory or panicking. No public exploit code is identified at time of analysis.