⚠️ Disclaimer

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.

📌 Vulnerability Overview

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.

🧬 Vulnerability Description

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.

🔬 Root Cause

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.

🧠 Why the Bug Happens

The diagnostic code effectively relies on two different views of the same state.

Allocation side

transport_count
       │
       ▼
payload size

Copy side

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.

💥 Memory Corruption

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.

🔎 Vulnerable Code Path

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.

🩹 Upstream Fix

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.

🛡️ Patch Logic

Vulnerable

New peer
   │
   ▼
transport_count++
   │
   ▼
Possible 16-bit wrap
   │
   ▼
Diagnostic size mismatch
   │
   ▼
OOB write

Patched

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.

📊 Vulnerable vs Patched

💥 Security Impact

The memory corruption can potentially result in:

• Kernel crash
• Denial of service
• Kernel memory corruption
• Out-of-bounds kernel write
• Potential privilege escalation
• Potential kernel code execution

Public research released after the disclosure reports local-root exploitation under specific conditions, while the original Linux Kernel CNA scoring uses AV:L/AC:H/PR:L/UI:N.

The vulnerability is also described as potentially remotely reachable under very specific SCTP/address-configuration circumstances, but that should not be treated as equivalent to a generally remotely exploitable vulnerability.

🧪 Research Environment

Recommended isolated topology:

┌───────────────────────────────────────────┐
│              Linux VM                    │
│                                           │
│       ┌───────────────────┐               │
│       │   SCTP Association │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│       ┌───────────────────┐               │
│       │ Multiple SCTP      │               │
│       │ Peer Transports    │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│       ┌───────────────────┐               │
│       │   SCTP sock_diag   │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│          INET_DIAG_PEERS                  │
│                                           │
└───────────────────────────────────────────┘

Useful tools:

ip sctp
ss
ss -a
ss -A sctp
dmesg -w
gdb
pwndbg
crash

Check SCTP support:

lsmod | grep sctp

Check kernel configuration:

grep CONFIG_IP_SCTP /boot/config-$(uname -r)

🔎 Kernel Verification

Check the running kernel:

uname -r

Check SCTP configuration:

grep -E 'CONFIG_IP_SCTP|CONFIG_SCTP' \
/boot/config-$(uname -r)

Check loaded SCTP modules:

lsmod | grep -i sctp

Inspect SCTP sockets:

ss -A sctp

🧪 Reproduction Workflow

For controlled kernel research:

01. Build vulnerable kernel
          ↓
02. Boot isolated VM
          ↓
03. Enable SCTP
          ↓
04. Create controlled SCTP association
          ↓
05. Populate unique peer transports
          ↓
06. Reach transport-count boundary
          ↓
07. Trigger SCTP diagnostic dump
          ↓
08. Monitor skb diagnostics
          ↓
09. Capture kernel behavior
          ↓
10. Apply upstream fix
          ↓
11. Repeat test
          ↓
12. Compare vulnerable vs patched

Monitor kernel output:

sudo dmesg -w

For debugging:

gdb vmlinux

or:

pwndbg vmlinux

📂 Repository Structure

CVE-2026-74469-DiagSpill/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── root-cause.md
│   ├── sctp-transport-count.md
│   ├── sock-diag.md
│   ├── skb-overflow.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable/
│   └── patched/
│
├── lab/
│   ├── setup.sh
│   ├── cleanup.sh
│   └── topology.md
│
├── screenshots/
│
├── docs/
│   └── research-notes.md
│
└── LICENSE

🛡️ Mitigation

The primary mitigation is upgrading to a kernel containing the upstream fix.

For Debian/Kali:

sudo apt update
sudo apt full-upgrade

Then reboot:

sudo reboot

Verify:

uname -r

If SCTP is not required, administrators can also consider disabling the affected SCTP functionality according to their environment and operational requirements. The public research specifically lists disabling SCTP / sctp_diag as an immediate mitigation when those components are unused.

📦 Fixed Kernel Releases

The upstream stable announcement lists these fixed releases:

These versions are from the Linux Kernel CVE announcement; distributions may backport the fix into packages with different version numbering.

🧩 Security Lessons

01 — Never allow bounded counters to wrap silently

A 16-bit counter has a hard maximum:

U16_MAX = 65535

Security-sensitive code must explicitly handle that boundary.

02 — Allocation and copy counts must agree

The size used to allocate a buffer must correspond to the number of objects actually copied into it.

03 — Diagnostic interfaces are security-sensitive

Kernel diagnostic APIs can become memory-corruption attack surfaces when internal state becomes inconsistent.

04 — Integer bugs can become memory-safety bugs

The original primitive is an integer overflow, but the resulting security impact is an out-of-bounds kernel write.

05 — Kernel networking state is complex

SCTP associations can contain large collections of peer transports, making counter limits and list-management logic security-critical.

📚 References

• CVE: CVE-2026-74469
• Codename: DiagSpill
• Subsystem: Linux SCTP
• Affected file: net/sctp/associola.c
• Primary function: sctp_assoc_add_peer()
• Fix: sctp: prevent peer transport count overflow
• Upstream fix: bd0e9289e2642f6a5c54faad304ce0f41e926d22
• CWE: CWE-787 / Out-of-bounds Write
• Linux Kernel CVE Advisory: CVE-2026-74469 advisory
• Debian Security Tracker: CVE-2026-74469 Debian tracker
• Red Hat: CVE-2026-74469 Red Hat advisory