Isang libong daan patungong root ang nabawas

Ang pananaliksik sa seguridad na dati ay nangangailangan ng hiwalay at tuloy-tuloy na imbestigasyon para sa bawat natuklasan ay lalo nang naisasagawa bilang isang sistematikong proseso. Tinatalakay ng dokumentong ito ang isa sa aming mga pagsisikap sa larangang ito.

Mas madali nang palawakin ang pagtuklas ng mga kahinaan, pero nananatiling sagabal sa operasyon ang pagtukoy ng priyoridad at pagpapatunay. Bumuo kami ng prototype upang maghanap ng mga depekto sa seguridad ng Linux kernel sa loob ng kontroladong kapaligiran ng pananaliksik. Natukoy at nasuri ng aming prototype ang 2,308 posibleng kahinaan sa Linux kernel, muling napalitaw ang 1,724 na kahinaan sa aktuwal na pagpapatakbo, at nakabuo ng 948 exploit para sa lokal na pagtaas ng pribilehiyo (LPE) na maaaring magbigay ng root access sa lokal na user na walang pribilehiyo.

Ginamit namin ang ebidensyang ito upang unahin ang mga kahinaang iuulat at bumuo ng mga mungkahing patch na susuriin ng mga maintainer. Alinsunod sa gabay ng komunidad ng Linux kernel, nagsimula kami sa mga kritikal na kahinaan at nakikipagtulungan kami sa mga partner ng Patch the Planet para sa higit pang ulat at patch.

Noong Hunyo, bilang bahagi ng aming inisyatibang Patch the Planet, ibinahagi namin na nakatukoy ang GPT‑5.5 Cyber ng mga kahinaan sa Linux kernel at nakabuo ng 24 na exploit para sa lokal na pagtaas ng pribilehiyo upang patunayan at iulat ang mga ito. Pinalawak namin ang gawaing iyon tungo sa isang pipeline na pinapagana ng paparating na modelo para sa cybersecurity, na sumasaklaw sa pagtuklas ng mga kahinaan, pagpapatunay sa aktuwal na pagpapatakbo, pagtatasa kung puwedeng pagsamantalahan ang mga ito, at pagbuo ng mga patch. Nang matapos ito, sinuri ng mga taong mananaliksik ang mga output at iniulat ang mga natuklasang kahinaan kasama ang mga patch.

Ang Linux kernel ang pundasyon ng mga Android device, cloud infrastructure, supercomputer, at iba pang sistemang ginagamit ng bilyun-bilyong tao. Dahil sa mahigit 40 milyong linya ng code nito, malawak ang mga puwedeng atakehin sa kernel sa pamamagitan ng mga system call, networking, filesystem, at device driver. Pinili namin ang Linux upang pag-aralan kung gaano kaepektibong makakatuklas ng mga kahinaan ang mga frontier na modelo at maipapakita ang epekto ng mga iyon sa seguridad sa isang codebase na ganito kalaki at kahalaga.

Libo-libong posibleng kahinaan ang lumabas sa paunang yugto ng pagtuklas—napakarami para mano-manong suriin at isailalim sa triage ng mga mananaliksik sa seguridad. Ang hamon sa pagpapatakbo ng aming pipeline sa pagtuklas ng mga kahinaan ay hindi ang mismong pagtuklas, kundi ang pagtukoy kung aling mga natuklasan ang muling mapapalitaw, anong hangganan ng seguridad ang nalalampasan ng mga ito, at alin ang dapat unang pagtuunan ng pansin ng mga maintainer.

Misyon ng Cyber team ng OpenAI na tumulong sa pagprotekta sa software na inaasahan ng mundo. Iniuulat namin ang gastos sa API sa bawat yugto upang matulungan ang mga mananaliksik na tasahin ang mga mapagkukunang kailangan para ulitin at palawakin ang gawaing ito. Nakabatay ang mga gastos na ito sa mga modelo, configuration ng target, at workflow na ginamit sa ebalwasyong ito. Mas malawak naming layunin na tulungan ang mga tagapagtanggol na maghanap at mag-ayos ng mga kahinaan, upang mabawasan ang mga pagkakataong magagamit ng mga umaatake at tumaas ang gastos nila sa pagsasamantala sa software.

