Claude Code ने 23 साल से छिपी Linux कमजोरी खोजी

• Anthropic के Claude Code ने Linux kernel की remotely exploitable vulnerability को अपने-आप detect किया और 23 साल से अनदेखी NFS driver की heap buffer overflow कमजोरी खोज निकाली
• सिर्फ “security vulnerability कहाँ है?” जैसे prompt के साथ पूरे kernel का analysis करके लगभग बिना supervision के कमजोरी की पहचान की गई
• यह bug 2003 के kernel code में 112-byte fixed buffer design से शुरू हुआ था, और बाद में LOCK operation जुड़ने पर owner ID length limit छूट जाने से पैदा हुआ
• Carlini ने इसके अलावा kernel की सैकड़ों संभावित कमजोरियाँ भी खोजीं, लेकिन human verification bottleneck की वजह से ज़्यादातर अभी तक report नहीं की गईं
• नया Claude Opus 4.6 model पहले के versions की तुलना में कहीं बेहतर detection capability दिखाता है, और इसे AI-based security research के turning point के रूप में देखा जा रहा है

---

Claude Code ने 23 साल से छिपी Linux कमजोरी खोजी

• Anthropic के researcher Nicholas Carlini ने Claude Code का उपयोग करके Linux kernel की remotely exploitable कई कमजोरियाँ खोजीं
  • उनमें से एक NFS (Network File System) driver की buffer overflow कमजोरी थी, जो 23 साल तक पकड़ में नहीं आई थी
  • Carlini ने कहा कि उन्होंने इस तरह की कमजोरी खुद पहले कभी नहीं खोजी थी, और Claude Code की क्षमता देखकर वे हैरान रह गए

• Claude Code कमजोरी कैसे detect करता है

  • Claude Code ने लगभग बिना supervision Linux kernel में security vulnerabilities detect कीं
    • Carlini ने बस “security vulnerability कहाँ है?” जैसा prompt दिया और उसे पूरे kernel source files को iterate करने के लिए set किया
  • इस्तेमाल की गई script को इस तरह बनाया गया था कि हर file पर CTF (hacking competition) scenario मानकर Claude Code सबसे गंभीर vulnerability को /out/report.txt में लिखे
    • find command से सभी files को search किया गया, और हर file पर Claude Code को कमजोरी ढूँढने के लिए बार-बार चलाया गया
  • इसे इस तरह design किया गया था कि एक ही vulnerability बार-बार report न हो, इसलिए kernel की सभी files को अलग-अलग analyze किया गया

• NFS (Network File System) कमजोरी

  • Claude Code द्वारा खोजी गई मुख्य कमजोरी Linux NFS driver में heap buffer overflow थी, जिससे attacker network के ज़रिए kernel memory पढ़ सकता है
  • attack scenario में मिलकर काम करने वाले दो NFS clients (Client A, Client B) एक ही NFS server को target करते हैं
    • Client A 1024-byte लंबे owner ID के साथ file lock request भेजता है और उसे approval मिल जाता है
    • उसके बाद Client B उसी file पर lock request भेजता है, तो server उसे reject करके response message बनाता है
  • समस्या यह है कि इस reject response buffer का size सिर्फ 112 bytes है, जबकि असली message owner ID सहित कुल 1056 bytes का हो जाता है
    • नतीजतन, kernel 1056 bytes को 112-byte buffer में लिख देता है, जिससे attacker-controlled data के साथ kernel memory overwrite हो जाती है
  • Claude Code ने इस कमजोरी को report करते समय ASCII protocol diagram भी अपने-आप बनाकर शामिल किया

• यह 23 साल तक पकड़ में क्यों नहीं आई

  • यह bug मार्च 2003 में Linux kernel में जोड़े गए code से शुरू हुआ था
    • उस समय commit message में कहा गया था कि NFSD4_REPLAY_ISIZE नाम का 112-byte fixed buffer OPEN, CLOSE जैसी NFSv4 operations के लिए पर्याप्त है
    • बाद में LOCK operation जुड़ने पर owner ID length limit को ध्यान में नहीं रखा गया, और वहीं से कमजोरी पैदा हुई
  • यह code Git अपनाने (2005) से पहले का बदलाव है, इसलिए यह इतना पुराना codebase है कि आज उसके लिए सीधा link भी संभव नहीं है

