CVE-2026-23125

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