Panghuli, tandaan na nakatuon ang pananaliksik na ito sa metodolohiya at pagsukat sa kakayahan ng modelo, hindi sa gastos. Inaasahan naming malaki ang maibababa ng gastos sa bawat yugto sa pamamagitan ng sapat na pagpapahusay sa harness; kaya mas maituturing na itaas na hangganan ang mga gastos na iniuulat namin.

Ang aming prototype sa pananaliksik ng mga kahinaan ay isang pipeline na may limang yugto, na gumagamit ng paparating na modelo para sa cybersecurity bilang pundasyon nito:

• Pagtuklas ng mga kahinaan: Tinutukoy ng mga agent ang mga bahagi ng codebase na may kaugnayan sa seguridad at sini-scan ang mga ito para sa mga posibleng kahinaan.

• Pagpapatunay sa aktuwal na pagpapatakbo: Sinusubukan ng mga agent na muling palitawin ang bawat posibleng kahinaan sa nakahiwalay na kapaligiran at pinapanatili ang ebidensya mula sa pagpapatakbo. Inilalabas ng hakbang na ito ang mga kahinaang muling napalitaw at napatunayan.

• Pagtatasa kung puwedeng pagsamantalahan: Sinusubukan ng mga agent kung ang mga napatunayang kahinaan ay maaaring magbigay-daan sa paglantad ng impormasyon o lokal na pagtaas ng pribilehiyo.

• Pagbuo ng mga patch: Gumagawa ang mga agent ng mga patch na tumutugon sa bawat natukoy na kahinaan.

• Pagsusuri ng tao: Sinusuri ng mga mananaliksik sa seguridad ang exploit, patch, at iminungkahing antas ng tindi bago iulat sa mga maintainer.

Sa dulo ng pipeline, pinagsasama ng sistema ang pagsusuri sa ugat ng problema, isang pinakasimpleng proof of concept na nagdudulot ng crash, isang mungkahing patch, at isang kumpletong exploit upang tulungan ang mga taong mananaliksik na tasahin ang tindi ng kahinaan at maisama ang mga pag-aayos sa upstream.

Hindi lahat ng linya ng code sa Linux kernel ay may kaugnayan sa seguridad. Gumamit ang aming pipeline ng isang pangkat ng mga Scout agent upang tukuyin ang mahahalagang target ng audit, na ipinasa naman sa mga Analyst agent para i-scan kung may mga kahinaan.

Binabasa ng mga Scout agent ang bawat folder at file at tinutukoy kung ano ang ia-audit batay sa kung maaabot ang mga ito ng mga user na mababa ang pribilehiyo at kung may kaugnayan ang mga ito sa seguridad.

Sa yugtong ito, natukoy ang 5,034 na target ng audit, mga 2.8 milyong linya ng code, na humigit-kumulang 7% ng buong codebase ng Linux kernel. Lubos nitong nabawasan ang gastos sa security audit kumpara sa pagsusuri ng buong codebase. Nagkakahalaga ang hakbang na ito ng $3,426 sa API credits.

Pagkatapos, sinuri ng mga analyst agent ang bawat target ng audit at naglabas ng mga posibleng kahinaan gamit ang workflow na katulad ng sa Codex Security plugin⁠(magbubukas sa bagong window). Sa pangkalahatan, binabasa ng mga analyst agent ang code ng itinalagang target ng audit upang maunawaan kung paano ito gumagana, matukoy ang threat model nito, at maghanap ng mga kahinaan.

Sa loob ng 12 oras, nakapagtala ang mga analyst agent ng 2,308 posibleng kahinaan matapos alisin ang mga duplicate. Nagkakahalaga ang yugtong ito ng $316,549 sa API credits.