• रिपोर्ट न हो सकीं सैकड़ों अतिरिक्त कमजोरियाँ

  • Carlini ने Linux kernel की सैकड़ों संभावित कमजोरियाँ और भी खोजीं, लेकिन human verification process में bottleneck होने की वजह से उनमें से ज़्यादातर अब तक report नहीं की गईं
    • उन्होंने कहा, “मैं unverified results को kernel maintainers को नहीं भेज सकता, इसलिए अभी भी सैकड़ों crashes हैं जिन्हें मैंने verify नहीं किया है.”
  • अभी तक Carlini ने खुद जिन कमजोरियों को fix या report किया है, उनकी संख्या 5 है
    • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
    • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
    • futex: Require sys_futex_requeue() to have identical flags
    • ksmbd: fix share_conf UAF in tree_conn disconnect
    • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

• AI-based vulnerability detection में प्रगति

  • Carlini ने यह कमजोरी खोजने के लिए Claude Opus 4.6 (release से 2 महीने पहले) का इस्तेमाल किया
    • पुराने versions Opus 4.1 (8 महीने पहले) और Sonnet 4.5 (6 महीने पहले) से वही नतीजा दोहराया नहीं जा सका
    • नए model ने कहीं ज़्यादा vulnerabilities detect कीं
  • उनका अनुमान है कि “आने वाले कुछ महीनों में researchers और attackers दोनों इन AI models की ताकत को पहचानेंगे, और बड़े पैमाने पर security vulnerabilities खोजे जाने की लहर आएगी”

• प्रस्तुति और अन्य जानकारी

  • यह सामग्री [un]prompted AI security conference 2026 में प्रस्तुत की गई
  • Claude Code का यह उदाहरण दिखाता है कि AI वास्तविक security research की productivity को नाटकीय रूप से बढ़ा सकता है

[m3op0w94]

उम्मीद वाला हिस्सा: linux में vulnerability मिली
निराशा वाला हिस्सा: curl में bounding हटाना

[GN⁺]

Hacker News की राय

• हैरानी की बात नहीं। बस लेख में एक बात का ज़िक्र नहीं है कि Claude Code ने 1,000 false positive bugs भी ढूंढ निकाले थे, और डेवलपर्स को उन्हें छाँटने में 3 महीने लगे

  • अब यह ऐसे काम नहीं करता। LLM खुद secondary pipeline में reproduce न होने वाले bugs को फ़िल्टर कर देता है। यह जाँचना कि vulnerability सच में trigger की जा सकती है या नहीं, उसे ढूँढने से कहीं आसान काम है, इसलिए लगभग 100% सटीकता के साथ सिर्फ़ असली bugs बचते हैं। LLM की प्रगति को नकारने वाले लोग अब भी बहुत हैं, लेकिन इसकी usefulness को नकारना मुश्किल है
  • स्रोत जानना चाहूँगा। मैंने ऐसा कुछ नहीं देखा। मेरे अनुभव में Claude Opus 4.6 की vulnerability detection false positive rate 20% से कम थी
  • static/dynamic analysis tools भी हमेशा vulnerabilities ढूँढ लेते हैं। ज़्यादातर बड़े projects के पास scanner द्वारा निकाला गया issues backlog पहले से होता है। असली समस्या उनमें से वास्तव में ख़तरनाक चीज़ों को छाँटना है। Claude ने पुराना bug ढूँढा, यह दिलचस्प है, लेकिन नया scanner आने पर ऐसा हमेशा होता है
  • लेख में यह नहीं लिखा कि false positives बहुत थे। उल्टा उसमें कहा गया है कि “अभी तक verify न किए गए bugs बहुत ज़्यादा हैं”
  • सीख यह नहीं है कि Claude Code बेकार है, बल्कि यह कि सही लोगों के हाथ में यह एक शक्तिशाली tool बन जाता है

