Cloudanix VulnDB

CVE-2026-99165

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's SCTP networking code can cause the entire system to crash when certain network messages are processed under specific timing conditions.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Null pointer dereference in sctp_outq_tail when a send-path wait drops the socket lock, allowing stream reconfiguration to free a stream's extension while leaving the stream index in range; subsequent dereference of the NULL extension triggers fatal oops.

Why it matters to the business

Remote or local trigger can panic the kernel, causing immediate host crash and denial of service; high impact on systems using SCTP with message interleaving enabled.

How an attack unfolds

An attacker establishes an SCTP association with message interleaving enabled, sends a message that waits for association completion, forces peer-driven stream count reduction during the unlocked window, then resumes the send so that sctp_outq_tail dereferences the now-NULL stream extension, resulting in kernel panic.

How to fix it

Apply the upstream kernel patch that factors range and extension validation into a helper repeated after every send-path wait; rebuild and deploy the fixed kernel; disable SCTP or message interleaving where not required as a temporary mitigation.

How to confirm the fix worked

Confirm the presence of the revalidation helper after connect and send-buffer waits in sctp_sendmsg paths; test that ESRCH is returned on validation failure after association establishment rather than proceeding with a freed stream; verify no KASAN null-ptr-deref reports under interleaving workloads.

Typical attack path

  1. Enable SCTP message interleaving on the target socket
  2. Initiate association establishment and issue a send that blocks on connect wait
  3. Trigger stream reconfiguration that shrinks output streams and frees extensions
  4. Resume the blocked send so the stale stream index is used after lock reacquisition
  5. sctp_outq_tail dereferences NULL extension and panics the kernel

How to detect it

Search kernel logs and KASAN reports for null-ptr-deref originating from sctp_outq_tail after sctp_sendmsg or sctp_primitive_SEND; correlate with SCTP association establishment events and stream reconfiguration activity.

  • 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

What your security team should do

  • Prioritize kernel upgrade on all systems exposing SCTP sockets with interleaving
  • Monitor for rapid kernel oops involving sctp_outq_tail and schedule emergency patching
  • Review SCTP usage and disable interleaving unless explicitly required
  • Add kernel crash and SCTP error logging to existing SIEM rules for early detection

The record

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.

Affected packages

Ecosystem Package Introduced Fixed