Hindi katumbas ng napatunayang kahinaan ang isang posibleng kahinaan. Sa ganitong dami, hindi praktikal para sa aming pangkat ng pananaliksik na mano-manong imbestigahan ang bawat ulat.

Kaya nakatuon kami sa pagpapatunay ng mga natuklasang a) naaabot ng user na mababa ang pribilehiyo, b) hindi nangangailangan ng espesyal na capability, at c) naglalabas ng nasusukat na ebidensya ng pagkasira ng memory.

Para sa bawat posibleng kahinaan, gumawa ang isang triage agent ng proof of concept at pinatakbo ito sa isang nakahiwalay na virtual machine na may Linux kernel na gumagamit ng Kernel Address Sanitizer (KASAN). Inobserbahan ng agent ang output ng programa at ang system console, at paulit-ulit na pinino ang proof of concept hanggang sa maulit nito ang iniulat na gawi o maubos ang mga posibleng paraan para ma-trigger ito.

Sa loob ng 30 oras, muling napalitaw ng aming sistema ang 1724 na kahinaan, ~74.7% ng 2,308 posibleng kahinaan. Maaaring magbunga ng mga false positive ang pagsusuri lang sa code nang hindi ito pinapatakbo, kaya humanga kami sa katumpakan ng mga analyst agent at sa bisa ng mga triage agent na kusang nakabuo ng mga gumaganang proof of concept para sa halos tatlong-kapat ng mga posibleng kahinaan.

Karamihan sa natitirang natuklasan ay nangailangan ng mas mataas na pribilehiyo o hindi muling napalitaw sa nakalaang oras dahil sa mahihirap na race condition, mga partikular na kundisyon para ma-trigger ang mga ito (hal. kailangang pumalya ang allocation sa isang partikular na linya), o matagal na pagpapatunay (hal. refcount wraparound). 3.1% lang ang nagmula sa maling pagsusuri ng modelo, kung saan nakabatay ang iniulat na kahinaan sa isang imposibleng kundisyon.

Umabot sa $73,330 sa API credits ang kabuuang gastos sa yugto ng pagpapatunay. Napansin naming sa aming validation pipeline, na kailangang gumawa ng proof of concept upang makumpirmang tunay ang isang posibleng kahinaan, mas mahal ang prosesong ito kaysa sa pagbibigay ng rekomendasyong batay lamang sa static analysis. Halos magkapareho rin ang gastos sa pagtatangkang patunayan ang isang true positive at isang false positive. Kaya ang mas maagang pag-aalis ng mga false positive sa pipeline ay nakakatulong nang malaki upang maging mas matipid ang proseso.

Pinatutunayan ng validation na tunay ang isang kahinaan, ngunit hindi kung gaano ito kaagarang dapat tugunan. Halimbawa, mas dapat unahin ang kahinaang maaaring magbigay-daan sa lokal na pagtaas ng pribilehiyo kaysa sa kahinaang makapagdudulot lang ng lokal na denial of service. Matapos mapatunayan ang 1,724 na kahinaan, ang susunod na gawain ay tukuyin kung alin ang may pinakamalaking posibleng epekto sa seguridad.

Isang agent para sa paunang pagsala ang nagsuri sa bawat ulat, crash log, at kaugnay na source code nang hindi pinapatakbo ang code. Sadyang maluwag ang pamantayan nito upang hindi maalis ang mga natuklasang posibleng seryoso, habang sinasala ang mga kasong walang kapani-paniwalang paraan ng pagsasamantala. Narrow nito ang mga resulta sa 313 posibleng paglantad ng impormasyon at 1,238 posibleng lokal na pagtaas ng pribilehiyo.

Pagkatapos, sinubukan ng mga agent sa pagbuo ng exploit (ExploitDev) ang mga ito sa mga nakahiwalay na virtual machine na may mga proteksyong naka-enable sa karaniwang distribusyon ng Linux, kabilang ang Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR), at HARDENED_USERCOPY. Nakatulong ito upang maiwasan ang mga hindi makatotohanang pagtatasa na umaasa sa pag-disable ng mga proteksyon.

