CVE-2026-74586 — SCTP ASCONF new_transport use-after-free ट्रिगर

CVE-2026-74586 के लिए एक स्व-निहित, अनप्रिविलेज्ड PoC, जो Linux कर्नेल की SCTP ASCONF (डायनामिक एड्रेस रीकॉन्फ़िगरेशन) हैंडलिंग में एक use-after-free है। बग का श्रेय स्वयं Qing Ming को जाता है, जिन्होंने इसे अपस्ट्रीम में रिपोर्ट किया; फ़िक्स कमिट beb33f8ee1ca ("sctp: clear new_transport when removing a peer") है, जिसे 2026-08-12 को Cc: stable के साथ मर्ज किया गया — Red Hat इसे important रेट करता है, तृतीय-पक्ष ट्रैकर्स इसे CVSS 9.8 पर रखते हैं।

यह रेपो एडवाइज़री के ऊपर जो जोड़ता है:

• एक कार्यशील रॉ-पैकेट ट्रिगर, किसी कर्नेल पैच या विशेष टूल की आवश्यकता नहीं
• स्टॉक डिस्ट्रो कर्नेल पर मापी गई विश्वसनीयता: Kali के 7.1.5+kali-amd64 के विरुद्ध 1,397 स्वचालित रनों में 1,394 हिट (99.8%)
• वे तीन इंजेक्शन बैरियर जिन्हें किसी भी रॉ ASCONF कार्य के लिए हल करना होता है, क्योंकि अन्यथा कर्नेल चुपचाप पैकेट को ड्रॉप कर देता है
• 7.1.5 sctp मॉड्यूल के लिए struct ऑफ़सेट (objdump से, अनुमान से नहीं) और इस बारे में नोट्स कि हथियारीकरण किस हद तक पहुँचता है इससे पहले कि वह एक कठोर दीवार से टकराए

बग

sctp_process_asconf_param() ADD-IP पैरामीटर द्वारा बनाए गए ट्रांसपोर्ट को asoc->new_transport में संग्रहीत करता है। उसी ASCONF चंक में उसी एड्रेस के लिए एक DEL-IP उस ट्रांसपोर्ट को sctp_assoc_rm_peer() के माध्यम से मुक्त कर देता है, जो (फ़िक्स से पहले) new_transport को साफ़ नहीं करता। जब sctp_process_asconf() लौटता है, तो sctp_sf_do_asconf() उस स्टेल पॉइंटर पर कार्य करता है — स्टॉक कर्नेल पर दृश्य प्रभाव अभी-अभी मुक्त किए गए ट्रांसपोर्ट के एड्रेस की ओर भेजा गया एक HEARTBEAT है; KASAN के अंतर्गत यह slab-use-after-free रिपोर्ट है।

एक ASCONF चंक ही पर्याप्त है:

[Address Parameter L] [ADD-IP G] [DEL-IP G]

बिल्ड और रन करना

gcc -O2 -Wall -o poc poc.c
./poc

रूट नहीं। PoC एक user + network namespace को unshare करता है, उसमें SCTP sysctls सेट करता है, loopback पर एक multi-homed association उठाता है, फिर raw socket के साथ तैयार किया गया ASCONF इंजेक्ट करता है।

कमजोर kernel पर अपेक्षित आउटपुट:

[+] Association established (no AUTH)
[+] server_vtag=0x... captured_tsn=0x...
[*] serial=0x... (= initial_tsn)
[+] Injected 60 bytes
  [9222->9111 vt=...] ASCONF-ACK(0x80) len=8
  [+] ASCONF-ACK -> server processed ADD-IP + DEL-IP
  [9222->9111 vt=...] HB(0x04) len=60        <- kernel using freed transport
  [9111->9222 vt=...] ABORT(0x06) len=8
[+] GhostTransport UAF TRIGGERED (ASCONF-ACK received)
[+] HEARTBEAT to ghost address observed (dangling transport USED)

