CVE-2026-53002

What it actually does

This flaw is a stack-based buffer overflow in the Linux kernel netfilter connection-tracking/NAT SIP helper path. When the kernel parses and rewrites SIP/SDP traffic, specifically while handling SDP session data and adjusting Content-Length values, vulnerable code uses sprintf-style formatting into a stack buffer and can write past the end of that buffer. Successful triggering can corrupt kernel stack memory and may cause a kernel warning, oops, panic, or denial of service on systems processing affected SIP traffic. Because the vulnerable code executes in kernel context, any reliable exploit would have high technical severity, although the available information indicates low EPSS, no known public exploit maturity, and no CISA KEV listing at this time.

Why it matters to the business

Systems acting as Linux-based firewalls, routers, NAT gateways, load balancers, VoIP/SIP gateways, or hosts with netfilter SIP helpers enabled could be crashed or destabilized by crafted SIP traffic. The most likely operational consequence is disruption of network forwarding or VoIP services rather than confirmed data theft. Urgency is moderate: the vulnerability is kernel-level and remotely triggerable in exposed packet-processing paths, but current exploitation signals are low, with EPSS at 0.00354, no known KEV status, and no ransomware association reported.

How an attack unfolds

An attacker sends specially crafted SIP traffic containing SDP content through or to a Linux system that has netfilter connection tracking/NAT SIP helper functionality enabled. As the packet traverses the kernel networking stack, the SIP helper parses the message, processes an INVITE request, rewrites SDP session details, and attempts to mangle the Content-Length field. On vulnerable kernels, that formatting operation can write beyond the stack buffer boundary. The immediate result may be a KASAN report on instrumented kernels, a kernel oops, packet-processing failure, or a full system crash. A more advanced attacker would attempt to shape the SIP/SDP payload to make the stack overwrite reliable, but no public exploit maturity is currently indicated.

How to fix it

Apply the Linux kernel update that contains the netfilter conntrack fix replacing unsafe sprintf usage with bounded scnprintf handling and increasing the relevant buffer size in mangle_content_len(). Where distribution-specific fixed versions are unavailable, update to the latest supported kernel from the operating system vendor and confirm the vendor has backported the fix for this CVE. As interim mitigation, disable or avoid loading the SIP conntrack/NAT helper modules if they are not required, such as nf_conntrack_sip and nf_nat_sip. Restrict SIP exposure to trusted sources, avoid unnecessary SIP ALG/helper functionality on Internet-facing systems, and consider handling SIP at the application layer or a dedicated SBC rather than using kernel helpers. Reboot into the patched kernel after installation, because kernel package installation alone is not sufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build that includes the fix. Validate with commands such as uname -a and the distribution package manager, then compare against the vendor security advisory for this CVE. Check whether SIP helper modules are loaded with lsmod | grep -E 'nf_conntrack_sip|nf_nat_sip' and review nftables/iptables CT helper configuration to determine whether SIP traffic is being assigned to the helper. Confirm mitigation by verifying the modules are not loaded or SIP helper rules are removed where the feature is unnecessary. Review kernel logs after patching or mitigation to ensure no new KASAN, oops, or panic messages reference the SIP helper path, mangle_content_len, nf_nat_sdp_session, or process_sip_msg.

Typical attack path

1. Identify a Linux-based network device, gateway, server, or firewall that processes SIP traffic with netfilter SIP connection-tracking/NAT helpers enabled.
2. Send crafted SIP messages, commonly INVITE requests containing SDP bodies, over a path handled by the vulnerable kernel helper.
3. Trigger SIP helper parsing in the kernel during conntrack/NAT confirmation and SDP rewriting.
4. Cause the vulnerable Content-Length mangling path to format data beyond the stack buffer boundary.
5. Induce kernel memory corruption, KASAN alerts, kernel oops/panic, network disruption, or potential further exploitation if the overwrite can be controlled.

How to detect it

Detection of prior exploitation is difficult because the vulnerability occurs in kernel packet-processing code and may leave no durable artifact beyond crashes, kernel warnings, or network disruption. Review kernel logs from journalctl -k, dmesg archives, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for KASAN stack-out-of-bounds reports, kernel oopses, panics, or stack traces containing the netfilter SIP helper functions. Correlate any such events with SIP traffic spikes, malformed SIP INVITE messages, SDP bodies, or unusual Content-Length behavior on ports commonly used for SIP such as 5060/tcp, 5060/udp, and 5061/tcp. Network telemetry may show repeated SIP INVITE requests with SDP content immediately before a crash or restart. For forensics, preserve vmcore/kdump output and kernel logs, then examine whether the failing stack includes vsnprintf, sprintf, mangle_content_len, nf_nat_sdp_session, process_sdp, process_invite_request, process_sip_msg, sip_help_tcp, or nf_confirm.

• BUG: KASAN: stack-out-of-bounds in vsnprintf
• stack-out-of-bounds in vsnprintf
• sprintf+0xb1/0xe0
• mangle_content_len
• nf_nat_sdp_session
• process_sdp
• process_invite_request
• process_sip_msg
• sip_help_tcp
• nf_confirm
• nf_conntrack_sip
• nf_nat_sip
• SIP/2.0
• INVITE sip:
• Content-Length:
• application/sdp

What your security team should do

• Prioritize patching Linux systems that forward, NAT, firewall, or inspect SIP traffic, including VoIP gateways, SBC-adjacent infrastructure, routers, and Internet-facing network appliances built on Linux.
• Inventory systems with nf_conntrack_sip or nf_nat_sip loaded and treat them as the primary exposure group.
• Disable SIP conntrack/NAT helpers wherever they are not explicitly required; do not rely on automatic helper assignment for untrusted SIP traffic.
• Restrict SIP traffic to known providers, peers, or management networks using firewall policy while updates are being deployed.
• Monitor kernel logs and SIEM telemetry for KASAN, oops, panic, and stack traces involving netfilter SIP helper functions.
• After updating, reboot systems into the fixed kernel and verify the active running kernel version.
• Because current exploitation intelligence is low and the CVE is not in KEV, prioritize based on exposure: Internet-facing SIP-processing systems first, internal systems with untrusted SIP paths next.