Nakabuo ang mga agent ng 291 proof of concept para sa paglantad ng impormasyon at 1,169 na gumaganang exploit para sa lokal na pagtaas ng pribilehiyo na maaaring magbigay ng root access sa mga lokal na user na walang pribilehiyo.

Nagsagawa kami ng pagsusuri sa mga baryasyon at bumuo ng 948 magkakaibang patch para sa mga kahinaang ginamit ng mga exploit na iyon. Ginagamit namin ang bilang na iyon upang matukoy ang kabuuang dami ng magkakaibang LPE. Karaniwang nagkakahalaga ng $359 sa credits ang pagbuo ng isang matagumpay na exploit. Dahil dito, medyo mura para sa mga tagapagtanggol na subukan kung puwedeng pagsamantalahan ang mga natuklasang kahinaan.

Nagkakahalaga ng $44,194 sa API credits ang agent para sa paunang pagsala ng mga kahinaan. Umabot sa $775,929 sa API credits ang kabuuang gastos sa yugto ng pagsasamantala: $84,929 para sa pagproseso ng mga posibleng paglantad ng impormasyon at $691,000 para sa mga posibleng lokal na pagtaas ng pribilehiyo.

Sa karaniwan, halos doble ang gastos sa pagproseso ng isang posibleng lokal na pagtaas ng pribilehiyo ($558) kumpara sa isang posibleng paglantad ng impormasyon ($271). Ito ay dahil ipinagpatuloy mula sa yugto ng pagpapatunay ang mga PoC para sa paglantad ng impormasyon, kaya mas kaunting pagbabago ang kailangan upang magamit ang mga ito sa isang exploit. Sa kabilang banda, ang pagbuo ng exploit mula sa isang posibleng LPE ay nangangailangan ng maraming dagdag na hakbang, gaya ng pagpaplano ng estratehiya ng pagsasamantala, pagtukoy sa mga object na may kahinaang gagamitin, pag-iwas sa mga proteksyon, at iba pa. Napansin din naming mas malaki ang gastos sa mga nabigong pagtatangka ng pagsasamantala ($3,922 para sa 69 na kaso) kaysa sa mga matagumpay ($360 para sa 1169 na kaso). Dulot ito ng ilang kahinaang mahirap pagsamantalahan (hal. mga race condition). Malaki sana ang maibabawas sa gastos ng ExploitDev kung may itinakdang makatwirang kundisyon para sumuko, gaya ng paghinto sa pagtatangka kapag walang naging progreso sa loob ng isang oras.

Para sa bawat napatunayang kahinaan, bumubuo rin ang sistema ng patch. Ibinibigay namin sa modelo ang kaugnay na source code at inaatasan itong sundin ang pinakamahuhusay na kasanayan sa pagsulat ng patch, gaya ng pagsasagawa ng mga static check sa patch, pagsunod sa mga kasanayan sa software development na ginagamit sa kalapit na code, at pagsusuri sa mga baryasyon upang matiyak na kumpleto ang patch.

Alinsunod sa mungkahi ng komunidad ng Linux kernel, nakapagpadala na kami ng daan-daang ulat at patch para sa mga kritikal na kahinaan at nakikipagtulungan kami sa mga partner ng Patch the Planet upang unti-unting ipadala ang mga patch para sa natitira. Bahagi ang gawaing ito ng aming mas malawak na pangako sa ilalim ng Daybreak na suportahan ang mga open-source project.

Sa seksyong ito, ibinabahagi namin ang mga aral, pagninilay, at karagdagang pagsusuri mula sa pananaliksik na ito.

