Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

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

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
linux-kernel-codex-harness — CVE-2026-31720 की जांच में उपयोग किया जाने वाला साक्ष्य-संचालित Linux कर्नेल भेद्यता अनुसंधान हार्नेस | Kitploit
उपकरण/GitHubGitHub/foxirain/linux-kernel-codex-harness
स्थैतिक विश्लेषणभेद्यता विश्लेषणफज़िंगAI सुरक्षा
GitHubfoxirain/linux-kernel-codex-harness

linux-kernel-codex-harness

CVE-2026-31720 की जांच में उपयोग किया जाने वाला साक्ष्य-संचालित Linux कर्नेल भेद्यता अनुसंधान हार्नेस

रिपॉजिटरी देखें

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
261 महीना पहलेअभी तक समीक्षित नहीं
साझा करें

Kernel Codex Harness

한국어 | English

CI

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

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

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

सार

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

External Signal
CVE-2026-31720

सूचकांक शर्तें— 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. सिस्टम आर्किटेक्चर

External Signal architecture for Kernel Codex Harness

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

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

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

IV. पद्धति

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

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

root@kitploit:~
Score(f) = Σ path_weight(f)
         + Σ line_signal_weight(f)
         + Σ syzbot_overlap_weight(f)

यह स्कोर संभावना या शोषण क्षमता का माप नहीं है। प्रत्येक आइटम केवल मॉडल को पहले जाँचने के लिए फ़ाइल चुनने में सापेक्ष क्रम प्रदान करता है। वर्तमान कार्यान्वयन सभी line-level match को जोड़ता है और प्रॉम्प्ट में दिखाने के लिए केवल शीर्ष संकेतों को सीमित करता है। समान परिणाम की पुनर्गणना समान स्रोत ट्री, प्रोफ़ाइल और कैश्ड syzbot JSON पर आधारित है। syzbot भार path·line अनुमानों द्वारा पहले उम्मीदवार बनी फ़ाइलों पर पश्च-लागू होता है; केवल syzbot हिट से नई उम्मीदवार फ़ाइलें नहीं बनतीं।

मुख्य स्थिर संकेत निम्नलिखित हैं:

  • ioctl, compat handler, file operation hook
  • copy_from_user, copy_to_user, __user
  • kmalloc, kzalloc, kvmalloc, cache आवंटन और free पथ
  • refcount, atomic, kref संचालन
  • size·length गणना और memcpy श्रृंखला
  • lock, RCU, async lifetime से संबंधित पैटर्न
  • BPF, skb, XDP, netlink सीमाएँ
  • capability और namespace जाँच

B. प्रोफ़ाइल-संचालित दायरा

अंतर्निहित प्रोफ़ाइलें default, net, fs, io_uring, bpf, drivers हैं। प्रोफ़ाइल include path, पैटर्न, भार और एक फ़ाइल में संरक्षित किए जाने वाले संकेतों की संख्या परिभाषित करती है। पूरे कर्नेल पर एक ही स्कोरिंग नीति लागू करने के बजाय, subsystem-विशिष्ट हमले की सतह और lifetime विशेषताओं को प्रतिबिंबित किया जाता है।

C. Crash बुद्धिमत्ता

syzbot-fetch syzkaller परियोजना के सार्वजनिक syzbot bug पृष्ठ [2] से title, subsystem, bug type, file:line जानकारी निकालकर JSON कैश में संग्रहीत करता है। exact file overlap एक मजबूत External Signal है, subsystem overlap एक कमजोर External Signal है। live dashboard बदल सकता है, इसलिए पुनरुत्पादन इकाई fetch समय की संग्रहीत JSON है। crash जानकारी variant hunting का प्रारंभिक बिंदु है, नई भेद्यता का प्रमाण नहीं मानी जाती।

D. सत्र और समीक्षा अनुबंध

scan रैंक किए गए उम्मीदवार manifest और शीर्ष प्रॉम्प्ट बंडल उत्पन्न करता है। प्रत्येक प्रॉम्प्ट में target path, score reason, line signal, syzbot संदर्भ और ऑडिट प्रक्रिया शामिल होती है।

