⚠️ Haftungsausschluss

Dieses Repository ist ausschließlich für autorisierte Sicherheitsforschung, Kernel-Schwachstellenanalyse, CTF-Umgebungen, Kernel-Debugging und defensive Tests gedacht.

Verwenden Sie Proof-of-Concept-Code nicht gegen Systeme ohne ausdrückliche Autorisierung.

📌 Überblick über die Schwachstelle

Die CVE-Meldung des Linux-Kernels beschreibt das Problem als einen 16-Bit-Überlauf von transport_count in SCTP, gefolgt von einer zu klein dimensionierten INET_DIAG_PEERS-Allokation und einem Out-of-Bounds-Schreiben während des Diagnose-Dumps.

🧬 Beschreibung der Schwachstelle

Der verwundbare Code verwaltet die Anzahl der eindeutigen Peer-Transports in einem 16-Bit-Zähler:

transport_count

Jeder neu hinzugefügte eindeutige Peer erhöht den Zähler.

Die kritische Grenze ist:

65535

Das Hinzufügen eines weiteren eindeutigen Transports bewirkt:

65535 + 1
     ↓
     0

Der resultierende Überlauf erzeugt eine Inkonsistenz zwischen:

transport_count

und:

transport_addr_list

Das Diagnose-Subsystem vertraut später auf den umgeschlagenen Zähler, wenn es die Größe des Antwortpuffers berechnet, während es weiterhin durch die vollständige Liste der Peer-Adressen iteriert.

🔬 Ursache

Die Schwachstelle lässt sich wie folgt darstellen:

                    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

Die Upstream-Meldung besagt ausdrücklich, dass der 65.536ste Transport den Zähler auf null umschlagen lässt.

🧠 Warum der Fehler auftritt

Der Diagnose-Code stützt sich effektiv auf zwei unterschiedliche Sichten auf denselben Zustand.

Allokationsseite

transport_count
       │
       ▼
payload size

Kopierseite

transport_addr_list
       │
       ▼
copy every peer address

Nach dem Integer-Überlauf:

transport_count = 0

transport_addr_list =
    [peer 1]
    [peer 2]
    [peer 3]
    ...
    [peer 65536]

Der Allokator reserviert daher Speicher basierend auf:

0 peers

während die Kopieroperation weiterhin verarbeiten kann:

65536 peer addresses

Diese Diskrepanz erzeugt die Speichersicherheitsverletzung.

💥 Speicherkorruption

Die Meldung des Linux-Kernels beschreibt den resultierenden Diagnose-Dump als Reservierung einer leeren Payload und anschließendem Schreiben von etwa 8 MiB an Peer-Adressen über das skb-Ende hinaus.

Konzeptionell:

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 klassifiziert den Fehler als CWE-787: Out-of-bounds Write.

🔎 Verwundbarer Codepfad

Der relevante Pfad lässt sich wie folgt zusammenfassen:

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

Die betroffene Quelldatei ist:

net/sctp/associola.c

Die CVE-Ankündigung des Linux-Kernels benennt diese Datei ausdrücklich.

🩹 Upstream-Fix

Der Upstream-Fix ist:

bd0e9289e2642f6a5c54faad304ce0f41e926d22

Commit:

sctp: prevent peer transport count overflow

Der Fix lehnt einen neuen eindeutigen Peer ab, wenn:

transport_count >= U16_MAX

Wichtig ist, dass die Prüfung nach der Suche nach einem bestehenden Peer erfolgt.

Dadurch bleibt die Möglichkeit erhalten, einen bereits existierenden Transport abzurufen, selbst wenn die Association das Limit erreicht hat.

🛡️ Patch-Logik

Verwundbar

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

Gepatcht

New peer
   │
   ▼
Existing peer?
   │
 ┌─┴──────────┐
 │            │
YES           NO
 │            │
 ▼            ▼
Reuse       Check U16_MAX
transport       │
                ▼
          Reject at limit

Die wichtige Sicherheitseigenschaft besteht darin, zu verhindern, dass der Zähler jemals umschlägt, während die normale Suchsemantik für einen bestehenden Peer erhalten bleibt.

📊 Verwundbar vs. Gepatcht