Sa pananaliksik na ito, nakita naming mabilis na kumilos ang mga maintainer ng Linux upang ayusin ang mga kahinaan at protektahan ang mga user. Isinagawa ang scan sa pinakabagong Linux kernel noong kalagitnaan ng Oktubre 2026. Nang matapos ang awtonomong scan at mano-manong pagsusuri makalipas ang 10 araw, 61 LPE na ang nalapatan ng patch sa upstream, 43 ang may mga patch na inihahanda, at 299 ang iniuulat at tinatalakay sa publiko.

Lubos naming pinahahalagahan ang mga maintainer ng Linux na agarang nagtatrabaho upang malapatan ng patch ang mga natukoy na isyu, pati ang mas malawak na komunidad ng seguridad na nag-aambag din ng kanilang mga natuklasan. Ang ganitong sama-samang pagtugon ang kailangan upang maprotektahan ang software sa buong mundo. Binibigyang-diin din ng mabilis na pagsisiwalat at pag-patch ng mga kahinaan kung gaano kahalaga para sa mga user at kumpanya na panatilihing updated ang software.

Mahalagang aral: Dapat isaalang-alang ng awtomatikong triage ang mabilis na siklo ng pag-patch. Nakakatulong na muling patunayan ang mga natuklasan gamit ang pinakabagong code, kabilang ang bagong code na isinama matapos ang orihinal na scan, upang maiwasan ang mga ulat na duplicate o hindi na napapanahon. Itinutuon nito ang pansin sa mga hindi pa naaayos na kahinaan at nagbibigay sa mga maintainer ng ebidensyang maaaksyunan nila nang hindi dinaragdagan ng hindi kailangang pagsusuri ang kanilang gawain.

Habang binubuo namin ang pipeline noong huling bahagi ng Hulyo 2026, nakatuklas at nakapagsamantala ang GPT‑5.6 Sol ng 166 na magkakaibang LPE na kahinaan sa kabuuang gastos na $513,690 sa API credits.

Sa ikalawang scan noong kalagitnaan ng Oktubre 2026, nakatuklas at nakapagsamantala ang mas bagong modelo para sa cybersecurity ng 948 magkakaibang LPE na kahinaan sa kabuuang gastos na $1,213,430 sa API credits. Sa parehong kampanya, ang pinakabagong master branch ng Linux kernel noong panahong iyon ang aming na-scan.

Mahalagang aral: Muling i-scan ang code na dati nang na-audit habang humuhusay ang kakayahan ng mga modelo. Maaaring matuklasan ng mas mahusay na modelo ang mga kahinaang hindi nakita ng mga naunang modelo, kahit pareho ang ginagamit na harness sa pananaliksik.

Kumuha kami ng sample na 166 na exploit na binuo ng mga agent at sinuri ang mga pamamaraan ng pagsasamantalang ginamit sa mga ito. Sa abot ng aming kaalaman, gumamit ang mga agent ng 10 bagong pamamaraan ng pagsasamantala sa mga exploit sa sample. Ibinahagi namin ang mga pamamaraan sa mga panlabas na eksperto sa pagsasamantala sa kernel, at bago rin sa kanila ang mga ito.

Sa 10 pamamaraan, dalawa ang bagong persistent elastic object na ginamit ng modelo upang mag-spray ng mga object sa loob ng target na kernel cache; dalawa ang bagong pamamaraan ng page grooming upang gawing mas maaasahan ang exploit; lima ang bagong data-only na pamamaraan upang direktang makakuha ng mas mataas na pribilehiyo o gawin ito sa pamamagitan ng arbitrary write; at ang natitira ay gumagamit ng arbitrary type confusion. Para sa kaligtasan, hindi namin ibinabahagi sa post na ito ang buong teknikal na detalye ng mga bagong pamamaraan ng pagsasamantalang ito.

Mahalagang aral: Hindi lang tumutugma sa mga kilalang pattern ng code na may kahinaan o gumagamit lamang ng mga kilalang pamamaraan ng pagsasamantala ang mga frontier na modelo; nagpapakita rin sila ng pagkamalikhain at mga bagong diskarte.

