Look up another CVE · open CVE-2026-68376 in the interactive tracker
CVE-2026-68376
sctp: fix auth_hmacs array size in struct sctp_cookie
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem include/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-68376 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/net/sctp/structs.h
- What this is
- SCTP PROTOCOLMAINTAINERS section matched on include/net/sctp/ · linux-sctp@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 8.1 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.50%, higher than 41.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.24 | 5.10.265 | 317731d01b03 |
| 2.6.24 | 5.15.216 | 0528485f2701 |
| 2.6.24 | 6.1.183 | ee5e65964f45 |
| 2.6.24 | 6.6.148 | 0b4414e43e08 |
| 2.6.24 | 6.12.101 | d0a59ba58578 |
| 2.6.24 | 6.18.42 | a8d20ba0ab51 |
| 2.6.24 | 7.1.6 | 3aa40c3bccac |
| 2.6.24 | 7.2 | e0b5252a5938 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The out-of-bounds index is taken directly from the `hmac_id` field of an AUTH chunk received from a remote SCTP peer and processed in sctp_sf_eat_auth()/sctp_sf_authenticate(), which is the normal SCTP packet-receive path in net/sctp.
- AC:HAttack complexity, high
- The overflow only occurs when the victim endpoint was configured with exactly four HMAC identifiers via setsockopt(SCTP_HMAC_IDENT); three or fewer fit the buffer exactly. That local socket configuration is beyond a remote attacker's control, though a local user can arrange it and then attack over loopback.
- PR:NPrivileges required, none
- Once the endpoint is so configured, any peer that completes an ordinary SCTP handshake can send the malformed AUTH chunk; the bogus hmac_id is accepted and dereferenced before any shared-key or HMAC verification, so no credentials of any kind are needed.
- UI:NUser interaction, none
- The AUTH chunk is consumed automatically by the kernel SCTP state machine on packet receipt; no action by any local user or administrator is needed at attack time.
- S:UScope, unchanged
- The corruption and the subsequent out-of-bounds accesses are confined to kernel memory within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- sctp_auth_get_hmac() reads far past the 4-entry sctp_hmac_list, and on kernels before the HMAC library conversion sctp_auth_calculate_hmac() reads a function-table pointer ~262 KB beyond the 4-pointer ep->auth_hmacs heap array; the accepted/rejected signature length acts as an oracle leaking the out-of-bounds value.
- I:HIntegrity impact, high
- The wild crypto_shash pointer fetched out of bounds is passed straight to crypto_shash_setkey()/crypto_shash_tfm_digest(), giving an attacker-groomable indirect call and write target; on current kernels a fixed 32-byte HMAC is written into a digest area sized from out-of-bounds data.
- A:HAvailability impact, high
- Dereferencing an out-of-bounds heap pointer as a crypto transform, or writing a 32-byte digest into an undersized skb region, reliably oopses or panics the kernel, and the attack can be repeated on every association.