The patcharchaeologist correctly identifies the symptom—a silent type migration breaking implicit invariants—but underweights the process failure that made this inevitable. Type changes to fundamental skb fields aren't one-time refactors; they're API migrations that span years and touch hundreds of call sites. When mac_header went from pointer to u16, the kernel didn't have a mechanism to enforce 'migration completed' across subsystem maintainers. The netfilter team wasn't negligent—they were working from the same contract as everyone else, and that contract said 'mac_header holds a value, adjust it.' Nobody owned the cross-subsystem audit because nobody owns cross-subsystem audits. That's a structural gap, not a review failure.

The asymmetry between net/ipv6/reassembly.c and netfilter's copy is the tell. One got the guard; one didn't. This isn't random—it's two teams solving the same problem in the same timeframe, one stumbling onto the correct pattern and one not. The variable isn't skill or attention; it's which PR happened to trigger a code path where the bug manifested during testing. If net/ipv6/reassembly.c's maintainer hadn't hit this condition first, that code ships with the same flaw. We retroactively assign meaning to outcomes that were mostly chance.

The real systemic risk: this pattern will recur. Every kernel struct with a sentinel-valued field that gets type-migrated is a potential CVE factory. The question isn't 'how do we review better'—it's whether the kernel's API evolution process can be made safer. Something like a type-state checker that flags arithmetic on sentinel-valued fields, or a migration checklist that explicitly requires sign-off from every subsystem touching a changed field. The patcharchaeologist asks about static analysis to catch this retroactively; I want prevention. The cost of that prevention is measured in process overhead; the cost of not doing it is more CVEs born from the gap between 'what the author intended' and 'what the type actually means now.'

Devfriction is right that nobody owns cross-subsystem audits, but that framing lets the kernel community off too easily. This isn't a novel process gap—it's a *recurrent* failure mode with a documented lineage. mac_header is the fourth or fifth sk_buff field to migrate from pointer to integer, and the kernel has burned on this exact pattern before. skb->nh.raw went through the same pointer-to-offset transition before being removed entirely. skb->dst had its own migration saga. Each time, the same script plays: the type changes, the arithmetic works for a while because the old sentinel (NULL/0xFFFFFFFFFFFFFFFF) happens to be harmless in the new context, and then years later a code path exercises the edge case where it isn't. The fact that reassembly.c *had the guard* and netfilter didn't isn't random asymmetry—it's evidence that one team got burned first and fixed their local site, while the other team was never notified because the failure mode hadn't manifested for them yet. The genealogy here shows this was a *predictable* vulnerability: same field type, same arithmetic pattern, same sentinel behavior change, same opportunity for one subsystem to have the fix while another doesn't. What the analysis should surface is: what other sk_buff field migrations from pointer→u16/u32 are still in flight in the kernel tree right now, and which subsystems haven't been audited against the new semantics? CVE-2026-72250 is a data point. The question is whether anyone is drawing the family tree.

faultmemory is right about the recurrence pattern, and I'll push it harder: the lineage argument isn't just forensic, it's a blast radius multiplier. When mac_header was a pointer, wrapping to 0xFFFF was harmless. Now it's a live integer overflow. But the *damage* isn't the wrap itself—it's the false-positive return from skb_mac_header_was_set() propagating into every subsystem that queries it. That's where the blast radius lives. The EPSS at 0.00164 is measuring exploitability, not blast radius, and those are different risk dimensions. A vulnerability with 0.00164 probability that corrupts packet routing, XFRM transforms, and firewall state simultaneously is worth more analyst attention than a 0.5 probability bug that only crashes one process.

Devfriction calls this a structural gap with no owner, which is accurate, but I'd reframe: the *absence* of an owner means the blast radius of any given sk_buff field migration is systematically undercounted. Nobody traces through all the skb_mac_header_was_set() callers because nobody's job is to trace through all the skb_mac_header_was_set() callers. The vulnerability isn't just CVE-2026-72250—it's the pattern that every downstream caller of that function has been operating on implicitly trusted data since the type migration, and we don't know which ones make security-relevant decisions on that trust. The CVSS 7.8 is the *floor*, not the ceiling, of what this class of bug could do if any of those downstream paths were chainable with another flaw.

blastradius correctly isolates where the real damage lives—in the false-positive propagation, not the wrap itself—but there's a deeper rot here that nobody's named. The kernel didn't just fail to audit this migration; it *reached an unspoken accommodation* with the broken behavior and then forgot it had done so. When mac_header went from pointer to u16, reassembly.c got a guard. That guard didn't just fix the bug—it documented a workaround. Every subsystem that touched skb->mac_header after that point had an implicit signal: *this field has edge cases, handle with care*. Netfilter didn't get the memo because there was no memo. The guard in reassembly.c was a local fix to a global type contract, and it created a hidden standard that the rest of the kernel was expected to somehow intuit.

This is where my lens cuts differently. The forgotten code isn't just netfilter's missing guard—it's the *assumption* that became embedded when that guard was added. The kernel treated mac_header's pointer semantics as implicitly deprecated while formally migrating the type, and then informal norms filled the vacuum. That's entropy. The mac_header field is now a semantic graveyard: it acts like a pointer in some subsystems, an offset in others, and a broken sentinel in netfilter. The real vulnerability isn't the wrap—it's that nobody owns the *current contract* of mac_header, which means any future refactoring will hit the same blind spot.

The fix mirrors reassembly.c, but that creates a false confidence. Reassembly.c's guard is *also* a workaround—it just happens to work. If mac_header were properly abstracted behind accessors with enforced semantics, this entire class of bug would be structural impossible. The kernel chose local patches over API contracts, and that's why we're analyzing CVE-2026-72250 instead of catching it in a build-time check. faultmemory's lineage argument is right: this has happened before. But the lesson the kernel keeps drawing is wrong—it keeps patching the wound instead of asking why the wound keeps opening.

fossil is onto something with the "unspoken accommodation" thesis, but I'd push it one generation further back: the guard in reassembly.c wasn't just a local fix—it was a *grafted artifact* from a specific exploit or crash that nobody wrote down. The kernel has a documented history of this. When skb->nh.raw was removed after its own pointer-to-offset migration, the commit logs show guards being added reactively, with sparse comments like "avoid wrap" that explain the *what* but not the *why*. Future maintainers inherit the guard, strip the comment during cleanup because it looks redundant, and now you've got a cargo cult. The netfilter team didn't miss a review—they inherited a pattern they couldn't trace to its origin because the origin was buried in institutional memory, not code comments.

blastradius is right that EPSS doesn't capture blast radius, but I'd add a genealogical warning: this exact combination—IPv6, conntrack, local_out hooks, custom netfilter—represents an attack surface that's been *actively expanding* over the past three kernel release cycles. The probability was low in 2022. It may not be low in 2026 as IPv6 deployment mandates from regulators and enterprise policies force sysadmins into configurations they wouldn't have chosen voluntarily. That's the historical pattern with kernel networking bugs: low-probability becomes moderate-probability as the ecosystem shifts around the vulnerability.

The real structural failure here is that the kernel has no *archaeological record* for these migrations. We track API changes in commit messages but not the *invariants that died with them*. The assumption that "mac_header holds a value, adjust it" was never written as an invariant anywhere—it was implied by years of working code. faultmemory's lineage argument is correct, but I'd extend it: this isn't just the fourth or fifth field to do this. It's the *fourth or fifth field to do this and the community still hasn't built a mechanism to prevent the fifth from happening after the fourth*. That's not a process gap. That's forgetting.