Mahalagang bahagi ng misyon ng aming pangkat ang pagsukat sa gastos ng paghahanap at pagsasamantala sa mga kahinaan, at paggamit sa ebidensyang iyon upang gabayan ang pamumuhunan sa depensa. Layunin naming tulungan ang mga tagapagtanggol na ayusin ang mga kahinaan bago magamit ng mga umaatake, at gawing napakamahal para sa mga umaatake ang pagsasamantala sa software. Nakakatulong ang pagsukat sa gastos ng pagsasamantala upang matasa namin kung paano nagbabago ang hamong iyon habang humuhusay ang kakayahan ng mga modelo. Sa seksyong ito, inihahambing namin ang gastos sa pagpapatakbo ng aming pipeline sa mga gantimpala ng mga bug bounty program para sa mga natukoy na kahinaan.

Karaniwang desktop operating system ang pinatakbo ng mga target na virtual machine sa aming eksperimento, hindi target na pinahina ang seguridad, sa ilalim ng parehong threat model na ginagamit sa mga kompetisyon sa cybersecurity (hal. Pwn2Own⁠(magbubukas sa bagong window), TyphoonPWN⁠(magbubukas sa bagong window)). Dati nang nag-alok ang Pwn2Own at TyphoonPWN ng mga bug bounty na $20,000 at $70,000, ayon sa pagkakasunod, para sa mga exploit sa lokal na pagtaas ng pribilehiyo sa Linux kernel. Kung ilalapat ang mga dating halagang iyon sa 948 exploit, aabot sa $18.9M—$66.3M ang hipotetikal na halaga, humigit-kumulang 16 hanggang 55 ulit ng gastos sa aming pipeline.

Sinubukan din namin ang aming pipeline sa vulnerability reward program na kernelCTF⁠(magbubukas sa bagong window) ng Google, na gumagamit bilang target ng Linux kernel na pinatibay ang seguridad at binawasan ang mga puwedeng atakehin. Pinatakbo namin ang pipeline sa pinakabagong bersyon ng Linux kernel sa kapaligiran ng kernelCTF at nakakuha ng 25 proof of concept para sa paglantad ng impormasyon at 21 exploit para sa lokal na pagtaas ng pribilehiyo. Hindi tugma ang bersyong iyon sa SLAB_VIRTUAL mitigation ng kernelCTF, kaya inalis namin iyon sa configuration. Bilang paghahambing, sa oras ng pagsulat nito, 26 na kumpirmadong 0-day LPE exploit na ang tinanggap ng kernelCTF noong 2026. Tumagal ang buong kampanya nang 112 oras, na may gastos na humigit-kumulang $32,936 sa API credits. Napunta sa pagtuklas ng mga kahinaan ang 83.7% ng gastos sa API. Kung tinanggap ng programa ang 21 kahinaan, magreresulta ito sa humigit-kumulang $1.5M na bounty reward, mga 45 ulit ng gastos.

Mahalagang aral: Batay sa mga pampublikong halaga ng gantimpala, gamit ang kasalukuyang mga modelong may kakayahan sa cybersecurity, may netong kita ang aming pipeline sa pananaliksik ng mga kahinaan noong panahon ng pananaliksik na ito. Dapat maagap na suriin ng mga tagapagtanggol ang kanilang software upang maging napakamahal para sa mga umaatake ang pagsasamantala rito.

Sa pagtatasa kung puwedeng pagsamantalahan ang mga kahinaan, binigyan ang mga ExploitDev agent ng ulat ng kahinaan at inatasang gumawa ng ganap na gumaganang exploit. Minarkahan ng aming pipeline ang isang kahinaan bilang napagsamantalahan kung matagumpay na nakakuha ng root shell. Sa isang maagang pagpapatakbo, nag-ulat ang yugto ng pagsasamantala ng 200 matagumpay na exploit para sa lokal na pagtaas ng pribilehiyo. Gayunman, matapos suriin ng tao, natuklasan naming 20 sa mga ito ang nakakuha ng root privilege sa pamamagitan ng ibang 0-day na kahinaan, hindi ang itinalaga sa kanila. Ipinahihiwatig nito na kailangan pa rin ng wastong pagpapatunay kahit matagumpay ang pagsasamantala ng mga agent.