• नया code एक साथ paste करके Claude से पूछना, “मैंने क्या मिस कर दिया? bug कहाँ है?” AI में नए डेवलपर्स के लिए बहुत convincing तरीका है। ख़ासकर यह threading या distributed systems bugs जल्दी पकड़ लेता है। लगता है इस समय तक crypto codebases का बड़े पैमाने पर analysis हो रहा होगा

  • मुझे Claude को यह मानने के लिए prompt bias करना पसंद है कि “bug है।” जैसे “इस code में bug है। क्या तुम इसे ढूँढ सकते हो?” या “bug साफ़ नज़र नहीं आता” जोड़ देने पर success rate ज़्यादा रही
  • मैं भी CC/codex को लगभग इसी तरह इस्तेमाल करता हूँ
  • मैं इस तरह पूछता हूँ: “यह code Codex ने लिखा है, इसमें कुछ अजीब दिख रहा है क्या?”

• इसे “छिपा हुआ” bug कहने से ज़्यादा सही होगा कि “किसी ने देखा ही नहीं।” code की संरचना ऐसी थी कि वह 112-byte buffer में 1056 bytes लिख देता था। static analyzer से भी यह आसानी से पकड़ा जा सकता था, लेकिन अगर LLM से कहो “सारे fixed-size buffers जाँचो,” तो hallucinated results भी मिल सकते हैं। फिर भी यह अच्छी शुरुआत है

  • ज़्यादातर vulnerabilities इसलिए बनी रहती हैं क्योंकि “किसी ने देखा ही नहीं।” system complexity बढ़ती जाती है और इंसानों के लिए उसके साथ बने रहना मुश्किल हो जाता है। अगर यह ऐसे मसले हल कर सकता है, तो यह बड़ी ख़बर है। static analyzers हर संभव buffer copy path रिपोर्ट करते हैं, लेकिन कई बार input वास्तव में bounded होता है, इसलिए Linux kernel में वे बहुत सटीक नहीं बैठते
  • सच तो यह है कि “किसी ने देखा ही नहीं” का कारण manpower की कमी थी। open source vulnerabilities ढूँढने के लिए लोगों और समय, दोनों की कमी थी। लेकिन अब models काफ़ी competent हो गए हैं, इसलिए वह सीमा टूट रही है। लगता है यह साल बहुत दिलचस्प होने वाला है
  • कहा जाता है कि static analyzer इसे आसानी से ढूँढ सकता था, लेकिन हक़ीक़त यह है कि 20 साल से ज़्यादा समय तक कोई इसे ढूँढ नहीं पाया। LLM कुछ शानदार कर दे तो हर बार “यह तो कोई बड़ी बात नहीं” वाली प्रतिक्रिया आना मज़ेदार है

• दिलचस्प बात यह है कि मिले 5 bugs में से 3~4 शायद linux-hardened patch से mitigate हो जाते। उदाहरण के लिए io_uring disable करना, UAF पर kernel crash, heap overflow exploitation रोकना आदि

• यह घोषणा काफ़ी हास्यास्पद लगती है: “हम एक ख़तरनाक हथियार सार्वजनिक कर रहे हैं, तो दुनिया को सुरक्षित बनाने में हमारी मदद करो। बस subscription fee दो।” यह वैसा है जैसे कोई biochemist chemical bomb छोड़ दे और कहे, “इसे रोकना है तो पैसे दो।” आजकल software industry सच में विडंबना से भरी है

  • यह बकवास है। vulnerabilities ढूँढकर report करने की तुलना biochemical weapons फैलाने से करना बहुत ज़्यादा है

• मैंने कई production codebases पर प्रयोग दोहराए, और duplicates, false positives, non-exploitable bugs बहुत मिले। फिर भी असली critical vulnerabilities (crit) भी काफ़ी थीं

• प्रेज़ेंटेशन Q&A के दौरान बैकग्राउंड में चलाए गए वीडियो को लेकर जिज्ञासा थी। क्या वह USB networking के ज़रिए NFS bug exploit करने का exploit demo था?

• यह हमारे security lab का संबंधित काम है। हमने इस साल सिर्फ़ AI security agents से 23 vulnerabilities खोजी हैं

  • Security Lab रिपोर्ट
  • Taskflow execution guide

• लगता है three-letter agencies (intelligence agencies) का 0-day stockpile अब तेज़ी से घटेगा

• आगे और vulnerability reports की उम्मीद मत कीजिए, बल्कि और ज़्यादा attack attempts की उम्मीद कीजिए