CVE-2026-64551

Vulnérabilité critique dans Linux (Linux)

CVSS 9.1 · Critique
EPSS 0.5%
Linux•Linux•Versions : <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, 2.6.12, <ebe0a55d954fa8da383b6192edb8f763dcb002d5, 0, <=7.1.*, <2.6.12, 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, <bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0, 6.1.178, <=5.10.*, <=6.6.*, 6.12.97, <=6.18.*, <a257b41ddfe9e327b26581ad2777f04b23ac73f5, 5.15.212, 6.6.145, 5.10.261, <1cd23ca80784223fa2204e16203f754da4e821f8, <588706ebaf8cdb4a4161602949eba365514b1db1, <=*, <=5.15.*, <6022da37786701df1fc5dd946a6dcba59d5473b1, <861f884f5471632c731cbbd612a1c072e391a624, 7.2, <08a8f2d13f703924316e9aeac863a88ef50990c7

Description

In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: err = (struct sctp_errhdr *)(chunk->skb->data); stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.

Gravité et risque d'exploitation

CVE-2026-64551 obtient un score CVSS de 9.1/10, soit une gravité critique. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.51 %, ce qui la place devant 42.6 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, 2.6.12, <ebe0a55d954fa8da383b6192edb8f763dcb002d5, 0, <=7.1.*, <2.6.12, 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, <bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0, 6.1.178, <=5.10.*, <=6.6.*, 6.12.97, <=6.18.*, <a257b41ddfe9e327b26581ad2777f04b23ac73f5, 5.15.212, 6.6.145, 5.10.261, <1cd23ca80784223fa2204e16203f754da4e821f8, <588706ebaf8cdb4a4161602949eba365514b1db1, <=*, <=5.15.*, <6022da37786701df1fc5dd946a6dcba59d5473b1, <861f884f5471632c731cbbd612a1c072e391a624, 7.2, <08a8f2d13f703924316e9aeac863a88ef50990c7) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références