Pagkatapos, hinigpitan namin ang mga limitasyon ng gawain at nagdagdag ng hiwalay na pagsusuri upang makumpirmang ginamit ng bawat pinal na exploit ang kahinaang itinalaga rito.

Mahalagang aral: Sa awtonomong pananaliksik sa seguridad, patunayan hindi lang ang resulta kundi pati ang paraang ginamit upang makuha ito; kailangang may paghihiwalay, pagsubaybay, at mga hiwalay na pagsusuri bilang mga kontrol.

Sa simula ng pananaliksik na ito, pinag-aralan namin kung dapat bang bumuo ng masinsing orchestration sa paligid ng agent upang mapahusay ang kakayahan nito sa cybersecurity. Ipinahiwatig ng aming resulta na mas kaunting orchestration at paggabay ang kailangan ng mas mahuhusay na modelo. At hindi sulit ang kaunting pagbuti kumpara sa gastos sa pagpapanatili nito. Dahil dito, nagpasya kaming alisin ang masinsing orchestration.

Inihambing sa eksperimento ang GPT‑5.5 Cyber at GPT‑5.6 Cyber. Sa aming obserbasyon, hindi palaging natutukoy ng GPT‑5.5 Cyber kung kailan at paano ilalapat ang mga umiiral na pamamaraan ng pagsasamantala sa Linux kernel. Pagkatapos, nagtipon kami ng 103 pamamaraan sa format na madaling gamitin ng modelo, inilagay ang mga ito sa kapaligiran ng agent, at inutusan ang agent na gamitin ang mga ito. Sa 63 posibleng target ng pagsasamantala, pinataas nito ang antas ng tagumpay mula 76.2% tungong 88.9%.

Nang ulitin namin ito gamit ang GPT‑5.6 Cyber, mas mahusay na nakahanap, nakapili, at nakapaglalapat ang modelo ng mga naaangkop na pamamaraan nang mag-isa. Inalis namin ang orchestration para sa mga pamamaraan/skill, at mas mahusay ang naging resulta ng workflow na ito ng GPT‑5.6 Cyber na may kaunting orchestration kaysa sa workflow ng GPT‑5.5 Cyber na may mas maraming suportang istruktura. Nang ibalik ang dagdag na layer ng mga pamamaraan para sa GPT‑5.6 Cyber, 1.5 percentage point lang ang naging pagbuti.

Mahalagang aral: Muling suriin ang inyong orchestration at harness habang nagbabago ang kakayahan ng base na modelo. Ang suportang istrukturang malaki ang naitutulong sa isang henerasyon ng modelo ay maaaring kaunti lang ang maidagdag sa mas mahusay na modelo, kaya dapat suriin kung sulit pa ito kumpara sa gastos sa pagpapanatili.

Noong una, kapag direktang inutusang gumawa ng mga mungkahing patch, nakakabuo ang modelo ng mga patch na gumagana nang tama at pumipigil sa proof of concept, ngunit paminsan-minsan ay nagdudulot ng iba pang isyu: sobrang code, posibleng pagbaba ng performance, paglihis sa mga kumbensyon sa coding, o hindi pagsusuri sa kaugnay na code para sa mga baryasyon ng parehong kahinaan, na humahantong sa hindi kumpletong mga patch.

Napahusay ng mga karagdagang tagubilin at paulit-ulit na pagpino sa proseso ng pagbuo ng patch ang kalidad ng mga patch. Ipinahihiwatig nito na sa wastong pangangasiwa, posibleng maging tama, walang labis na code, at naaayon sa umiiral na mga kumbensyon ng code ang mga security patch na binuo ng AI. Aktibong larangan ito ng pananaliksik, at naniniwala kaming magiging mas madali at mas epektibo ito sa mga susunod na modelo. Sa ilang kaso, natukoy rin ng aming research prototype ang mga isyu sa mga patch na isinulat ng mga taong eksperto, na naayos bago isinama ang mga ito sa code.