मॉडल प्रतिक्रिया निम्नलिखित verdict में से एक में सामान्यीकृत होती है:

  • cve_candidate
  • plausible_security_bug
  • latent_bug
  • not_cve_candidate
  • needs_more_context

प्रतिक्रिया में एक Single best next target और संक्षिप्त summary शामिल होता है। pending target के बिना पुरानी प्रतिक्रियाएँ नए लक्ष्य से नहीं जुड़तीं, बल्कि अलग से archive होती हैं।

V. कार्यान्वयन और उपयोग

A. आवश्यकताएँ

  • Python 3.11 या उच्चतर
  • autopilot उपयोग के लिए Codex CLI [3] और प्रमाणीकरण
  • दूरस्थ syzbot dashboard संग्रह के लिए नेटवर्क कनेक्शन

B. स्थापना

root@kitploit:~
git clone https://github.com/foxirain/linux-kernel-codex-harness.git
cd linux-kernel-codex-harness

python3 -m venv .venv
source .venv/bin/activate
python -m pip install .

अंतर्निहित प्रोफ़ाइल JSON wheel में शामिल हैं। बाहरी JSON नियम --config /path/to/profile.json के माध्यम से पारित किए जा सकते हैं।

C. न्यूनतम कार्यप्रवाह

root@kitploit:~
# 1. रैंक किया गया सत्र बनाएँ।
kernel-harness scan /path/to/linux \
  --profile net \
  --limit 80 \
  --top 20 \
  --out artifacts

# 2. उच्च-प्राथमिकता उम्मीदवारों का निरीक्षण करें।
kernel-harness inspect artifacts/session-YYYYMMDDTHHMMSSZ --top 10

# 3. एक केंद्रित प्रॉम्प्ट प्रस्तुत करें।
kernel-harness codex artifacts/session-YYYYMMDDTHHMMSSZ \
  --rank 1 \
  --include-snippet

--limit manifest में बनाए रखने के लिए उम्मीदवारों की संख्या है, और --top शुरुआत में पहले से उत्पन्न किए जाने वाले प्रॉम्प्ट बंडलों की संख्या है। बाद के rank के बंडल भी अनुरोध पर उत्पन्न किए जा सकते हैं।

D. समय-बजट-आधारित ऑटोपायलट

root@kitploit:~
kernel-harness autopilot artifacts/session-YYYYMMDDTHHMMSSZ \
  --duration 30m \
  --per-run-timeout 10m \
  --include-snippet

डिफ़ॉल्ट sandbox read-only है। केवल तभी जब विश्लेषण के दौरान फ़ाइल संशोधन अनिवार्य हो, --sandbox workspace-write निर्दिष्ट करें।

E. वैकल्पिक syzbot फ़ीड

root@kitploit:~
kernel-harness syzbot-fetch https://syzkaller.appspot.com/upstream \
  --out artifacts/syzbot/upstream.json \
  --limit 50

kernel-harness scan /path/to/linux \
  --profile fs \
  --syzbot-json artifacts/syzbot/upstream.json \
  --out artifacts

F. सत्र कलाकृतियाँ

root@kitploit:~
artifacts/session-<timestamp>/
├── SESSION.md
├── targets.json
├── finding_template.json
├── review_state.json
├── codex_response.txt              # present while a response is pending
├── bundles/
│   ├── <rank>-<target>.md
│   └── <rank>-<target>.snippet.txt
├── responses/
└── autopilot/
    ├── AUTOPILOT_STATUS.txt
    ├── AUTOPILOT_PROGRESS.txt
    ├── AUTOPILOT_FINDINGS.txt
    ├── prompts/
    ├── exec/
    └── findings/

VI. परिचालन परिणाम और सत्यापन

यह संस्करण केवल अवधारणा प्रमाण नहीं रहा, बल्कि वास्तविक Linux कर्नेल भेद्यता अनुसंधान में उपयोग किया गया।

तालिका II — प्रकाशित भेद्यता परिणाम

