The integer overflow in hid_bpf_get_data() is a bounds-check bypass, not a crashable bug. When the kernel performs (offset + size) < allocated_size with unsigned integers, wraparound produces a garbage value that passes the comparison, returning an out-of-bounds kernel pointer directly to the caller. This is a clean memory-disclosure primitive — no crash, no log entry, just a pointer into adjacent kernel memory the attacker controls via parameters they supply.
What makes this critical is the attack surface. HID-BPF lets eBPF programs attach to USB HID devices, meaning the exploit path includes any device that speaks HID — a physical attacker with a malicious USB device, or a compromised USB driver manipulating offset/size parameters. From a leaked kernel pointer, the standard chain follows: defeat KASLR, spray credentials, escalate to root. This isn't theoretical — kernel pointer leaks have never been observed as standalone in-the-wild exploits; they're always stage one of a multi-stage attack.
The fix — inserting check_add_overflow() — is one line and correct. But the real story is institutional. The overflow-checking API landed in 2018 specifically to prevent this class of failure. HID-BPF merged years later without adopting it, not out of negligence but because BPF maintainers and HID maintainers operate in separate knowledge domains. The pattern of unchecked unsigned addition before bounds comparison is genetic to the kernel — it keeps reproducing because the hardware semantics contradict developer intuition, and BPF's role as a force multiplier (user-space parameters constructing kernel pointers) makes the failure mode especially severe.
EPSS structurally underweights this class. The model estimates 30-day exploitation probability, but a kernel pointer leak is infrastructure, not an exploit. It permanently defeats KASLR for every subsequent privilege escalation attempt on that system. The window of exposure isn't measured in days until patch deployment — it's measured in leverage added to whatever exploit chain is already active.
For defenders: treat any BPF handler that returns pointers based on caller-supplied offsets as high-priority audit targets. The HID-BPF attach point now includes USB devices that may have weaker audit trails than file-based access. Check your BPF subsystem handlers for the exact pattern (unsigned_a + unsigned_b) < limit — if the arithmetic isn't protected by check_add_overflow(), it's vulnerable. The EPSS score should not govern prioritization for memory-disclosure primitives in BPF; assume active chaining and respond accordingly.