CVE-2026-72450 is a shift-out-of-bounds in the XFRM selector matching path, triggered when AF_UNSPEC selectors interact with XFRM_STATE_AF_UNSPEC state flags in a specific way. The bug isn't simply a missing bounds check — it's a structural gap where the AF_UNSPEC code path uses selector prefixlen values against address data of different bit-widths without validating family consistency. This matters because AF_UNSPEC exists to allow selectors to match across address family boundaries for legitimate tunnel and wildcard scenarios, but that flexibility created a validation gap: prefixlen checks that normally occur at policy or SA insertion time were apparently never applied to this path.
The fix addresses this with three independent corrections: rejecting family mismatches at the selector boundary, capping addr4_match at 32 bits, and capping addr_match at 128 bits. This three-part approach is itself revealing — it suggests the original validation responsibility was diffused across layers without clear ownership, and the fix had to add backstops at multiple points to avoid breaking legitimate AF_UNSPEC users in VPN, kernel routing policy, and IPsec tunnel mode.
The deeper concern is whether this represents a pattern rather than an isolated gap. The XFRM validation architecture appears to treat different entry points with different rigor — some paths have explicit prefixlen validation while others apparently rely on implicit assumptions that were never enforced. The addr4_match and addr_match caps function as defensive backstops now, but they shouldn't be the only line of defense. You should audit your XFRM code paths to identify whether other entry points have similar implicit assumptions about prefixlen validity that weren't validated across all code paths. The dead-zone framing is useful here: code paths with no active maintainers are paradoxically more dangerous because there's no one using them to notice when assumptions break — syzbot found this one, not a developer.