ACK के बाद HEARTBEAT दिलचस्प हिस्सा है: वह पैकेट केवल इसलिए मौजूद है क्योंकि kernel ने लटके हुए new_transport को ट्रैवर्स किया। client ठीक उसके बाद ABORT करता है क्योंकि heartbeat अचानक से वापस आ गया।

कच्चा इंजेक्शन क्यों परेशानी भरा है (तीन बाधाएँ)

इसमें से कुछ भी नया शोध नहीं है, यह बस इतना अप्रलेखित है कि एक दोपहर बर्बाद कर देता है, इसलिए अगले व्यक्ति के लिए यह यहाँ है:

1. CRC32c. Loopback आपको raw socket पैकेट्स के लिए CHECKSUM_UNNECESSARY नहीं देता, इसलिए sctp_rcv() checksum सत्यापित करता है और मेल न खाने पर ड्रॉप कर देता है। पूरे SCTP पैकेट पर checksum फ़ील्ड को शून्य करके CRC32C (poly 0x82F63B78, reflected) की गणना करें।
2. दूसरा auth चेक। sctp_auth_recv_cid() इनपुट पथ में state machine से पहले चलता है और unauthenticated ASCONF को ड्रॉप कर देता है, भले ही addip_noauth_enable=1 हो — वह sysctl केवल sctp_sf_do_asconf() के अंदर के चेक को ढीला करता है। बचने का रास्ता यह है कि socket स्तर पर AUTH की बातचीत ही कभी न करें (कोई SCTP_AUTH_SUPPORTED setsockopt नहीं), ताकि peer.auth_capable false रहे और दोनों चेक पास हो जाएँ।
3. सीरियल। पहला स्वीकृत ASCONF सीरियल = peer का प्रारंभिक TSN। कोई भी DATA chunk कैप्चर करें, उसका TSN लें, एक घटाएँ। यहाँ off-by-one होने पर chunk चुपचाप त्याग दिया जाता है।

प्रभावित / ठीक किया गया

upstream commit पर Fixes: टैग 6af29ccc223b ("sctp: Bundle HEARTBEAT into ASCONF_ACK") है, इसलिए कोड पुराना है। mainline में ठीक किया गया और stable श्रृंखला में backport किया गया (Debian tracker: sid में 7.1.9-1 से ठीक, trixie-security में 6.12.107)। 2026-09-09 तक Kali rolling हर suite में 7.1.5-1kali1 भेजता है, जो इन सबसे पहले का है — यही इस PoC की मुख्य व्यावहारिक प्रासंगिकता है।

Weaponization नोट्स (यह कहाँ रुकता है)

आगे ले जाने वाले किसी भी व्यक्ति के लिए — QEMU में 7.1.5 के मुकाबले मापा गया, भेजे गए sctp.ko के objdump -d से offsets:

field	offset
flowi (88 bytes)	0x30
ipaddr	0x88
af_specific	0xa8
asoc	0xb0
dst	0xe0
state	0x15c
rcu	0x2b0

sctp_association->new_transport 0x6b0 पर है। यह तालिका चालू kernel पर pahole -C sctp_transport /sys/kernel/btf/vmlinux से आती है — इस तालिका के पिछले संस्करण में ipaddr offset गलत था (0x68, flowi की गलत गिनती से); BTF ही सत्य का आधार है।

