0xblackash/cve-2026-74469Research repository for CVE-2026-74469 (DiagSpill), a Linux kernel SCTP peer transport counter overflow causing an out-of-bounds write, with PoC, root-cause analysis, and patch details.
DiagSpill
A Linux kernel SCTP vulnerability caused by a 16-bit peer transport counter
overflow, allowing the counter to wrap from 65535 to 0. During an SCTP
diagnostic dump, the wrapped value can cause insufficient skb payload
reservation followed by an out-of-bounds write of peer address data.
This repository is intended for authorized security research, kernel vulnerability analysis, CTF environments, kernel debugging, and defensive testing only.
Do not use proof-of-concept code against systems without explicit authorization.
| Field | Details |
|---|---|
| CVE | CVE-2026-74469 |
| Codename | DiagSpill |
| Component | Linux Kernel |
| Subsystem | SCTP / sock_diag |
| Affected File | net/sctp/associola.c |
| Primary Function | sctp_assoc_add_peer() |
| Bug Class | Integer overflow / Out-of-bounds write |
| Impact | Kernel memory corruption |
| Potential Impact | Local privilege escalation |
| CVSS v3.1 | 7.0 — High |
| Attack Vector | Local |
| Attack Complexity | High |
| Privileges Required | Low |
| User Interaction | None |
| Status | Patched |
The Linux Kernel CVE advisory describes the issue as a 16-bit
transport_count overflow in SCTP, followed by an undersized INET_DIAG_PEERS
allocation and an out-of-bounds write during diagnostic dumping.
The vulnerable code maintains the number of unique peer transports in a 16-bit counter:
transport_count
Every newly added unique peer increments the counter.
The critical boundary is:
65535
Adding another unique transport causes:
65535 + 1
↓
0
The resulting wraparound creates an inconsistency between:
transport_count
and:
transport_addr_list
The diagnostic subsystem later trusts the wrapped counter when calculating the size of the response buffer, while still iterating through the complete list of peer addresses.
The vulnerability can be represented as:
SCTP Association
│
▼
Add unique peers
│
▼
transport_count
uint16_t
│
▼
65,535 peers
│
▼
+ 1 unique peer
│
▼
Integer wrap
│
▼
transport_count = 0
│
▼
SCTP sock_diag
│
▼
Reserve incorrect payload
│
▼
Iterate complete peer list
│
▼
Out-of-bounds skb write
The upstream advisory specifically states that the 65,536th transport wraps the counter to zero.
The diagnostic code effectively relies on two different views of the same state.
transport_count
│
▼
payload size
transport_addr_list
│
▼
copy every peer address
After the integer wraps:
transport_count = 0
transport_addr_list =
[peer 1]
[peer 2]
[peer 3]
...
[peer 65536]
The allocator therefore reserves space based on:
0 peers
while the copy operation can still process:
65536 peer addresses
This mismatch produces the memory-safety violation.
The Linux Kernel advisory describes the resulting diagnostic dump as reserving an empty payload and then writing approximately 8 MiB of peer addresses past the skb tail.
Conceptually:
Expected skb:
┌───────────────────────────────┐
│ INET_DIAG header │
├───────────────────────────────┤
│ Peer addresses │
└───────────────────────────────┘
▲
│
valid end
Actual vulnerable state:
┌───────────────────────────────┐
│ INET_DIAG header │
└───────────────────────────────┘
▲
│
skb tail
↓
Peer address writes
↓
Peer address writes
↓
Peer address writes
↓
OUT-OF-BOUNDS WRITE
Red Hat classifies the flaw as CWE-787: Out-of-bounds Write.
The relevant path can be summarized as:
SCTP association
│
▼
sctp_assoc_add_peer()
│
▼
transport_count++
│
▼
16-bit overflow
│
▼
SCTP sock_diag
│
▼
INET_DIAG_PEERS
│
▼
skb payload reservation
│
▼
transport_addr_list iteration
│
▼
Out-of-bounds write
The affected source file is:
net/sctp/associola.c
The Linux Kernel CVE announcement identifies this file explicitly.
The upstream fix is:
bd0e9289e2642f6a5c54faad304ce0f41e926d22
Commit:
sctp: prevent peer transport count overflow
The fix rejects a new unique peer when:
transport_count >= U16_MAX
Importantly, the check occurs after the existing-peer lookup.
That preserves the ability to retrieve an already-existing transport even when the association has reached the limit.
New peer
│
▼
transport_count++
│
▼
Possible 16-bit wrap
│
▼
Diagnostic size mismatch
│
▼
OOB write
New peer
│
▼
Existing peer?
│
┌─┴──────────┐
│ │
YES NO
│ │
▼ ▼
Reuse Check U16_MAX
transport │
▼
Reject at limit
The important security property is preventing the counter from ever wrapping while preserving normal lookup semantics for an existing peer.