CVE-2026-31427
Description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found.
If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.
With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.
Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel's nf_conntrack_sip, process_sdp() uses an uninitialized stack variable, causing SDP session addresses to be rewritten with stale or zeroed data for inactive sessions.
Vulnerability
Description
In the Linux kernel's netfilter connection tracking helper for SIP, the function process_sdp() declares a union nf_inet_addr rtp_addr on the stack and passes it to the sdp_session hook after iterating SDP media descriptions. However, rtp_addr is only assigned inside the media loop when a recognized media type with a non-zero port is encountered. If the SDP body lacks media lines (m=), contains only inactive media (e.g., m=audio 0...), or uses unrecognized media types, rtp_addr remains uninitialized. Despite this, the function still calls the hook with the uninitialized address, leading to a kernel stack information leak or corruption depending on compiler and kernel configuration [1][2][3][4].
Attack
Vector and Exploitation
An attacker can exploit this by sending a crafted SIP message containing an SDP body with no active media descriptions. The Linux kernel's netfilter module will process the SDP, and because rtp_addr is left uninitialized, the sdp_session hook receives a pointer to stack memory containing stale data. With CONFIG_INIT_STACK_ALL_ZERO (default on many distributions), this causes the session owner (o=) and connection (c=) addresses to be rewritten to 0.0.0.0. Without such initialization, the rewritten address is whatever random data was on the stack. The attack requires the system to process SIP traffic through netfilter, typically in a gateway or VoIP-aware firewall role, but no special privileges beyond network access are needed for the network-facing component [1].
Impact
A successful exploitation results in denial of service for SIP sessions: the session-level addresses are corrupted, causing legitimate SIP endpoints to receive malformed SDP data. This can disrupt VoIP call setup, registration, or media negotiation. The corruption is persistent for the duration of the conntrack entry, potentially affecting all subsequent SIP messages for that session. The CVSS v3 score of 5.5 (Medium) reflects the local network-based attack vector and the availability impact with no confidentiality or integrity loss, though the leak of stack memory could theoretically expose kernel information in non-zero-init configurations [1].
Mitigation
The fix pre-initializes rtp_addr from the session-level connection address (caddr) when available, tracks whether a valid address was established with a have_rtp_addr flag, and skips the sdp_session hook entirely when no valid address is present. Patches have been committed to the stable kernel trees as shown in the referenced commits [1][2][3][4]. System administrators should apply the latest stable kernel updates that include this fix; no workaround is available for unpatched kernels.
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
8- git.kernel.org/stable/c/01f34a80ac23ae90b1909b94b4ed05343a62f646nvdPatch
- git.kernel.org/stable/c/52fdda318ef2362fc5936385bcb8b3d0328ee629nvdPatch
- git.kernel.org/stable/c/6a2b724460cb67caed500c508c2ae5cf012e4db4nvdPatch
- git.kernel.org/stable/c/6e5e3c87b7e6212f1d8414fc2e4d158b01e12025nvdPatch
- git.kernel.org/stable/c/7edca70751b9bdb5b83eed53cde21eccf3c86147nvdPatch
- git.kernel.org/stable/c/82baeb871e8f04906bc886273fdf0209e1754eb3nvdPatch
- git.kernel.org/stable/c/faa6ea32797a1847790514ff0da1be1d09771580nvdPatch
- git.kernel.org/stable/c/fe463e76c9b4b0b43b5ee8961b4c500231f1a3f6nvdPatch
News mentions
1- Patch Tuesday - April 2026Rapid7 Blog · Apr 14, 2026