Kernel Codex Harness

한국어 | English

अनुसंधान उपकरण · मूल आयात: 3 अप्रैल 2026 · दस्तावेज़ संशोधन: 11 जुलाई 2026

मूल दर्शन — बाह्य संकेत
मॉडल अनुमान के बाहर पुनरुत्पादनीय अवलोकनों को ध्यान का मार्गदर्शन करने दें; प्राथमिकता को कभी प्रमाण न समझें।

परियोजना स्थिति. यह रिपॉजिटरी एक LLM-सहायता प्राप्त अनुसंधान हार्नेस का प्रारंभिक संस्करण है, जिसे वास्तविक Linux कर्नेल भेद्यता अनुसंधान के लिए बनाया और उपयोग किया गया था। इस संस्करण का उपयोग CVE-2026-31720 के रूप में प्रकाशित भेद्यता की खोज के लिए किया गया था। हार्नेस अनुसंधान लक्ष्यों को प्राथमिकता देता है, लेकिन भेद्यताओं को स्वचालित रूप से सिद्ध नहीं करता या कर्नेल की सुरक्षा की गारंटी नहीं देता; अंतिम सत्यापन और रिपोर्टिंग मनुष्यों द्वारा की जाती है।

सार

सार— Linux कर्नेल जैसे बड़े कोडबेस को LLM में सीधे खोजने देने से संदर्भ तेजी से बिखर जाता है, और खतरनाक API की उपस्थिति को वास्तविक शोषण क्षमता के साथ आसानी से भ्रमित किया जाता है। Kernel Codex Harness इस समस्या को स्वचालित भेद्यता पहचान के बजाय अनुसंधान प्राथमिकता निर्धारण और स्थिति-आधारित ऑर्केस्ट्रेशन की समस्या के रूप में परिभाषित करता है। यह परियोजना उस सिद्धांत को External Signal कहती है, जिसमें LLM तर्क के बाहर गणना किए गए पुनरुत्पादनीय अवलोकनों द्वारा मॉडल के ध्यान को नियंत्रित किया जाता है। कर्नेल पथ, userspace सीमा, lifetime·usercopy·refcount·size से संबंधित स्थिर संकेतों और वैकल्पिक syzbot crash बुद्धिमत्ता को मिलाकर उम्मीदवार फ़ाइलों को रैंक किया जाता है, और प्रत्येक उम्मीदवार को संकीर्ण प्रॉम्प्ट बंडल में परिवर्तित किया जाता है। मैन्युअल समीक्षा और समय-बजट-आधारित ऑटोपायलट समान प्रतिक्रिया अनुबंध और सत्र स्थिति का उपयोग करते हैं। इस हार्नेस का उपयोग वास्तविक Linux कर्नेल अनुसंधान में USB gadget audio पथ में stack out-of-bounds write की खोज के लिए किया गया था, और यह दोष CVE-2026-31720 के रूप में प्रकाशित हुआ। यह कार्यान्वयन एक सटीक स्थिर विश्लेषक नहीं है, बल्कि एक शोध कार्यप्रवाह है जो व्याख्या योग्य अनुमानों द्वारा LLM अनुसंधान के दायरे को सीमित करता है; सभी निष्कर्षों के लिए reachability, invariant break और concrete impact पर मानव पुनः-सत्यापन की आवश्यकता होती है।

सूचकांक शर्तें— Linux कर्नेल, भेद्यता अनुसंधान, बाह्य संकेत, LLM ऑर्केस्ट्रेशन, अनुमानी प्राथमिकता, syzbot, प्रोग्राम विश्लेषण, Codex।

I. परिचय

Linux कर्नेल सुरक्षा समीक्षा में दो प्रकार की पैमाने की समस्याएँ हैं। पहली, पूरा स्रोत ट्री एक ही LLM संदर्भ में संभालने के लिए बहुत बड़ा है। दूसरी, copy_from_user, allocator, refcount, lock जैसे संकेत सामान्य हैं, लेकिन स्वयं भेद्यता का संकेत नहीं देते। विश्लेषक को पहले "कहाँ देखना है" तय करना होता है, फिर userspace reachability और विशिष्ट स्थिति संक्रमण को अलग से सिद्ध करना होता है।

इस परियोजना का मूल दर्शन External Signal है।

LLM को स्वयं यह तय नहीं करने दिया जाता कि कहाँ देखना है। मॉडल तर्क के बाहर के पुनरुत्पादनीय संकेत ध्यान का आवंटन करते हैं, लेकिन भेद्यता निष्कर्ष केवल reachability और invariant साक्ष्य से तय होते हैं।

इसलिए हार्नेस मॉडल को पूरे कर्नेल में अस्पष्ट रूप से खोजने नहीं देता। यह फ़ाइलों को प्राथमिकता देता है, एक समय में केवल एक अनुसंधान शाखा प्रदान करता है, और निष्कर्ष से पहले साक्ष्य संरचना की मांग करता है।

II. External Signal और डिज़ाइन सिद्धांत

A. मॉडल अनुमान से पहले External Signal

External Signal LLM द्वारा उत्पन्न निर्णय नहीं है, बल्कि एक अवलोकन है जो मॉडल निष्पादन से पहले तय होता है और उसी स्रोत ट्री, प्रोफ़ाइल और संग्रहीत syzbot JSON से पुनः गणना की जा सकती है। पथ भार, regex हिट, कैश्ड syzbot overlap इसी श्रेणी में आते हैं। ये संकेत केवल उम्मीदवार रैंकिंग और प्रॉम्प्ट संदर्भ के लिए उपयोग होते हैं, verdict या प्रमाण के रूप में नहीं।

