Описание
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.
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.
Отчет
This vulnerability is rated as an Important impact on Red Hat Enterprise Linux because memory corruption within kernel space can lead to a system-wide denial of service or facilitate privilege escalation. However, the SCTP kernel module is not loaded by default on standard Red Hat installations unless explicitly configured or required by running applications. Consequently, exposure is limited to environments where SCTP services are actively utilized or where local unprivileged users can trigger module loading.
Меры по смягчению последствий
To mitigate this issue, prevent the sctp kernel module from loading. Create a file named /etc/modprobe.d/disable-sctp.conf with the following content:
After creating the file, regenerate the initramfs and reboot the system for the changes to take effect. Applications or services that rely on the SCTP protocol cannot use this mitigation and should prioritize applying the fix.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat OpenShift Container Platform 5 | openshift/ose-rhel-coreos-9 | Affected | ||
| Red Hat Enterprise Linux 10 | kernel | Fixed | RHSA-2026:71233 | 24.09.2026 |
| Red Hat Enterprise Linux 10.0 Extended Update Support | kernel | Fixed | RHSA-2026:69089 | 21.09.2026 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | kernel-rt | Fixed | RHSA-2026:70308 | 22.09.2026 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | kernel | Fixed | RHSA-2026:70290 | 22.09.2026 |
| Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2026:71016 | 23.09.2026 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2026:71213 | 24.09.2026 |
| Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support | kernel | Fixed | RHSA-2026:69874 | 22.09.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
7.8 High
CVSS3
Связанные уязвимости
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_se...
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_as
sctp: don't free the ASCONF's own transport in DEL-IP processing
In the Linux kernel, the following vulnerability has been resolved: s ...
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...
EPSS
7.8 High
CVSS3