Skip to main content
VulnerabilityPublished Updated

CVE-2026-23125: Linux kernel · sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · fixed in e94294798548e8cfbd80869e1d2f97efce92582c : update Linux kernel when convenient.

Data as of 26 Oct 2026, 14:18 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-06-10.

Patch
Available – fixed in e94294798548e8cfbd80869e1d2f97efce92582c, e7e81abbcc5620c9532080538f9709a6ea382855, bf2b543b3cc4ebb4ab5bca4f8dfa5612035d45b8 +4

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 14 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < e94294798548e8cfbd80869e1d2f97efce92582c
Fixed in
  • e94294798548e8cfbd80869e1d2f97efce92582c
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < e7e81abbcc5620c9532080538f9709a6ea382855
Fixed in
  • e7e81abbcc5620c9532080538f9709a6ea382855
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < bf2b543b3cc4ebb4ab5bca4f8dfa5612035d45b8
Fixed in
  • bf2b543b3cc4ebb4ab5bca4f8dfa5612035d45b8
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < a80c9d945aef55b23b54838334345f20251dad83
Fixed in
  • a80c9d945aef55b23b54838334345f20251dad83
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < 784428ab1889eb185a1459e9d6bc52df33d572ef
Fixed in
  • 784428ab1889eb185a1459e9d6bc52df33d572ef
LinuxLinuxAffected
  • ≥ 730fc3d05cd4ba4c9ce2de91f3d43349e95dbbf5, < 5a309bedf02ee08b0653215f06c94d61ec7a214a
Fixed in
  • 5a309bedf02ee08b0653215f06c94d61ec7a214a

Description

In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.

References

Community reviews

Loading reviews…