Bug 2510890 (CVE-2026-64564)
| Summary: | CVE-2026-64564 kernel: sctp: don't free the ASCONF's own transport in DEL-IP processing | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | akhatavk, akito5623, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in the Stream Control Transmission Protocol (SCTP) implementation within the Linux kernel. A remote attacker could send a specially crafted sequence of ASCONF (Add IP Address Configuration) chunks, including DEL-IP (Delete IP Address) parameters, to trigger a use-after-free condition. This memory corruption could lead to a system crash, resulting in a denial of service, and potentially allow for arbitrary code execution.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2026080404-CVE-2026-64564-6762@gregkh/T Fly A PoC and exploit for CVE-2026-64564 have been released. Patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=42e30bf3463cd37d73839376662cb79b4d5c416c PoC / Exploit https://github.com/hackspeak/cve-2026-64564 This issue has been addressed in the following products: Red Hat Enterprise Linux 10.0 Extended Update Support Via RHSA-2026:69089 https://access.redhat.com/errata/RHSA-2026:69089 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Update Services for SAP Solutions Red Hat Enterprise Linux 8.8 Telecommunications Update Service Via RHSA-2026:69837 https://access.redhat.com/errata/RHSA-2026:69837 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On Via RHSA-2026:69874 https://access.redhat.com/errata/RHSA-2026:69874 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On Via RHSA-2026:69906 https://access.redhat.com/errata/RHSA-2026:69906 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions Via RHSA-2026:69908 https://access.redhat.com/errata/RHSA-2026:69908 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2026:70290 https://access.redhat.com/errata/RHSA-2026:70290 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2026:70308 https://access.redhat.com/errata/RHSA-2026:70308 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions Via RHSA-2026:70483 https://access.redhat.com/errata/RHSA-2026:70483 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions Via RHSA-2026:70482 https://access.redhat.com/errata/RHSA-2026:70482 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.6 Extended Update Support Via RHSA-2026:70484 https://access.redhat.com/errata/RHSA-2026:70484 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2026:71016 https://access.redhat.com/errata/RHSA-2026:71016 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2026:71213 https://access.redhat.com/errata/RHSA-2026:71213 This issue has been addressed in the following products: Red Hat Enterprise Linux 10 Via RHSA-2026:71233 https://access.redhat.com/errata/RHSA-2026:71233 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2026:71232 https://access.redhat.com/errata/RHSA-2026:71232 |
In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.