Copy Fail – CVE-2026-31431

 (copy.fail)
9 पॉइंट द्वारा GN⁺ 2026-04-30 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • 2017 के बाद से सभी Linux distributions में root privileges हासिल किए जा सकने वाला container escape privilege escalation vulnerability
  • यह Linux kernel के cryptographic module (authencesn) में मौजूद एक साधारण logic flaw का फायदा उठाता है, और जटिल timing coordination (race condition) या kernel version के हिसाब से tuning के बिना सिर्फ 732-byte की एक Python script से चलाया जा सकता है
  • इसका मुख्य सिद्धांत Linux द्वारा फ़ाइल चलाते समय संदर्भित किए जाने वाले memory cache (page cache) को बदलना है, जिसमें AF_ALG (kernel cryptographic socket) और splice() (data copy system call) को जोड़कर setuid binary की cached copy में 4 bytes overwrite किए जाते हैं
    • वास्तविक disk पर मौजूद फ़ाइल नहीं बदलती, इसलिए यह stealth attack है जिसका निशान forensic disk image में नहीं बचता
    • reboot होने या memory मुक्त होने पर cache फिर मूल रूप में लौट आता है, इसलिए पारंपरिक file integrity checks से बाद में पता लगाना मुश्किल होता है
  • क्योंकि page cache पूरे host में shared होता है, Kubernetes environment में अगर एक pod इस vulnerability का उपयोग करे तो host node पर कब्ज़ा करके दूसरे tenants के containers तक पहुँचने वाला container escape संभव है
  • इसे Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16 पर सीधे verify किया गया, और केवल unprivileged local user account होने पर network access या kernel debugging features के बिना यह तुरंत काम करता है
  • मौजूदा Linux privilege escalation (LPE) vulnerabilities आम तौर पर प्रति प्रयास 30~80% success rate रखती हैं और केवल कुछ खास kernel ranges में काम करती हैं, लेकिन Copy Fail एक ही प्रयास में 100% success rate के साथ 9 साल (2017~2026) तक सभी distributions को प्रभावित करता है
  • इसी page cache manipulation family की Dirty Pipe (pipe buffer flags का दुरुपयोग) और Dirty Cow (timing race की आवश्यकता) के विपरीत, इसमें न race condition है, न distribution-specific offsets, न recompilation की ज़रूरत, इसलिए यह कहीं अधिक सरल और शक्तिशाली है
  • सबसे तात्कालिक जोखिम वाले लक्ष्य: multi-tenant Linux hosts, Kubernetes/container clusters, CI runners (GitHub Actions self-hosting, GitLab runners आदि), user code चलाने वाले cloud SaaS — यानी हर वह environment जहाँ untrusted code shared kernel पर चलता है
  • सबसे पहली प्राथमिकता kernel patch (a664bf3d603d mainline commit) है — 2017 में जोड़ी गई cryptographic module की in-place optimization को वापस लेकर यह सुनिश्चित किया गया है कि page cache pages cryptographic operations के write target में शामिल न हों
  • patch से पहले अस्थायी उपाय के तौर पर algif_aead module को disable किया जा सकता है, और dm-crypt/LUKS·kTLS·IPsec·SSH जैसी सामान्य encryption features पर कोई असर नहीं पड़ता
  • container, sandbox, CI runner जैसे untrusted workload environments में patch की स्थिति से अलग seccomp के ज़रिए AF_ALG socket creation को block करने की सिफारिश की जाती है
  • Xint के Taeyang Lee ने यह शुरुआती insight निकाली कि "splice() जिस तरह page cache pages को encryption subsystem तक पहुँचाता है, वह एक अनछुई bug class है", और Xint Code ने kernel के crypto/ subsystem को लगभग 1 घंटे में अपने-आप scan करके इसे खोज निकाला — यह AI-assisted vulnerability detection का एक उदाहरण है

संबंधित पढ़ाई

5 टिप्पणियां

 
popopo 2026-05-04

लगता है Rocky Linux के लिए अभी तक पैच नहीं आया है

RHEL

Almalinux

Rocky Linux

मैं Rock Linux इस्तेमाल कर रहा हूँ, और अगर आप reboot नहीं कर सकते हैं तो https://github.com/wgnet/wg.copyfail.patch का bpftool से block करना प्रभावी है.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

पैच मौजूद है, लेकिन... यह सिर्फ subscription service repository में ही दिया जा रहा है। CE version पर पैच लागू नहीं है। (9.7, 10.1 की पुष्टि)
 
popopo 2026-05-10

2026-05-05 को patch आ गया था.

2026-05-10 को एक नया security option है.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

लगता है कि security repository जोड़ने पर, RHEL source reflection से अलग भी security measures लागू किए जा सकते हैं.
 
sukso96100 2026-05-02

जो लोग Ubuntu इस्तेमाल कर रहे हैं, उनके लिए कार्रवाई के तरीके की गाइड जारी हो गई है, इसलिए उसे देखकर संदर्भ लिया जा सकता है.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Hacker News की राय

  • Linux kernel crypto code के साथ काम करने के नज़रिए से, बार-बार सामने आने वाले AF_ALG exploit वाकई बेहद निराशाजनक हैं
    AF_ALG बहुत पहले kernel में बिना पर्याप्त review के आ गया था, इसकी संरचना बहुत जटिल है, और यह non-privileged userspace programs के लिए बहुत बड़ा attack surface खोल देता है
    ऊपर से इसकी ज़रूरत भी लगभग नहीं है। userspace में पहले से अपने crypto code मौजूद हैं, और kernel crypto code मूल रूप से dm-crypt जैसे kernel-internal use cases के लिए था
    इस exploit में इस्तेमाल हुआ authencesn भी असल में IPsec का एक internal implementation detail है, इसलिए इसे general-purpose userspace encryption/decryption API के रूप में expose करना शुरू से ही गलत फैसला लगता है
    अगर आप Linux kernel configuration मैनेज करते हैं, तो सभी CONFIG_CRYPTO_USER_API_* options बंद करने की मैं ज़ोरदार सिफारिश करता हूँ
    सिर्फ ऐसा कर देने से ही इस bug के अलावा AF_ALG के कई पुराने और भविष्य के bugs का exploitation असंभव हो जाता
    अगर इससे कोई userspace program टूटता है, तो बेहतर है उसे userspace crypto code पर migrate करने में मदद की जाए, और वास्तव में कुछ चीज़ें पहले ही इस दिशा में बदली जा चुकी हैं
    शुरू से ही AF_ALG का इस्तेमाल exploit के अलावा बहुत ज़्यादा नहीं था
    पहले ऐसे userspace APIs किसी तरह स्वीकार्य रहे होंगे, लेकिन अब syzbot और LLM-assisted bug finding के दौर में इन्हें बचाए रखना मुश्किल है

    • मुझे AF_ALG क्या है यह नहीं पता था, इसलिए खोजा तो https://www.chronox.de/libkcapi/html/ch01s02.html मिला, और वहाँ इसके अस्तित्व की कुछ वजहें दी गई थीं
      तर्क यह था कि kernel mode में ही उपलब्ध hardware accelerators को userspace से इस्तेमाल किया जा सकता है, keys को application memory में लंबे समय तक रखे बिना kernel को सौंपा जा सकता है, और embedded जैसी memory-constrained environments में userspace crypto libraries की तुलना में footprint घटाया जा सकता है
      यह पर्याप्त रूप से मजबूत justification है या नहीं, यह मैं नहीं कह सकता, लेकिन कम से कम कोई वजह तो है
    • मैं जानना चाहता हूँ कि यह आखिर kernel में आया कैसे
      Linus को आम तौर पर इस बात पर काफ़ी सख़्त माना जाता है कि kernel में क्या जाना चाहिए, इसलिए ऐसी API अंदर आने की पृष्ठभूमि दिलचस्प होगी
    • AF_ALG Linux का एक socket interface है जो kernel crypto API को file descriptors के ज़रिए expose करता है
      इससे hashing और encryption को सामान्य read(2)/write(2) calls के माध्यम से संभाला जा सकता है
    • इस kernel option को बंद करने पर कौन सा software टूटेगा, यही सबसे बड़ा सवाल है

  • ऐसा लगता है कि disclosure process में कुछ गड़बड़ी हुई थी
    vendors इस vulnerability को गंभीरता से नहीं ले रहे थे, और इसी वजह से कई distributions में यह अब तक unpatched बनी हुई थी
    https://access.redhat.com/security/cve/cve-2026-31431 पर "Moderate severity", "Fix deferred" लिखा था, और Debian, Ubuntu, SUSE tracking pages पर भी कुछ ऐसा ही दिख रहा था

    • patch kernel में आते ही यह बात हमलावरों या निगरानी करने वालों के लिए कई हफ्तों से व्यावहारिक रूप से सार्वजनिक थी
      लेकिन upstream ने इसे स्पष्ट रूप से vulnerability के रूप में communicate नहीं किया, और Linus तथा Greg kernel में इस तरह की classification को सिद्धांततः बहुत महत्व नहीं देते
    • distributions इसे medium risk मान रहे हैं, शायद इसलिए कि इसमें remote code execution नहीं बल्कि local access चाहिए
      फिर भी अगर local से root privilege escalation संभव है, तो सामान्यतः इसे high priority माना जाना चाहिए
      https://ubuntu.com/security/cves/about#priority
    • RedHat ने अब इसे Important severity और Affected में बदल दिया है
    • Ubuntu की अपनी guidelines देखें तो यह high priority होना चाहिए, लेकिन असली label medium है, इसलिए कुछ inconsistency लगती है

  • यह अफ़सोस की बात है कि कौन से kernel versions vulnerable हैं और किन versions में patch आया, यह मुख्य लेख में तुरंत नहीं लिखा गया
    खासकर इसलिए क्योंकि यह built-in module है, जिसे rmmod से आसानी से हटाया भी नहीं जा सकता
    Fedora 44 के kernel 6.19.14 के vulnerable होने की पुष्टि करने के लिए खोजते हुए मुझे linux-cve-announce mailing list की यह पोस्ट मिली: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    वहाँ लिखा था कि इसे 6.18.22, 6.19.12, और 7.0 में संबंधित commits से ठीक किया गया, इसलिए वह संदर्भ उपयोगी रहा

  • अगर आप यह देखना चाहते हैं कि सुझाए गए mitigation के मुताबिक kernel module algif_aead को modprobe settings से block किया गया है या नहीं, तो obfuscated shell code पूरा चलाने की ज़रूरत नहीं है
    नीचे दिए गए कुछ Python lines से साफ़-साफ़ देखा जा सकता है कि module वास्तव में load हो रहा है या नहीं
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    अगर mitigation सही से लागू हुई है, तो modprobe algif_aead भी error के साथ fail होना चाहिए

  • प्रभावित operating systems पर पूरी तरह autonomous AI agents को सामान्य user privileges के साथ चलाने वाला शायद कोई नहीं होगा
    लेकिन अगर इसे zero-day prompt injection के साथ जोड़ा जाए, तो यह काफ़ी विनाशकारी हो सकता है

    • मेरा agent तो पहले से root पर चल रहा है, इसलिए मुझे यह समस्या नहीं दिख रही
    • शुक्र है, हमने curl | sh से install करना उद्योग का standard नहीं बना दिया

  • LPE का मतलब local privilege escalation है
    security वाले short forms बहुत ज़्यादा होते हैं, और संदर्भ से समझा जा सकता था, लेकिन फिर भी शुरुआत में इसे पूरा लिखना बेहतर होता

    • LPE security community के भीतर काफ़ी जाना-पहचाना acronym है, इसलिए इसे न खोलना बहुत बड़ा अपराध नहीं कहा जा सकता
      फिर भी अगर लेख व्यापक पाठक-वर्ग के लिए लिखा गया हो, तो इसे स्पष्ट रूप से define करना बेहतर है, इस बात से मैं सहमत हूँ
      ऊपर से पूरा लेख कुछ हद तक AI-generated भी लगता है
    • व्यापक पाठकों के लिए लिखते समय acronyms को पहले expand करना बुनियादी बात है, लेकिन LLMs अक्सर ऐसी guidelines ठीक से नहीं मानते

  • यह थोड़ा मज़ेदार है
    पेज पर लिखा है कि यह RHEL 14.3 पर काम करता है, जबकि ऐसा कोई version मौजूद ही नहीं है
    अभी RHEL 10.x पर है, इसलिए मुझे लगा मानो किसी ने TARDIS पकड़ ली हो

    • 14.3 शायद RHEL version नहीं बल्कि Red Hat की GCC versioning से आया है
      कभी-कभी यह gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2) की तरह दिखता है, और नीचे दिए उदाहरणों में भी ऐसा ही कुछ नज़र आता है
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • उसी line में 6.12.0-124.45.1.el10_1 भी लिखा है, जो साफ़ तौर पर RHEL 10 kernel है
      इस तरह की typo इंसान अक्सर करते हैं
      लंबे copy-paste किए हुए नंबर सही रहते हैं, लेकिन आसान नंबर हाथ से टाइप करते हुए ग़लत हो जाते हैं
    • माफ़ कीजिए, लेकिन इसे ठीक किया जाएगा
      issue समझाने के लिए जानकारी जल्दी-जल्दी इकट्ठी की गई थी, और हाँ, इसमें marketing का पहलू भी था
      इसलिए कुछ छोटी गलतियाँ आ गईं, और उन्हें पकड़ने के लिए धन्यवाद
    • हाँ, "directly validated distributions: RHEL 14.3" पढ़ते ही release page कम से कम कुछ हद तक AI slop जैसी लगी
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      और जब पेज के नीचे "Talk to our security experts" भी दिखा, तो मन में आया कि कहीं उस security expert का नाम Claude तो नहीं

  • RHEL 9/10 में algif_aead module नहीं बल्कि built-in था, इसलिए उसे unload नहीं किया जा सकता था
    इसलिए मैंने दूसरे विकल्प के रूप में systemd के ज़रिए AF_ALG को block करने का तरीका खोजा, और हर exposed service के लिए drop-in चाहिए
    आम तौर पर अहम sshd और user@ को संभालने वाला एक Ansible playbook भी है
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • RHEL 9/10 में initcall_blacklist=algif_aead_init को kernel boot option में जोड़कर reboot करने का तरीका भी काम करता था
      ऐसा करने के बाद exploit अब नहीं चला
    • मेरे मन में भी ऐसा ही तरीका आया था, लेकिन हर service पर block लगाना whack-a-mole जैसा लगता है
      cronjob, slurmjob जैसे दूसरे execution paths का क्या होगा, यह चिंता रहती है, और काश individual services के बजाय systemd स्तर पर ऐसा कोई तरीका हो जिससे सभी processes इसे inherit करें

  • यह exploit शायद SUID binary को बदलकर उसे PID 0 के रूप में चलाने वाली तकनीक का इस्तेमाल करता है
    लेकिन साइट यह भी दावा करती है कि इससे Kubernetes / container clusters, CI runners & build farms से escape किया जा सकता है, जबकि वास्तव में containers या खासकर user namespace escape के समर्थन में कोई ठोस विवरण नहीं दिखता
    rootless Podman में चलाकर देखा तो उम्मीद के मुताबिक container से बाहर नहीं निकला
    साथ ही "2017 के बाद जारी हुई सभी Linux distributions पर root बन जाता है" जैसा दावा भी किया गया, जबकि असली tests सिर्फ चार पर हुए थे, और Alpine पर तो यह चला ही नहीं

    • साइट की तरफ़ से कहा गया है कि विस्तृत विवरण जल्द आएगा, इसलिए शायद part 2 में अतिरिक्त steps या corrections होंगे
      "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform." ऐसा teaser भी दिया गया है
    • यह vulnerability readable files के memory bytes overwrite कर सकती है, इसलिए कई environments से escape की संभावना की कल्पना की जा सकती है
    • 2017 के बाद की सभी distributions वाला दावा शायद इस तथ्य पर आधारित है कि यह vulnerability 2017 के दूसरे हिस्से के commit से आई थी
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      हालांकि वास्तविक exploitability इस बात पर निर्भर करेगी कि target नवीनतम major release है या किसी पुराने branch का maintained kernel
    • इस लेख ने अपनी विश्वसनीयता खुद काफ़ी घटा दी
      फिर भी जब मैंने PoC को 24.04 instance पर सीधे चलाकर देखा, तो vulnerability खुद असली लगी और काफ़ी बड़ा मुद्दा भी
      लेकिन प्रभावित distributions की संख्या दावे से काफ़ी कम लगती है, और 2017 के बाद की सभी distributions जैसी बात अतिशयोक्ति लगती है
      उदाहरण के लिए, अगर मेरी समझ सही है, तो Ubuntu 16.04 EOL भी थोड़ा प्रभावित है, लेकिन मुख्य असर हाल में deploy होने लगे vendor kernels जैसे linux-gcp, linux-oracle-6.7 जैसी 6.17 series पर ज़्यादा दिखता है
    • अगर rootless container के अंदर भी वास्तविक UID 0 तक पहुँचा जा सके, तो उसके बाद escape संभव हो सकता है
      बस उसके लिए अतिरिक्त steps चाहिए होंगे, और Alpine में भी मूल vulnerability मौजूद हो सकती है, बस script adjustments की ज़रूरत हो
      आखिरकार यह कोई polished universal exploit नहीं, बल्कि एक PoC है

  • पेज खुद थोड़ा vibecoded और promotional लगता है, लेकिन vulnerability असली है और risk भी ऊँचा लगता है
    आज बड़ा security update क्यों आया, यह अब समझ में आता है, इसलिए updates की priority बढ़ानी चाहिए

    • यह काफ़ी खुला हुआ advertising है, लेकिन व्यक्तिगत रूप से मुझे बुरा advertising नहीं लगता
      वे असली bugs ढूँढकर और patches दिलवाकर OSS ecosystem में meaningful contribution भी कर रहे हैं, और साथ में अपने security tools भी बेच रहे हैं
    • इन्हें शायद advertising के बिना भी पहले से बहुत काम मिल जाता होगा
      लेकिन आजकल web pages हाथ से कौन बनाता है, और खासकर अगर सामने वाले kernel developers हों, तो यह और भी स्वाभाविक लगता है