CVE-2026-52929

What it actually does

This is a Linux kernel SCTP denial-of-service vulnerability in stream reconfiguration handling. When an SCTP ADD_OUT_STREAMS request is denied, the kernel reduces the outgoing stream count and queued chunks but does not fully tear down the removed stream metadata. A later attempt to add streams can reuse stale scheduler-private stream state, causing an inconsistent SCTP stream scheduler state and potentially a kernel NULL pointer dereference in the scheduler path. Successful exploitation can crash the kernel or affected SCTP handling path, resulting in local or remote denial of service depending on SCTP exposure and network reachability.

Why it matters to the business

Systems that expose SCTP can be made unstable or unavailable, which may interrupt services that depend on SCTP-based signaling or transport. This is most relevant for telecom, signaling, carrier, industrial, and specialized network services where SCTP is enabled. Current public risk indicators are relatively low: EPSS is low, it is not listed in CISA KEV, no ransomware association is reported, and no public exploit maturity is indicated; however, kernel denial-of-service flaws can still have high operational impact on exposed infrastructure.

How an attack unfolds

An attacker first needs the ability to interact with an SCTP endpoint on a vulnerable Linux kernel. They establish or influence an SCTP association and trigger SCTP stream reconfiguration by attempting to add outgoing streams. The attacker then causes the ADD_OUT_STREAMS operation to be denied, leaving stale stream scheduler metadata behind due to incomplete rollback. A subsequent re-add or scheduler access causes the SCTP scheduler to operate on inconsistent or stale stream-extension state, which can lead to a NULL pointer dereference in kernel context. The practical result is a kernel crash, service outage, or forced reboot rather than code execution based on the available description.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream SCTP fix for fully rolling back denied ADD_OUT_STREAMS state. If no fixed package version is available from the vendor yet, track the vendor advisory and update to the first kernel build that includes the SCTP stream rollback fix. Where immediate patching is not possible, reduce exposure by disabling SCTP if it is not required, blocking SCTP at host and network firewalls, restricting SCTP access to trusted peers, and isolating SCTP-dependent services from untrusted networks. Reboot into the patched kernel after installation; simply installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a vendor release containing the SCTP stream rollback fix. Validate with commands such as uname -a and the relevant package manager query for the installed kernel build. Review vendor changelogs or security advisories for references to the SCTP ADD_OUT_STREAMS rollback, SCTP stream scheduler consistency, or the associated CVE. Confirm whether SCTP is enabled or reachable by reviewing loaded modules, listening services, firewall policy, and network exposure. If SCTP is not required, verify it is disabled or blocked. For high-assurance validation, perform controlled SCTP regression testing in a non-production environment to ensure denied stream-add operations no longer crash or destabilize the kernel.

Typical attack path

1. Identify a reachable Linux system with SCTP enabled and accepting SCTP associations.
2. Establish or interact with an SCTP association that permits stream reconfiguration attempts.
3. Send SCTP stream reconfiguration traffic that attempts to add outgoing streams.
4. Cause the ADD_OUT_STREAMS operation to be denied, leaving stale outgoing-stream metadata in the vulnerable kernel state.
5. Trigger a subsequent add-stream or scheduler operation that reuses the stale stream state.
6. Cause a kernel NULL pointer dereference, resulting in denial of service or system instability.

How to detect it

To determine whether exploitation may have already occurred, review kernel logs, system journal entries, crash dumps, panic records, and uptime/reboot history for SCTP-related NULL pointer dereferences or crashes. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, hypervisor reset events, and network telemetry for SCTP traffic. Look for crashes occurring shortly after SCTP association setup or stream reconfiguration activity, especially repeated crashes from the same peer or source network. Network detection should focus on SCTP packets involving stream reconfiguration behavior, particularly add-outgoing-stream attempts followed by denied or failed operations and then system instability. Because the vulnerability is a denial-of-service condition, durable host artifacts may be limited to kernel panic traces, oops messages, crash dumps, and reboot records rather than files dropped by an attacker.

• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• sctp
• ADD_OUT_STREAMS
• SCTP
• sctp_stream_outq_migrate
• /var/crash/
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• vmcore

What your security team should do

• Inventory Linux systems and appliances that have SCTP enabled, SCTP modules loaded, or SCTP services exposed.
• Prioritize patching internet-facing, telecom-facing, signaling, carrier-grade, or externally reachable SCTP endpoints.
• Upgrade to a vendor kernel release that includes the SCTP stream rollback fix and reboot into the patched kernel.
• If patching must be delayed, block or tightly restrict SCTP traffic at network and host firewalls unless business-critical.
• Monitor for kernel crash logs, NULL pointer dereferences, SCTP stream reconfiguration errors, and unexpected reboots on systems where SCTP is enabled.
• Review vendor advisories because exact fixed package versions vary by Linux distribution and appliance vendor.
• Treat repeated SCTP-related kernel crashes or reboots as potential exploitation attempts even though public exploit maturity is currently not reported.