CVE-2026-23125
Medium · 5.5CVSS
5.5
EPSS
0.1%
Published
Feb 14, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's SCTP networking code can cause systems to crash when handling certain authenticated connections, leading to downtime until fixed software is installed.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Null pointer dereference in sctp_packet_bundle_auth when SCTP-AUTH shared key initialization fails after SCTP_CMD_PEER_INIT, allowing a DATA chunk with auth=1 and shkey=NULL to reach sctp_outq_flush_data and trigger KASAN null-ptr-deref during transmit.
Why it matters to the business
Kernel panic and denial of service on systems using SCTP with authentication, causing unplanned outages and requiring reboots; affected container images must be rebuilt and redeployed.
How an attack unfolds
An attacker with local access crafts an SCTP association where sctp_auth_asoc_init_active_key fails during INIT_ACK processing; the misplaced SCTP_CMD_ASSOC_SHKEY leaves asoc->shkey NULL while auth_capable is set, so a subsequent DATA chunk queued with auth flag reaches the transmit path and dereferences the null pointer when the T1_COOKIE timer fires.
How to fix it
Upgrade to fixed package versions: kube-fluentd-operator 1.18.2-r49, ruby3.3-rails-8.0 8.0.3-r2, ruby3.2-rails-8.0 8.0.3-r2, ruby3.4-rails-7.2 7.2.2.2-r2, ruby3.4-rails-8.0 8.0.3-r2 and equivalents for all listed Chainguard and Wolfi variants; rebuild and redeploy containers with updated kernels containing the reordered SCTP_CMD_ASSOC_SHKEY command.
How to confirm the fix worked
Confirm kernel version contains the patch moving SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT; verify no null-ptr-deref in sctp_packet_append_chunk via KASAN or by exercising SCTP-AUTH INIT_ACK failure paths in test environments.
Typical attack path
- Establish SCTP association with AUTH capable peer
- Trigger failure in sctp_auth_asoc_init_active_key during INIT_ACK handling
- Queue authenticated DATA chunk before COOKIE_ECHO transmission
- Force T1_COOKIE timer to enqueue COOKIE_ECHO and flush outqueue
- Trigger null dereference in sctp_packet_append_chunk
How to detect it
Search kernel logs for KASAN null-ptr-deref reports referencing sctp_packet_append_chunk or sctp_packet_bundle_auth; inspect SCTP association state during INIT_ACK processing for failed shkey initialization followed by DATA transmission.
What your security team should do
- Prioritize patching all affected Chainguard and Wolfi images within normal change windows given low EPSS and local attack vector
- Inventory workloads using SCTP with authentication and schedule kernel updates
- Monitor EPSS trend and any new exploit maturity indicators for escalation
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 2.6.24 | 5.10.249 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.27.1.160000.2.8 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.28.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.28.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel