Dirty Frag: सार्वभौमिक Linux LPE (लोकल प्रिविलेज एस्केलेशन) भेद्यता

 (openwall.com)
2 पॉइंट द्वारा GN⁺ 3 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Dirty Frag एक सार्वभौमिक लोकल प्रिविलेज एस्केलेशन भेद्यता है जो प्रमुख Linux डिस्ट्रीब्यूशनों में root अधिकार हासिल करना संभव बनाती है, और responsible disclosure schedule तथा embargo टूट जाने के कारण अभी तक कोई patch या CVE नहीं है
  • यह Dirty Pipe और Copy Fail जैसे bug class का विस्तार है, और deterministic logic bug होने के कारण race condition की आवश्यकता नहीं होती तथा सफलता दर बहुत अधिक है
  • भेद्यता की प्रभावी अवधि लगभग 9 वर्ष है, और Ubuntu, RHEL, Fedora, openSUSE जैसे प्रमुख डिस्ट्रीब्यूशनों पर परीक्षण पूरा हो चुका है
  • मौजूदा Copy Fail mitigation (algif_aead blacklist) लागू होने पर भी सिस्टम अब भी Dirty Frag के प्रति vulnerable हैं
  • अस्थायी mitigation के रूप में, डिस्ट्रीब्यूशन patch आने तक भेद्यता उत्पन्न करने वाले esp4, esp6, rxrpc मॉड्यूल हटाने की सिफारिश की गई है

अवलोकन

  • sk_buff संरचना के frag member को दूषित करने वाली bug class, जो Dirty Pipe और Copy Fail वाली उसी bug class का विस्तार है
  • xfrm-ESP Page-Cache Write भेद्यता और RxRPC Page-Cache Write भेद्यता को chain करके प्रमुख Linux डिस्ट्रीब्यूशनों में root अधिकार प्राप्त किए जा सकते हैं
  • यह deterministic logic bug है, इसलिए timing window पर निर्भर नहीं करती, और race condition की आवश्यकता नहीं होती
  • exploit विफल होने पर भी kernel panic नहीं होता, और सफलता दर बहुत अधिक है

दो भेद्यताओं को chain करने का कारण

  • xfrm-ESP Page-Cache Write, Copy Fail की तरह एक शक्तिशाली arbitrary 4-byte STORE primitive प्रदान करती है और अधिकांश डिस्ट्रीब्यूशनों में शामिल है, लेकिन इसके लिए namespace creation permission चाहिए
  • Ubuntu में AppArmor policy के कारण non-privileged user namespace creation अवरुद्ध हो सकता है, इसलिए इस वातावरण में xfrm-ESP Page-Cache Write को trigger नहीं किया जा सकता
  • RxRPC Page-Cache Write के लिए namespace creation permission की आवश्यकता नहीं होती, लेकिन rxrpc.ko मॉड्यूल स्वयं अधिकांश डिस्ट्रीब्यूशनों में शामिल नहीं है
    • हालांकि Ubuntu में rxrpc.ko मॉड्यूल डिफ़ॉल्ट रूप से लोड होता है
  • दोनों भेद्यताओं को chain करने से उनकी कमज़ोरियाँ एक-दूसरे की पूर्ति करती हैं, जिससे सभी प्रमुख डिस्ट्रीब्यूशनों में root अधिकार प्राप्त करना संभव हो जाता है

Copy Fail के साथ संबंध

  • Copy Fail ही इस शोध को शुरू करने की प्रेरणा था
  • xfrm-ESP Page-Cache Write, Copy Fail के साथ उसी sink को साझा करती है, लेकिन algif_aead मॉड्यूल की उपलब्धता से स्वतंत्र रूप से trigger की जा सकती है
  • सार्वजनिक Copy Fail mitigation (algif_aead blacklist) लागू होने वाले सिस्टम भी Dirty Frag के प्रति अब भी vulnerable हैं

प्रभाव का दायरा

  • xfrm-ESP Page-Cache Write: commit cac2661c53f3 (2017-01-17) से upstream तक
  • RxRPC Page-Cache Write: commit 2dc334f1a63a (2023-06) से upstream तक
  • भेद्यता की प्रभावी अवधि लगभग 9 वर्ष है
  • परीक्षण किए गए डिस्ट्रीब्यूशन संस्करण:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

शमन उपाय

  • responsible disclosure schedule और embargo टूट जाने के कारण किसी भी डिस्ट्रीब्यूशन में patch मौजूद नहीं है
  • अस्थायी mitigation के रूप में, भेद्यता उत्पन्न करने वाले मॉड्यूल हटाने के लिए निम्न कमांड दिया गया है: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • esp4, esp6, rxrpc मॉड्यूल को /etc/modprobe.d/dirtyfrag.conf में blacklist के रूप में दर्ज करके unload किया जाता है
  • प्रत्येक डिस्ट्रीब्यूशन द्वारा patch backport करने के बाद संबंधित update लागू करना आवश्यक है

सार्वजनिक होने की पृष्ठभूमि

  • linux-distros@vs.openwall.org maintainers के साथ चर्चा के बाद, उनके अनुरोध पर Dirty Frag दस्तावेज़ सार्वजनिक किया गया
  • embargo बाहरी कारणों से टूट चुका है, और फिलहाल कोई patch या CVE मौजूद नहीं है
  • PoC, linux-distros के साथ समन्वय के बाद सटीक जानकारी प्रदान करने के उद्देश्य से सार्वजनिक किया गया, और बिना अनुमति वाले सिस्टम पर इसके उपयोग की मनाही है

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

2 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय

  • यह मूल कारण और exploit करने के तरीके, दोनों के हिसाब से Copy Fail से बहुत मिलता-जुलता है
    मुझे लगता है कि यह उस चीज़ का अच्छा उदाहरण है जिसे LLM को बहुत ज़्यादा काम सौंपने पर खो देना आसान होता है, यानी exploration। AI के साथ vulnerability research करने पर रचनात्मकता काफ़ी रुकती हुई लगती है। जब सवाल पूछो और तुरंत जवाब मिल जाए, तो आसपास और क्या है यह देखना छूट जाता है। जिन्न की तरह, जो ठीक वही देता है जो माँगा गया हो, उससे ज़्यादा नहीं
    Copy Fail खोजने वाले researcher ने कुछ संदिग्ध देखने के बाद AI पर काफ़ी निर्भर किया, लेकिन अगर उसने खुद बहुत सारा code खंगाला होता तो शायद ऐसे twin bug ढूँढने के और मौके मिलते। साथ ही, अगर prompt थोड़ा कम निर्देशात्मक दिया होता, तो लगता है कि आज के LLM भी ये bugs ढूँढ लेते। साथ मिलकर काम किया, लेकिन performance गिर गई — यह काफ़ी अनोखा negative synergy का मामला है

    • अगर मैंने गलत नहीं पढ़ा, तो यह सिर्फ मिलता-जुलता नहीं बल्कि एक ही मूल कारण है। IPsec के Extended ESN के ऊपरी 32 बिट == authencesn module/cipher mode की समस्या
      copy.fail में गलत चीज़ ठीक की गई थी, और लोगों ने जल्दी से दोष AF_ALG पर डाल दिया
      [संपादन: हाँ, यह वही authencesn समस्या है। https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... code में authencesn सिर्फ comment में आता है, लेकिन फिर भी यह वही समस्या है]
      [संपादन2: RxRPC की समस्या अलग है, यहाँ ESP वाले हिस्से की बात हो रही है]
    • follow-up prompt में यह भी कहा जा सकता है, “ऐसे ही तरह के bugs ढूँढो।” एक बार वास्तविक case अच्छी तरह दर्ज हो जाए, तो मिलते-जुलते bugs ढूँढना इतना मुश्किल नहीं रहता
      रचनात्मकता वाली बात समझ में आती है। किसी भी tool की तरह AI नज़र को सीमित कर सकता है। पूरे workflow को उसके हवाले किए बिना सिर्फ सहायक की तरह इस्तेमाल करना आसान नहीं है
    • समझ नहीं आया। शुरू में ये bugs खोजे ही LLM ने थे। लेकिन अब उसी खोज को vulnerability discovery में LLM के ख़राब होने का संकेत बताया जा रहा है
    • यह बात किसी आधार पर कही जा रही है, या बस मौके पर ही गढ़ ली गई है, यह जानने की जिज्ञासा है
    • AI ने जो खोजा उससे मिलता-जुलता, लेकिन पूरी तरह वही नहीं, ऐसे मूल vulnerability को AI explore नहीं कर पाया — इस तरह का सबक निकालना बहुत कठिन है
      अगर ये दोनों vulnerabilities एक साथ disclose न होतीं, तो किस counterfactual स्थिति में कहा जाता कि “इसने काफ़ी अच्छी exploration की” — यह जानना चाहूँगा

  • “embargo टूट गया है, इसलिए इन vulnerabilities के लिए कोई patch या CVE नहीं है”
    लिंक: https://github.com/V4bel/dirtyfrag
    विस्तृत विश्लेषण: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    अहम हिस्सा यह है: “Copy Fail इस research को शुरू करने की प्रेरणा था। खास तौर पर, Dirty Frag vulnerability chain में xfrm-ESP Page-Cache Write, Copy Fail के साथ वही sink साझा करता है। लेकिन यह algif_aead module उपलब्ध होने या न होने से स्वतंत्र रूप से trigger होता है। दूसरे शब्दों में, public Copy Fail mitigation यानी algif_aead blacklist लागू होने पर भी Linux अभी Dirty Frag के प्रति vulnerable रहता है”
    mitigation यह बताई गई है, हालांकि मैंने खुद test या verify नहीं किया: “responsible disclosure schedule और embargo टूट जाने की वजह से किसी distribution के पास patch नहीं है। नीचे दिए गए command से vulnerability पैदा करने वाले modules हटा दें”
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    mitigation पर हुई चर्चा में कहा गया कि reboot ज़रूरी हो सकता है, या अगर machine पहले ही exploit हो चुकी है तो ऊपर वाला command चलाने के बाद यह भी चलाना चाहिए: sudo echo 3 > /prox/sys/vm/drop_caches

    • sudo echo 3 > /prox/sys/vm/drop_caches में sudo का कोई असर नहीं है। sudo सिर्फ echo को चलाता है, असली write को नहीं
      और अगर machine पहले ही exploit हो चुकी है, तो तब तक बहुत देर हो चुकी है। disk में कुछ भी corrupt हो सकता है, इसलिए पूरी disk image दोबारा बनानी चाहिए
    • non-sudo shell में sudo echo और redirection को इस तरह इस्तेमाल नहीं किया जा सकता
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      या
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      और /proc वाला typo भी ठीक किया गया है
    • जानकारी के लिए, echo 1 > ... से भी mitigation हो जाती है। सब कुछ flush करने की ज़रूरत नहीं, 1 से सिर्फ page cache हटाना काफ़ी है
      Ubuntu 26.04 पर local test किया: exploit चलाकर root लिया, mitigation सेट की, और फिर बिना argument के su दोबारा चलाया तो तुरंत बिना password root मिल गया। उसके बाद page cache साफ़ की, तो su ने password माँगा

  • कोई आसान तरीका होना चाहिए जिससे यह सुनिश्चित हो कि सिर्फ whitelist किए गए kernel modules ही load हों। जिन modules की ज़रूरत भी नहीं, उन्हें बार-बार blacklist करते-करते थक गया हूँ

  • फिर से पूछता हूँ, copy.fail में algif_aead को ही सारा दोष क्यों दिया जा रहा है? बेवकूफ़ चीज़ तो authencesn है
    authencesn को ठीक नहीं किया गया, और अब उसका नतीजा सामने है। पता चला है कि एक सामान्य network socket के ज़रिए उसी, या शायद उसी तरह के, out-of-bounds write तक पहुँचा जा सकता है
    काश यह बात पहले सूझी होती, लेकिन नहीं हुई
    [संपादन: यहाँ ESP के ज़रिए वाली समस्या की बात हो रही है। मेरी समझ में RxRPC की समस्या बिल्कुल अलग है]

  • अगर यह सच में सभी बड़े distributions पर काम करता है, तो maintainers कितने गैर-जिम्मेदार हैं यह देखकर मैं फिर हैरान हूँ। ऐसे optional kernel features, जो शायद 0.1% से भी कम users के काम आते हों, default में enabled क्यों हैं?
    यह 1999 के Linux distributions की उस आदत जैसा लगता है, जहाँ default install में internet-exposed network services के दर्जनों पैकेज आ जाते थे। लेकिन अब 1999 नहीं है

    • किसी distribution maintainer से यह उम्मीद करना कि वह “तुम्हें इसकी ज़रूरत नहीं होगी” (YAGNI) कहकर किसी feature को blacklist कर दे, काफ़ी बड़ी माँग है। किसी को नहीं पता कि कौन क्या इस्तेमाल करेगा। user हमेशा बाद में जाकर अपनी असली ज़रूरत के हिसाब से build समायोजित कर सकता है
      Linux के शुरुआती दिनों में make menuconfig चलाकर kernel में सिर्फ वही features चुनने का समय याद है। सच कहूँ तो उस दौर में लौटना नहीं चाहता
      लेकिन यहाँ एक ऐसी चीज़ है जिसे आसानी से बेहतर किया जा सकता है, और वह है RHEL। RHEL बहुत से modules को loadable modules की तरह रखने के बजाय सीधे kernel में compile कर देता है, इसलिए copy fail जैसी mitigations संभव नहीं थीं। शायद वहाँ ऐसी चीज़ें कुछ कम की जा सकती हैं
    • user जिन components का इस्तेमाल शायद कभी न करे उन्हें disable करते हुए भी system का उपयोग बहुत कठिन न बने, ऐसा कोई आसान तरीका नहीं है। इस बेवकूफ़ OS को 25 साल इस्तेमाल करने के बाद भी मुझे नहीं पता चलता कि कुछ करने के लिए क्या चालू/बंद करना चाहिए
      Linux distribution maintainers दुनिया के सबसे ज़िम्मेदार software maintainers हैं। उनकी security practices बेवकूफ़ programming language package managers से कहीं बेहतर हैं; वे चुनी हुई package lists बनाए रखते हैं, बदलावों की समीक्षा करते हैं, bugs patch करते हैं, जटिल packaging समस्याएँ सुलझाते हैं, fixes backport करते हैं, staged release इस्तेमाल करते हैं, दुनिया भर के mirrors पर files वितरित करते हैं, और हर file को cryptographically verify करते हैं। और यह भी मत भूलिए कि वे यह सब मुफ़्त में करते हैं
    • यह default में enabled नहीं है। ये optional modules हैं जो ज़रूरत पड़ने पर load होते हैं। kernel की पूरी architecture ही ऐसी है कि user को चाहिए वह core functionality compile-in हो, और बाकी लगभग सब कुछ modules के रूप में ज़रूरत के समय load हो
    • कई मायनों में mobile नहीं होने वाले computers अब भी 1999 में अटके हुए हैं। Android कहीं नया है और उसे पूरे stack में mandatory access control integrate करने का मौका मिला, इसलिए वह बाकी Linux systems से काफ़ी ज़्यादा सुरक्षित है
    • इसका exploit करने के लिए computer तक सीधा access होना चाहिए। या तो malicious USB device हो, या supply-chain attack, या ऐसा software जिसका install user खुद करे या जो अपने-आप install हो जाए, और उसी का दुरुपयोग किया जाए। इससे भी आगे, व्यवहार में लगभग मनमाने terminal commands चलाने की क्षमता चाहिए, जो अपने-आप में उस software sandbox के लिए पहले से बहुत बड़ा compromise है
      अगर attacker यह सब कर चुका है, तो हालात पहले ही बुरे हैं। उस बिंदु पर इससे root तक privilege escalate कर लेना चिंताओं में छोटी बात है
      जैसे नीचे किसी और ने पोस्ट किया है: https://xkcd.com/1200/
      लोगों के घबराने से पहले यह समझना ज़रूरी है कि यह vulnerability वास्तव में क्या है

  • इतने सालों बाद आखिरकार हम “अगर नज़रें काफ़ी हों तो हर bug सतही होता है” वाली स्थिति तक पहुँच गए हैं, और यह कुछ ख़ास अच्छा नहीं लग रहा। क्या अब हमें हफ़्ते में कई बार kernel update करना पड़ेगा?

    • क्या यह मान लिया जाए कि कोई घर में घुसकर किसी तरह default credentials ढूँढ लेगा और root access भी हासिल कर लेगा?

  • जिज्ञासा है कि embargo टूटा कैसे। क्या leak हुआ, या किसी तीसरे पक्ष ने इसे स्वतंत्र रूप से खोज लिया?

    • असल में embargo जैसा कुछ होता ही नहीं, और हो भी नहीं सकता
      Linux open source है, इसलिए security bugs को ठीक करने वाले सारे patches तुरंत सबको दिखते हैं। kernel development का तरीका ऐसा है कि इसे दरकिनार करने का कोई उपाय नहीं। लोग जिस “embargo” की बात करते हैं, वह यह काफ़ी बेवकूफ़ाना धारणा है कि अगर patch description में खुलकर “THIS IS A LPE” न लिखा जाए और सब चुप रहें, तो mailing list में “official” संदेश जाने तक vulnerability leak नहीं हुई मानी जाएगी
      पहले शायद इस approach का कुछ बचाव किया जा सकता था, लेकिन LLM के दौर में mailing list के diffs को automated pipeline से नए models में डालकर यह पहचानना कि कौन सा patch security issue ठीक कर रहा है, संभव है; इसलिए यह सिर्फ बेवकूफ़ी ही नहीं बल्कि ख़तरनाक भी है
    • patch का लिंक किसी के X account पर पोस्ट हुआ, और किसी दूसरे व्यक्ति ने उसे देखकर एक घंटे से भी कम समय में काम करने वाला exploit डाल दिया। हो सकता है LLM का इस्तेमाल हुआ हो, लेकिन तेज़ turnaround के अलावा इसके पक्ष में कोई साबित दावा नहीं है
      https://x.com/encrypted_past/status/2052409822998392962
    • किसी असंबंधित तीसरे पक्ष ने इसे सार्वजनिक रूप से पोस्ट कर दिया था

  • क्या किसी को पता है कि Debian vulnerable है या नहीं? मैंने Debian 12 और Debian 13 machines पर exploit आज़माया, लेकिन खुद reproduce नहीं कर पाया

    • Debian 13, यानी Trixie, के 6.12.57+deb13-amd64 kernel पर यह reproduce हुआ, लेकिन Debian 12 Bookworm के 6.1.0-42-amd64 kernel पर नहीं हुआ
      जो लोग Bookworm पर Debian package security stream इस्तेमाल नहीं कर रहे, उनके लिए 6.1.0-42-amd64 kernel वास्तव में copy.fail के प्रति immune है। dirtyfrag के प्रति भी immune दिखना चौंकाने वाला है। अगर security stream में अभी patch नहीं आया है, तो आप commit 2b8bbc64b5c2 वाला kernel version चुन सकते हैं। मुझे लगता है कि यही commit संयोग से कुछ Debian 12 kernel versions को dirtyfrag से भी सुरक्षित बना रहा होगा
    • DigitalOcean के नए Debian 13 droplet पर अभी exploit आज़माया और यह काम कर गया
    • पूरी तरह updated Debian 13 पर test किया, exploit काम करता है। mitigation भी काम करती है, यह confirm किया

  • ubuntu:latest container में नए default user के रूप में चलाया
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    नतीजा: dirtyfrag: failed (rc=3)
    यह अच्छी खबर है!

    • container के अंदर चलाने पर मुझे भी यही नतीजा मिला, लेकिन host पर सीधे चलाया तो shell मिल गई। इससे सिर्फ इतना पता चलता है कि exploit container के अंदर काम नहीं करता। इसलिए या तो container vulnerable नहीं है, या script को container में चलाने के लिए समायोजन चाहिए
      copy fail का इस्तेमाल container escape के लिए किया जा सकता है (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), इसलिए मेरा अनुमान है कि exploit में बस थोड़ा-सा बदलाव चाहिए
    • container को इस तरह के test के लिए भरोसेमंद platform मानना मुश्किल है। सही वजह से हो या नहीं, containers में बहुत-सी चीज़ें fail हो जाती हैं
 
GN⁺ 3 시간 전
Lobste.rs की राय

  • साझा Linux सर्वर मैनेज करने के लिए यह वाकई कमाल का हफ्ता रहा। फिर भी अच्छा लगा कि इस बार खुलासे में सीधे मुद्दे की बात की गई
    लेकिन समझ नहीं आता कि mitigation निर्देशों में सब लोग stderr क्यों छिपा रहे हैं
    संपादन: यह copy.fail से “प्रेरित” होकर 30 अप्रैल को रिपोर्ट किया गया था, तो क्या इसे एक दिन के भीतर ही ढूंढ लिया गया? प्रभावशाली है
    काफी बड़े shared server पर sudo अधिकार रखने वाले के तौर पर, मैं यह भी सोच रहा हूं कि क्या जितने कम हो सके उतने modules के साथ kernel को खुद compile करना अच्छा विचार हो सकता है। मैंने इसके फायदे-नुकसान पर गहराई से विचार नहीं किया, लेकिन ऐसा लगता है कि इससे इस हफ्ते की दोनों local privilege escalation vulnerabilities से बचा जा सकता था
    संपादन2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    ओह, इसमें setuid की जरूरत नहीं है। इसे शामिल करना अच्छा लगा

    • मैं जिन multi-user systems को maintain करता हूं, उनमें मैं ऐसा कर रहा हूं, और इस हफ्ते के दोनों local root exploits से वास्तव में बच सका

  • क्या running system पर loaded kernel modules की सूची लेकर उसे उस system की modprobe allowlist के रूप में सेट करना संभव और उचित होगा?
    CopyFail और DirtyFrag दोनों ऐसे kernel modules का दुरुपयोग करते दिखे जो मेरे जांचे गए किसी भी system पर load नहीं थे। अगर ऐसा है, तो क्या जो modules स्पष्ट रूप से जरूरी नहीं लगते उन्हें block करके कुछ हमलों को पहले ही कम नहीं किया जा सकता?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    समझ नहीं आता कि ऐसी चीज़ कैसे होने दी जाती है। इतना बड़े पैमाने की जानकारी का ऐसे कम भरोसेमंद माहौल में मौजूद होना सचमुच बेतुका लगता है

    • यहां “असंबंधित third party ने प्रकाशित किया” से यही मामला है या नहीं, यह पक्का नहीं है, लेकिन संदर्भ के लिए, Brad Spengler ने fix commit पहले चढ़ा हुआ देखकर commit message से झलकती security vulnerability को पहचान लिया, और replies में किसी ने vibe coding से exploit बना लिया
      Linux commits पर नजर रखने वाला कोई भी third party वही सुराग पकड़कर exploit बना सकता था
    • “असंबंधित third party” वाली अभिव्यक्ति से लगता है कि उसे यह पता ही नहीं था कि bug embargo में है
      यहां “कम भरोसेमंद माहौल” पूरा internet है, और व्यवहार में सचमुच isolation जैसा कुछ बहुत कम है। पहले भी ऐसा ही था, बस अब यह और स्पष्ट हो गया है। Apache httpd bug को fix होने से पहले दो बार फिर से खोजे जाने पर Stefan Eissing की हाल की पोस्ट भी देखने लायक है

  • क्या यह जांचने का कोई तरीका है कि प्रभावित modules वास्तव में load नहीं किए जा सकते?
    CopyFail के समय पहली mitigation लगाते वक्त मुझसे गलती हो गई थी। /etc/modprobe.d/ के भीतर file name .conf पर खत्म नहीं हो रहा था, और https://news.ycombinator.com/item?id=47954159 में दिए गए test command को चलाने तक मुझे इसका पता नहीं चला। क्या esp4/esp6/rxrpc modules के लिए भी ऐसा कोई मिलता-जुलता command है?

    • मैंने तीनों modules को modprobe से load करके देखा, और पिछली बार जैसी ही error आई
      संलग्न proof-of-concept code भी है, लेकिन अभी तक उसे आज़माया नहीं है