सार्वजनिक परिणामप्रभावित क्षेत्रगंभीरता / CVSSभेद्यताअनुसंधान मॉडल
CVE-2026-31720USB gadget audio · drivers/usb/gadget/function/f_uac1_legacy.cHigh 7.8 · CVSS 3.1 (NVD)होस्ट-नियंत्रित अनुरोध लंबाई चार-बाइट स्टैक ऑब्जेक्ट को ओवरफ्लो कर सकती हैv1-सहायता प्राप्त अनुसंधान के दौरान निष्कर्ष सामने आया; सत्यापन और प्रकटीकरण मानव-नेतृत्व में रहा
CVSS स्रोत (2026-08-09 को सत्यापित)
  • CVE-2026-31720: NVD CVSS 3.1 · 7.8 High · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • आधिकारिक प्रकाशित स्कोर और vector को स्थानांतरित किया गया; अलग से पुनर्गणना नहीं की गई।

सत्यापन पहचान सटीकता benchmark नहीं है, बल्कि कार्यान्वयन के प्रतिगमन और तैनाती क्षमता पर केंद्रित है।

तालिका III — इंजीनियरिंग सत्यापन दायरा

सत्यापन आइटमअपेक्षित गुण
Allocator प्रतिगमनkmalloc और kvmalloc को allocator संकेत के रूप में पहचानना
प्रोफ़ाइल संसाधनस्रोत checkout से 6 अंतर्निहित प्रोफ़ाइल लोडिंग, स्थापित wheel से default प्रोफ़ाइल smoke-test
Verdict अनुबंधnot_cve_candidate को सकारात्मक निष्कर्ष के रूप में गलत न समझना
Follow-up नीतिदो मैन्युअल follow-up की अनुमति, तीसरे अनुरोध को अवरुद्ध करना
पुरानी प्रतिक्रिया हैंडलिंगpending target के बिना प्रतिक्रियाओं को archive करना और पुनः उपयोग न करना
सुरक्षित डिफ़ॉल्टautopilot sandbox डिफ़ॉल्ट read-only
CI मैट्रिक्सPython 3.11 और 3.12 पर प्रतिगमन सूट निष्पादन
root@kitploit:~
python -m unittest discover -s tests -v

GitHub Actions unit प्रतिगमन चलाता है, फिर wheel को नए वातावरण में स्थापित करता है और default प्रोफ़ाइल स्कैन का smoke-test करता है। उपरोक्त प्रकाशित मामला वास्तविक अनुसंधान से प्राप्त परिचालन परिणाम है, लेकिन प्रतिनिधि Linux ट्री corpus पर मापा गया precision, recall या CVE खोज दर benchmark नहीं है।

VII. सुरक्षा विचार

  • डिफ़ॉल्ट read-only sandbox बनाए रखने की अनुशंसा की जाती है।
  • बाहरी sandbox के बिना वातावरण में --dangerously-bypass-approvals-and-sandbox का उपयोग न करें।
  • अविश्वसनीय स्रोत टिप्पणियाँ और पहचानकर्ता भी मॉडल इनपुट बन सकते हैं, इसलिए prompt injection पर विचार किया जाना चाहिए।
  • मॉडल द्वारा उत्पन्न निष्कर्षों को प्रकाशन या रिपोर्टिंग से पहले reachability और impact के लिए मानव द्वारा पुनः सत्यापित किया जाना चाहिए।
  • syzbot crash और उच्च अनुमानी स्कोर को भेद्यता प्रमाण के रूप में उद्धृत नहीं किया जाना चाहिए।