इस दस्तावेज़ में External Signal पूरे परियोजना दर्शन को संदर्भित करता है। कोड में ExternalSignal डेटा मॉडल वर्तमान में केवल syzbot से उत्पन्न संकेतों का प्रतिनिधित्व करता है, इसलिए दोनों शब्दों का दायरा भिन्न है।

B. प्राथमिकता प्रमाण नहीं है

Regex हिट, उच्च-जोखिम पथ, syzbot overlap — ये सभी अनुसंधान क्रम के लिए संकेत हैं। उच्च स्कोर होने पर भी, यदि वास्तविक कॉल पथ, अनुमतियाँ, कर्नेल config, namespace, device उपलब्धता हमलावर की पहुँच की अनुमति नहीं देते, तो यह सुरक्षा निष्कर्ष नहीं है।

C. Bug Class से पहले Reachability

ऑडिट पहले उन सीमाओं की जाँच करता है जो userspace से शुरू होती हैं: syscall, ioctl, netlink, procfs, filesystem, BPF, driver hook। उसके बाद ही UAF, OOB, refcount, race, info leak, capability check जैसे bug class का मूल्यांकन किया जाता है।

D. एक समय में एक अनुसंधान शाखा

एक अनुसंधान इकाई मूल रूप से एक फ़ाइल और उसके निकटवर्ती caller·teardown·free पथ तक सीमित होती है। मॉडल द्वारा अनुशंसित मैन्युअल follow-up अधिकतम दो बार अनुमत है। यह सीमा खोज क्षमता कम करने के लिए नहीं है, बल्कि सत्यापन योग्य दायरे में निष्कर्ष बनाए रखने के लिए है।

E. आत्मविश्वास से अधिक साक्ष्य

प्रॉम्प्ट मांग करता है कि एक मजबूत निष्कर्ष कम से कम निम्नलिखित की व्याख्या करे:

1. attacker-reachable entrypoint,
2. attacker-controlled field या lifetime transition,
3. टूटता हुआ object·length·state invariant,
4. corruption, leak, privilege escalation जैसा विशिष्ट impact,
5. मौजूदा check हमले को क्यों नहीं रोकता।

यदि साक्ष्य अपर्याप्त है, तो मॉडल भेद्यता पर जोर देने के बजाय अगली जाँच के लिए एकल लक्ष्य लौटाता है। यह prompt-level evidence contract है, और वर्तमान parser प्रत्येक साक्ष्य की पूर्णता को स्वचालित रूप से सत्यापित नहीं करता। Ingestion verdict और next target को सामान्यीकृत करता है, इसलिए अंतिम साक्ष्य सत्यापन मानव की जिम्मेदारी है।

F. डिज़ाइन वंशावली

प्रारंभिक अनुसंधान प्रवाह Protect AI के vulnhuntr द्वारा उपयोग किए गए फ़ाइल-स्तरीय विश्लेषण, सीमित संदर्भ विस्तार और संरचित आउटपुट के विचार से शुरू हुआ [1]। इस परियोजना में इसे Python अनुप्रयोग विश्लेषण पर सीधे लागू नहीं किया गया, बल्कि userspace-reachable kernel surface, कर्नेल ऑब्जेक्ट lifetime, teardown पथ और syzbot overlap के केंद्र में पुनः डिज़ाइन किया गया। विशेष रूप से प्राथमिकता संकेतों और भेद्यता प्रमाण को अलग करना, और bug class से पहले reachability की जाँच करना कर्नेल हार्नेस का मुख्य डिज़ाइन विकल्प है।

III. सिस्टम आर्किटेक्चर

चित्र 1. External Signal परत मॉडल अनुमान से पहले गणना किए गए अवलोकनों को रैंक किए गए समीक्षा इकाइयों में बदल देती है। यह ध्यान आवंटित करती है, लेकिन भेद्यता प्रमाण स्थापित नहीं करती।

तालिका I — प्रमुख मॉड्यूल जिम्मेदारियाँ

मॉड्यूल	जिम्मेदारी
targeting.py	कर्नेल फ़ाइल खोज और पथ·पैटर्न·syzbot संकेत स्कोरिंग
models.py	Candidate, Signal और syzbot-व्युत्पन्न ExternalSignal डेटा मॉडल
bundle.py	manifest, session index, prompt/snippet बंडल निर्माण
prompting.py	reachability और invariant-केंद्रित कर्नेल ऑडिट प्रॉम्प्ट
session.py	pending review, history, follow-up depth स्थिति संग्रहण
ingest.py	strict verdict और next target सामान्यीकरण
autopilot.py	समय-बजट-आधारित codex exec, लॉग, archive, finding प्रबंधन
syzbot.py	सार्वजनिक syzbot पृष्ठ संग्रह और स्थानीय JSON कैश निर्माण
cli.py	scan, inspect, codex, loop, autopilot आदि कमांड जोड़ना

IV. पद्धति

A. उम्मीदवार खोज और स्कोरिंग

स्कैनर प्रोफ़ाइल के include directory के अंतर्गत .c और .h फ़ाइलों को पार करता है। फ़ाइल f का प्राथमिकता स्कोर अवधारणात्मक रूप से इस प्रकार बनता है:

Score(f) = Σ path_weight(f)
         + Σ line_signal_weight(f)
         + Σ syzbot_overlap_weight(f)