• यहाँ free एकल है (RCU कॉलबैक sctp_transport_destroy_rcu), इस पथ पर कोई double-free नहीं है। यदि आप सोच रहे थे कि सॉकेट बंद करके दो frees मिलेंगे — sctp_association_free() केवल transport सूची पर चलता है, और rm_peer() पहले ही ghost को unlink कर चुका है। उस पर एक शाम बर्बाद न करें।
• sctp_outq_select_transport() chunk के +0xe8 पर chunk->transport से +0x15c पर state पढ़ता है। state=1 (ACTIVE) के साथ spray किया गया एक reclaimed ऑब्जेक्ट free के बाद kernel व्यवहार बदल देता है — ऑब्जेक्ट से परामर्श लिया जा रहा है।
• instrumented रनों से समय-सुधार: select साइट पर stale read ASCONF इंजेक्शन के माइक्रोसेकंड्स के भीतर होता है — kernel तार्किक रूप से मृत (RCU-pending) transport को पढ़ता है जबकि spray अभी सेकंडों दूर है। एक instrumented रन ने पकड़ा कि sctp_outq_select_transport() इंजेक्ट समय पर ही एक stale transport pointer से state=0xFFFF (slab कचरा) पढ़ रहा था। परिणाम: spray को trigger से पहले cache को pre-groom करना होगा, बाद में नहीं — इस पथ पर grace period समाप्त होने से पहले ही ऑब्जेक्ट पढ़ा जाता है।
• उसके आगे का गेट +0x288 पर खाली-सूची जाँच है: kernel *(p+0x288) की तुलना p+0x288 से करता है। वह एक self-pointer है। slab पता जाने बिना आप spray करके उससे पार नहीं पा सकते, अर्थात् इस bug को af_specific नियंत्रण के instruction-pointer नियंत्रण में बदलने से पहले एक info leak चाहिए। af_specific स्वयं एक indirect call साइट है (*(af_specific+0x18) जिसमें rdi = transport), तो leak होने पर वही इनाम है।
• काम करने वाला spray primitive: 800-बाइट key के साथ setsockopt(SCTP_AUTH_KEY) उसी kmalloc-1k cache में पहुँचता है। याद रखें header struct sctp_authkey { assoc_id; keynumber; keylength; key[] } है और AUTH को पहले प्रति-सॉकेट SCTP_AUTH_SUPPORTED के साथ sctp_assoc_value से सक्षम करना होता है — सादा int EINVAL देता है।

दायरा

यह एक trigger/crash PoC है। यह privilege escalation नहीं है और यह repo ऐसा दावा नहीं करता। इसे VM में अपने ही kernels पर चलाएँ।

परीक्षण किया गया: 7.1.5+kali-amd64 (Kali रोलिंग) और 7.0.12+kali-amd64 पर।

संदर्भ

• फ़िक्स: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=beb33f8ee1ca83acddb2a5ae80f3d22ec550b4c3
• Debian ट्रैकर: https://security-tracker.debian.org/tracker/CVE-2026-74586
• Qing Ming द्वारा मूल रिपोर्ट (commit संदेश में lore लिंक)

लाइसेंस

तर्क के kernel-व्युत्पन्न भागों के लिए GPL-2.0; बाकी के साथ जो चाहें करें। केवल अधिकृत सुरक्षा परीक्षण और अनुसंधान के लिए।

दूसरा PoC: acklock.c — ASCONF-ACK soft-lockup (सभी 7.1.x में अनफ़िक्स्ड)

उसी कोड पथ में एक दूसरा अनपैच्ड kernel bug, 7.1.5 पर प्रदर्शित: sctp_verify_asconf() बिना न्यूनतम लंबाई के ERR_CAUSE TLV स्वीकार करता है और PAD4-संरेखित parameters पर चलता है, जबकि sctp_get_asconf_response() (ASCONF-ACK उपभोक्ता) RAW लंबाई से आगे बढ़ता है। एक तैयार किया गया ASCONF-ACK जिसके ERR_CAUSE TLV की लंबाई 5 है, उपभोक्ता को 3 बाइट से desync कर देता है; अगले 4 बाइट तब length = 0 वाले parameter header के रूप में पढ़े जाते हैं, और asconf_ack_len -= 0 अनंत काल तक घूमता रहता है — softirq में एक अनंत लूप (ksoftirqd 100% पर अटका, CPU भूखा, 7.1.5 पर 3/3 lab रनों में clocksource-watchdog timeouts द्वारा पुष्ट)।