💥 Sicherheitsauswirkung

Die Speicherkorruption kann potenziell zu Folgendem führen:

• Kernel-Absturz
• Denial of Service
• Korruption des Kernel-Speichers
• Out-of-Bounds-Schreiben im Kernel
• Potenzielle Rechteausweitung
• Potenzielle Ausführung von Kernel-Code

Öffentliche Forschung, die nach der Offenlegung veröffentlicht wurde, berichtet über lokale Root-Ausnutzung unter bestimmten Bedingungen, während die ursprüngliche Bewertung des Linux-Kernel-CNA AV:L/AC:H/PR:L/UI:N verwendet.

Die Schwachstelle wird auch als potenziell remote erreichbar unter sehr spezifischen SCTP-/Adresskonfigurationsumständen beschrieben, was jedoch nicht mit einer allgemein remote ausnutzbaren Schwachstelle gleichgesetzt werden sollte.

🧪 Forschungsumgebung

Empfohlene isolierte Topologie:

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

Nützliche Werkzeuge:

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

SCTP-Unterstützung prüfen:

lsmod | grep sctp

Kernel-Konfiguration prüfen:

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

🔎 Kernel-Verifikation

Laufenden Kernel prüfen:

uname -r

SCTP-Konfiguration prüfen:

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

Geladene SCTP-Module prüfen:

lsmod | grep -i sctp

SCTP-Sockets inspizieren:

ss -A sctp

🧪 Reproduktions-Workflow

Für kontrollierte Kernel-Forschung:

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

Kernel-Ausgabe überwachen:

sudo dmesg -w

Zum Debuggen:

gdb vmlinux

oder:

pwndbg vmlinux

📂 Repository-Struktur

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

🛡️ Gegenmaßnahmen

Die primäre Gegenmaßnahme ist die Aktualisierung auf einen Kernel, der den Upstream-Fix enthält.

Für Debian/Kali:

sudo apt update
sudo apt full-upgrade

Danach neu starten:

sudo reboot

Überprüfen:

uname -r

Wenn SCTP nicht benötigt wird, können Administratoren auch in Betracht ziehen, die betroffene SCTP-Funktionalität entsprechend ihrer Umgebung und betrieblichen Anforderungen zu deaktivieren. Die öffentliche Forschung nennt insbesondere das Deaktivieren von SCTP / sctp_diag als sofortige Gegenmaßnahme, wenn diese Komponenten nicht verwendet werden.

📦 Behobene Kernel-Versionen

Die Upstream-Stable-Ankündigung nennt diese behobenen Versionen:

Diese Versionen stammen aus der CVE-Ankündigung des Linux-Kernels; Distributionen können den Fix in Pakete mit abweichender Versionsnummerierung zurückportieren.

🧩 Sicherheitslektionen

01 — Begrenzte Zähler dürfen niemals stillschweigend überlaufen

Ein 16-Bit-Zähler hat ein hartes Maximum:

U16_MAX = 65535

Sicherheitsrelevanter Code muss diese Grenze explizit behandeln.

02 — Allokations- und Kopieranzahl müssen übereinstimmen

Die Größe, die zum Allokieren eines Puffers verwendet wird, muss der Anzahl der tatsächlich hineinkopierten Objekte entsprechen.

03 — Diagnose-Schnittstellen sind sicherheitsrelevant

Kernel-Diagnose-APIs können zu Angriffsflächen für Speicherkorruption werden, wenn der interne Zustand inkonsistent wird.

04 — Integer-Fehler können zu Speichersicherheitsfehlern werden

Der ursprüngliche Primitive ist ein Integer-Überlauf, aber die resultierende Sicherheitsauswirkung ist ein Out-of-Bounds-Schreiben im Kernel.

05 — Der Netzwerkzustand des Kernels ist komplex

SCTP-Assoziationen können große Sammlungen von Peer-Transports enthalten, was Zählerlimits und Listenverwaltungslogik sicherheitskritisch macht.

📚 Referenzen

• CVE: CVE-2026-74469
• Codename: DiagSpill
• Subsystem: Linux SCTP
• Betroffene Datei: net/sctp/associola.c
• Primäre Funktion: 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