CVE-2026-46227: falha de alta gravidade em Linux
sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
Publicada em · Atualizada em
Aviso por e-mail quando ela entrar no KEV, ganhar PoC pública ou subir de nota.
21Vexday Risk Score
Sem sinal de exploração. Nenhum artefato público de exploração conhecido até agora.
ssvc Trackcvss 7.8epss 0.1%
In the Linux kernel, the following vulnerability has been resolved:
sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with
list_for_each_entry_safe(), which caches the next entry in @tmp before
the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may
drop the socket lock inside sctp_wait_for_sndbuf().
While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the
association cached in @tmp, migrating it to a new endpoint via
sctp_sock_migrate() (list_del_init() + list_add_tail() to
newep->asocs), and optionally close the new socket which frees the
association via kfree_rcu(). The cached @tmp can also be freed by a
network ABORT for that association, processed in softirq while the
lock is dropped.
sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock
via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing
revalidates @tmp. After a successful return, the iterator advances to
the stale @tmp, yielding either a use-after-free (if the peeled socket
was closed) or a list-walk onto the new endpoint's list head (type
confusion of &newep->asocs as a struct sctp_association *).
Both are reachable from CapEff=0; the type-confusion path gives
controlled indirect call via the outqueue.sched->init_sid pointer.
Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()
returns. @asoc is known to still be on ep->asocs at that point: the
only callers that list_del an association from ep->asocs are
sctp_association_free() (which sets asoc->base.dead) and
sctp_assoc_migrate() (which changes asoc->base.sk), and
sctp_wait_for_sndbuf() checks both under the lock before any
successful return; a tripped check propagates as err < 0 and the loop
bails before the re-derive.
The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the
loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so
the @tmp cached by list_for_each_entry_safe() still covers the
lock-held free that ba59fb027307 ("sctp: walk the list of asoc
safely") was added for.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Produtos afetados
Linux · LinuxCVEs relacionadas — Linux
No mesmo produto, das mais perigosas para as menos.
CVE-2026-31431HIGHcrypto: algif_aead - Revert to operating out-of-placeEPSS 98.1%KEVCVE-2026-46300HIGHnet: skbuff: preserve shared-frag marker during coalescingEPSS 16.1%KEVCVE-2024-53197HIGHALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesEPSS 4.1%KEVCVE-2024-53104HIGHmedia: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_formatEPSS 3.4%KEVCVE-2025-39682CRITICALtls: fix handling of zero-length records on the rx_listEPSS 3.2%KEVCVE-2024-36971HIGHnet: fix __dst_negative_advice() raceEPSS 2.7%KEV
Referências
https://access.redhat.com/errata/RHSA-2026:26462https://access.redhat.com/errata/RHSA-2026:26515https://access.redhat.com/errata/RHSA-2026:26535https://access.redhat.com/errata/RHSA-2026:26563https://access.redhat.com/errata/RHSA-2026:27731https://access.redhat.com/errata/RHSA-2026:27735https://access.redhat.com/errata/RHSA-2026:33899https://access.redhat.com/errata/RHSA-2026:34094https://access.redhat.com/errata/RHSA-2026:36018https://access.redhat.com/errata/RHSA-2026:36348https://access.redhat.com/errata/RHSA-2026:36349https://access.redhat.com/errata/RHSA-2026:36956