CVE-2026-53225

What it actually does

This is a Linux kernel SCTP receive-path information disclosure flaw in the ASCONF address-configuration lookup logic. An unauthenticated SCTP peer can send a malformed trailing ASCONF chunk containing a truncated IPv6 address parameter. The vulnerable code validates only that the chunk contains the ADD-IP header and a parameter header, then calls address parsing logic that may read up to 16 bytes beyond the supplied parameter data from uninitialized kernel memory. The described impact is an out-of-bounds uninitialized read, not direct code execution or privilege escalation.

Why it matters to the business

Systems exposing SCTP to untrusted networks may allow a remote unauthenticated party to trigger kernel memory disclosure behavior or kernel memory-sanitizer findings. While the currently described impact is limited compared with remote code execution, kernel networking flaws can affect high-availability telecom, signaling, load-balancing, and specialized infrastructure that relies on SCTP. EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, but the issue should still be addressed through normal kernel patching because exploitation requires only network reachability to SCTP.

How an attack unfolds

An attacker first identifies a host that accepts SCTP traffic. They then send a crafted SCTP packet containing an ASCONF chunk on a path where no existing association is found, forcing the kernel into the no-association ASCONF lookup logic. The malicious chunk is constructed so that it contains enough bytes to pass the initial header checks but includes a trailing IPv6 address parameter that is shorter than the parser expects. The vulnerable kernel then calls the address-parameter conversion routine, which reads the full IPv6 address size from memory even though the packet did not supply those bytes. Depending on kernel build, instrumentation, and surrounding memory state, this may result in exposure of uninitialized kernel memory content, diagnostic kernel warnings, or packet-processing anomalies.

How to fix it

Upgrade to a Linux kernel version or distribution security update that includes the SCTP bounds-checking fix for __sctp_rcv_asconf_lookup(). If exact fixed package versions are not provided by the kernel vendor, use the relevant distribution advisory and install the latest available security kernel for the affected release. Reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by blocking SCTP at network boundaries where it is not required, disabling unused SCTP services, and restricting SCTP to trusted peers. Do not rely solely on host firewalls if SCTP is allowed through upstream network paths.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build containing the fix, not merely that the package has been installed. Validate with the distribution package manager, kernel changelog/advisory references, and the active kernel reported by the host after reboot. Confirm SCTP exposure by checking whether SCTP is loaded or in use and whether firewalls permit IP protocol 132. Network validation should verify that untrusted sources cannot send SCTP to systems that do not explicitly require it. For regression testing in controlled environments, malformed SCTP ASCONF packets should no longer trigger KMSAN, KASAN, dmesg, or kernel warning messages referencing __sctp_rcv_asconf_lookup() or from_addr_param().

Typical attack path

1. Find an internet-facing or otherwise reachable host with SCTP enabled or permitted through network controls.
2. Send SCTP traffic containing an ASCONF chunk toward the target.
3. Craft the ASCONF chunk so the trailing IPv6 address parameter contains only the parameter header or is otherwise shorter than the full IPv6 address structure.
4. Trigger the no-association ASCONF lookup path in the Linux kernel SCTP receive handler.
5. Cause the kernel address parser to read uninitialized bytes beyond the truncated parameter.
6. Attempt to observe leaked data indirectly through protocol behavior, diagnostics, crashes, or instrumented environments.

How to detect it

Review kernel logs, crash dumps, and security telemetry for warnings or sanitizer reports related to SCTP ASCONF parsing. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, kernel crash dump repositories, EDR kernel-event telemetry, IDS/NSM packet captures, and firewall logs that record SCTP. Look for malformed SCTP packets using IP protocol 132 with ASCONF chunks, especially chunk type 0xC1/193 containing an IPv6 Address parameter type 0x0006 with a parameter length shorter than a complete IPv6 address parameter or extending beyond the chunk boundary. Because this flaw may not create reliable application logs, absence of logs does not prove absence of exploitation. If packet capture is available, search historical traffic for SCTP ASCONF packets from untrusted sources and inspect whether trailing address parameters are truncated. In instrumented or debug kernels, exploitation attempts may appear as KMSAN uninitialized-value reports in __sctp_rcv_asconf_lookup() or address conversion routines.

• KMSAN: uninit-value in __sctp_rcv_asconf_lookup
• __sctp_rcv_asconf_lookup
• from_addr_param
• net/sctp/input.c
• sctp: fix uninit-value in __sctp_rcv_asconf_lookup
• SCTP ASCONF
• ASCONF chunk type 0xC1
• ASCONF chunk type 193
• SCTP IPv6 Address parameter type 0x0006
• IP protocol 132
• truncated ASCONF
• malformed SCTP ASCONF

What your security team should do

• Inventory Linux systems that expose SCTP, especially telecom, signaling, Diameter/SIGTRAN, load-balancing, and specialized network appliances.
• Prioritize patching externally reachable SCTP endpoints and systems where untrusted peers can send SCTP traffic.
• Install the vendor-provided fixed kernel and reboot to ensure the patched kernel is active.
• If SCTP is not required, block IP protocol 132 at perimeter firewalls, cloud security controls, and host firewalls.
• Monitor kernel logs for SCTP parsing warnings, KMSAN/KASAN reports, or crashes involving __sctp_rcv_asconf_lookup(), from_addr_param(), or ASCONF processing.
• Capture or inspect SCTP traffic where feasible for malformed ASCONF chunks with truncated IPv6 address parameters.
• Treat exploitation likelihood as currently low because EPSS is low, the issue is not listed in KEV, and no mature exploit is reported, but do not defer routine kernel security updates.