The patch for CVE-2026-72350 adds shift-operand validation in u32_mt_checkentry(), which fires when netfilter rules are loaded into the kernel. The vulnerable code lives in u32_match_it(), which executes on every packet. This creates a static enforcement model: protection holds only if rules remain immutable after validation. If the kernel permits dynamic rule modification through netlink, module reload, or concurrent updates without re-calling checkentry, the validation can be bypassed. You need to verify whether your filtering pipeline ever modifies xt_u32 rules post-load — if so, this patch provides incomplete protection.
Beyond the validation gap, the undefined behavior dimension matters more than CVSS suggests. A shift count of 32 on a 32-bit integer is undefined under the C standard, not merely out-of-bounds. The compiler may constant-fold, vectorize, or drop the operation entirely depending on optimization context. This means identical rules can behave differently across kernel builds, compiler versions, or per-CPU execution contexts. The behavior isn't just "crash or not" — it's nondeterministic across the SMP packet processing path.
The low EPSS score (0.00176) reflects exploitability barriers (root required to load netfilter rules), but conflates probability with severity. If xt_u32 rules process perimeter traffic, a successful exploit doesn't crash a single host — it silently corrupts the filtering layer's behavior on all traffic it touches. That's a different blast radius than EPSS captures.
Check three things: (1) whether CAP_NET_ADMIN or root is required to load these rules in your configuration, (2) whether any operational process modifies xt_u32 rules after initial load, and (3) whether xt_u32 is even active in your ruleset — it's a legacy target largely superseded by nftables, and may exist as dormant code in your module tree without being on the hot path.