VIII. सीमाएँ और वैधता के लिए खतरे

  1. शाब्दिक विश्लेषण। वास्तविक C AST, call graph, interprocedural data flow का निर्माण नहीं करता।
  2. स्कोर पूर्वाग्रह। टिप्पणियाँ, मैक्रोज़, दोहराए गए token, बड़ी फ़ाइलें स्कोर पर अत्यधिक प्रभाव डाल सकती हैं।
  3. Reachability अंतर। कर्नेल config, privilege, namespace, device उपलब्धता को स्वचालित रूप से मॉडल नहीं करता।
  4. बाह्य डेटा नाजुकता। syzbot एकीकरण सार्वजनिक HTML संरचना परिवर्तनों से प्रभावित होता है।
  5. मॉडल निर्भरता। परिणाम की गुणवत्ता उपयोग किए गए मॉडल, prompt व्याख्या और रिपॉजिटरी संदर्भ पर निर्भर करती है।
  6. मूल्यांकन दायरा। वर्तमान परीक्षण सॉफ़्टवेयर प्रतिगमन को सत्यापित करते हैं। प्रकाशित CVE मामला वास्तविक उपयोग परिणाम है, लेकिन सुरक्षा पहचान प्रदर्शन के सांख्यिकीय मूल्यांकन का स्थान नहीं लेता।

IX. पूर्वव्यापी

Git इतिहास में दर्ज पहले संस्करण से लक्ष्य "LLM को भेद्यताएँ स्वयं खोजने देना" से अधिक "किस कोड को पहले देखना है और कौन सा साक्ष्य माँगना है, इसे नियंत्रित करना" के करीब था। CVE-2026-31720 की खोज करने वाला v1-सहायता प्राप्त अनुसंधान संकीर्ण अनुसंधान इकाई और साक्ष्य अनुबंध के वास्तविक अनुसंधान में अनुप्रयोग का उदाहरण प्रदान करता है। v2 इस कार्यप्रवाह को repository state और known reference को एक साथ संरक्षित करने वाले provenance-aware triage तक विस्तारित करता है। यदि अब पुनः कार्यान्वित किया जाए, तो निम्नलिखित को प्राथमिकता दी जाएगी:

  1. tree-sitter या Clang-आधारित symbol/call graph,
  2. फ़ाइल आकार और दोहराए गए हिट को ध्यान में रखते हुए स्कोर सामान्यीकरण,
  3. review और runner परत पृथक्करण के माध्यम से CLI/autopilot डुप्लिकेशन हटाना,
  4. versioned manifest और atomic state write,
  5. JSON Schema-आधारित मॉडल प्रतिक्रिया और संरचित साक्ष्य,
  6. syzbot crash, fix commit, निकटवर्ती variant का स्वचालित कनेक्शन।

फिर भी, बनाए रखने योग्य केंद्रीय सिद्धांत External Signal है। LLM को पूरे कोडबेस में अस्पष्ट रूप से खोजने न दें; मॉडल के बाहर के संकेतों द्वारा संकुचित अनुसंधान इकाइयों को reachability और invariant-केंद्रित रूप से दोहराएँ।

X. निष्कर्ष

Kernel Codex Harness Linux कर्नेल भेद्यता पहचान का स्थान नहीं लेता। इसके बजाय, यह External Signal को व्याख्या योग्य रैंकिंग में बदलता है और LLM समीक्षा को छोटी, स्थिति-युक्त अनुसंधान प्रक्रियाओं तक सीमित करता है। यह संरचना वास्तविक अनुसंधान में CVE-2026-31720 की खोज के लिए उपयोग की गई। परियोजना का मुख्य परिणाम नए विश्लेषण एल्गोरिदम का दावा करने में नहीं है, बल्कि LLM सुरक्षा समीक्षा को external-signal attention allocation, evidence contract, reproducible orchestration की समस्या के रूप में परिभाषित करने और वास्तविक शोध कार्यप्रवाह में लागू करने में है।

परिशिष्ट A. रिपॉजिटरी संरचना

root@kitploit:~
.
├── .github/workflows/ci.yml
├── docs/
│   ├── assets/kernel-harness-architecture.svg
│   ├── AUTOPILOT.md
│   ├── CODEX_CLI.md
│   ├── CODEX_WORKFLOW.md
│   └── SYZBOT.md
├── kernel_harness/
│   ├── resources/
│   │   ├── linux-kernel-default.json
│   │   └── profiles/
│   ├── autopilot.py
│   ├── bundle.py
│   ├── cli.py
│   ├── ingest.py
टूल डाउनलोड करें