CVE-2026-74569

The vulnerability in sip_help_tcp() stems from an s16-typed delta variable accumulating SIP message expansion during NAT rewriting. When a Contact header contains many endpoints, nf_nat_sip rewrites each URI, and the cumulative expansion can exceed 32767 bytes. The s16 overflow wraps negative, silently corrupting the datalen calculation downstream. The crash manifests later—at ct_sip_get_header reading past the linearized skb tail—not at the wrap point, making this a delayed, silent buffer overrun that is harder to detect than an immediate crash. The fix (widening to s32) is correct and safe because the 65535-byte enlarge_skb() limit is the hard ceiling; s32 comfortably accommodates the full range. But the real problem isn't this one variable. It's the implicit assumption embedded in the original code: that SIP message growth under NAT would stay within s16 range. That assumption contradicts how SIP's Contact-based routing actually works—a single message can expand by 20-30KB during NAT rewriting, all within protocol limits but far outside s16 range. You should audit your deployments for three things. First, verify whether nf_conntrack_sip.c (UDP handler) uses the same s16 pattern; if it does, UDP may be exploitable without the TCP connection tracking state this CVE requires. Second, scan other netfilter protocol helpers for s16 or similarly narrow delta variables tracking in-band size adjustments—the same pattern has appeared in multiple netfilter adjacent CVEs since 2015. Third, check whether your SIP NAT rules process messages with many Contact headers; this is the trigger condition, and an attacker can engineer precise expansion to force the wrap. The blast radius is significant: the SIP helper runs at the NAT boundary, in the packet processing hot path, for every INVITE and REGISTER crossing a Linux firewall. The 65535-byte limit bounds exploitation, but that bounded area contains every NAT-gateway SIP deployment on Linux. The vulnerability is deterministic once the expansion conditions are met—not a race condition or complex memory layout issue, but a one-dimensional counter that wraps predictably. Patch immediately, and treat this as a forcing function to audit other helpers for similar implicit size assumptions based on common-case traffic rather than protocol maximums.

Reviewed through automated stages and approved by a human before publication.