Mahalagang aral: Mapapabilis ng mga modelo ang proseso ng pag-patch, ngunit maaaring kailangang paulit-ulit na pinuhin ang mga skill at harness para rito upang matiyak na maaasahang natutugunan ng mga patch ang mga kinakailangan sa paggana at iba pang aspekto. Inirerekomenda rin naming gumamit ng mga modelo upang suriin ang mga patch na ginawa ng tao at AI mula sa pananaw ng umaatake. Matutukoy nito ang mga isyung gaya ng kakayahang malampasan ang patch, mga hindi nasaklaw na paraan o baryasyon ng pag-atake, at iba pa.

Sa aming pagpapatakbo sa kernelCTF, bukod sa 21 Linux kernel 0-day exploit, nakatuklas at nakapagsamantala rin ang aming research prototype ng kahinaan sa QEMU TCG. Itinalaga sa analyst agent ang pagsusuri sa system call entry code. Habang nagsusulat ito ng mga programa upang mag-eksperimento sa mga paglipat ng antas ng pribilehiyo, nakaranas ito ng hindi inaasahang pag-crash ng kernel. Nagsagawa ito ng triage sa crash at natunton ang isyu sa QEMU TCG, kahit walang access sa source code ng QEMU, at isinama ang kahinaan sa ulat. Pagkatapos, matagumpay na nakabuo ang ExploitDev agent ng exploit para sa lokal na pagtaas ng pribilehiyo gamit ang kahinaang ito. Natuklasan namin ang kahinaang ito sa QEMU nang mano-mano naming suriin ang mga exploit. Nakumpirma naming naayos na ito sa upstream QEMU, ngunit hindi pa sa release build na ginamit sa eksperimento.

Mahalagang aral: Kayang tumuklas ng mga frontier na modelong may kakayahan sa cybersecurity ng mga kahinaan sa imprastruktura ng pagsubok. Inirerekomenda naming subukan ang bawat bahagi ng imprastruktura bago magsagawa ng pananaliksik na gumagamit ng pag-atake upang tuklasin ang mga kahinaan. Maagap naming sinubukan ang aming imprastruktura, at isiniwalat at nilapatan ng patch ang maraming kahinaan sa Kata, Moby/Docker, gVisor, at iba pang proyekto.

Layunin naming gawing pangmatagalang bentahe para sa mga nagpoprotekta sa Internet ang lumalawak na kakayahan ng mga modelo. Ipinapakita ng pananaliksik na ito na magagamit ang lumalawak na kakayahan sa cybersecurity ng mga frontier na modelo upang epektibong maghanap ng mga kahinaan sa kumplikadong software, gaya ng Linux kernel. Ang pagpapatibay ng seguridad ng mahahalagang software project tulad ng Linux at iba pang open-source project ay makakaprotekta sa maraming sistema at user na umaasa sa mga ito.

Sa pamamagitan ng Patch the Planet, isang inisyatiba ng Daybreak, layunin naming palawakin ang pananaliksik na ito sa mas marami pang mahahalagang software project at bumuo ng maaasahang awtomatikong paglalapat ng patch kasama ang mga maintainer at partner sa seguridad. Nais naming patuloy na bawasan ang mga pagkakataong magagamit ng mga umaatake at pataasin ang gastos sa paghahanap at pagsasamantala sa mga kahinaan, hanggang sa hindi na maging sulit ang inaasahang pakinabang sa pag-atake.

Dapat makatulong ang bawat henerasyon ng mga modelo sa pagbuo ng software na mas mahihirapang mapasok ng susunod na henerasyon. Patuloy kaming magsisikap na bumuo ng ligtas na Internet kung saan masayang makakalikha ang sinuman.