Описание
In the Linux kernel, the following vulnerability has been resolved:
sctp: revalidate output stream after association connect wait
When message interleaving is enabled, the first send waits for association
establishment before building its data chunks. The wait drops the socket
lock, and handshake processing can reduce the output stream count to the
peer-advertised inbound stream count. sctp_stream_init() then frees the
extension of every removed stream.
The sender resumes with the stream that it checked before the wait. If the
peer removed that stream, sctp_outq_tail() later dereferences its NULL
extension. Fatal-oops policies then panic the host.
KASAN: null-ptr-deref in range [0x38-0x3f]
RIP: sctp_outq_tail+0x49e/0xaa0
Call Trace:
sctp_primitive_SEND
sctp_sendmsg_to_asoc
sctp_sendmsg
A range check alone is insufficient. Stream reconfiguration can grow the
output count again while the lock is released without recreating extensions
freed by the earlier shrink. The stream can then be in range while its
extension remains NULL. The send-buffer wait has the same issue.
Factor the range and extension checks into a helper and repeat both after
each send-path wait that drops the socket lock. Once the lock is
reacquired, the validation remains stable through data creation and
queueing.
If validation fails after the connect wait, the auto-created association is
already established. Return ESRCH so the existing caller path keeps it
under state-machine ownership instead of freeing it directly, which would
leave protocol, counter and socket state inconsistent.
A flaw was found in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. This flaw allows a remote peer or local user to cause a denial of service (DoS) through a kernel crash. When message interleaving is enabled, the kernel drops the socket lock while waiting for association establishment or send-buffer availability, allowing handshake processing to free output stream extensions without proper revalidation. When the sending process resumes and accesses the unvalidated stream, it dereferences a null pointer, causing a system panic.
Отчет
This vulnerability is evaluated as having Moderate impact because successful exploitation results in a kernel panic and host denial of service, without granting arbitrary code execution or unauthorized data exposure. Typical Red Hat Enterprise Linux configurations do not automatically load the SCTP kernel module unless an administrator explicitly loads it or an active service binds an SCTP socket. Additionally, triggering the flaw requires local unprivileged socket operations and the specific configuration of SCTP message interleaving combined with stream reconfiguration.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Fix deferred |
Показывать по
Ссылки на источники
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate output stream after association connect wait When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream can t...
In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate output stream after association connect wait When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream
sctp: revalidate output stream after association connect wait
In the Linux kernel, the following vulnerability has been resolved: s ...
In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate output stream after association connect wait When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stre...
EPSS
5.5 Medium
CVSS3