Torvalds impune noi reguli: rapoartele de vulnerabilități generate de AI au inundat lista de securitate a kernelului

 Zeci de rapoarte identice trimise simultan de cercetători diferiți care folosesc aceleași unelte AI au transformat lista privată de securitate a kernelului Linux într-un „cuello de botella" aproape inoperabil — și Linux 7.1 răspunde cu o documentație nouă care redefinește ce este o vulnerabilitate reală și cum trebuie raportată.

19 mai 2026·Pablinux · LinuxAdictos·~6 min citire

---

2–3

rapoarte/săptămână
acum doi ani

5–10

rapoarte/zi
în prezent

Linux 7.1

prima versiune cu noua politică AI documentată

Linus Torvalds a ridicat în notele de lansare ale Linux 7.1-rc4 o problemă pe care o amână de mai multe luni: lista privată de securitate a kernelului, destinată raportării confidențiale a vulnerabilităților critice, a devenit aproape inoperabilă din cauza unui flux continuu de rapoarte generate sau asistate de inteligență artificială, dintre care marea majoritate sunt duplicate ale aceluiași bug descoperit simultan de mai mulți cercetători care folosesc unelte similare.

Linus Torvalds — Linux 7.1-rc4 release notes

„Lista privată de securitate a kernelului a ajuns aproape complet inoperabilă din cauza avalanșei de rapoarte asistate de AI — multe dintre ele identice, trimise de persoane diferite care au rulat aceleași unelte pe același cod."

Sursa: lkml.iu.edu/hypermail/linux/kernel/2605.2/01597.html

Cifra care ilustrează magnitudinea problemei vine de la Willy Tarreau, veteran al mentenanței kernelului stabil și autorul noii documentații: acum doi ani, lista privată primea două-trei rapoarte pe săptămână. Astăzi primește între cinci și zece pe zi.

Acum 2 ani

2–3

rapoarte pe săptămână

→

Astăzi

5–10

rapoarte pe zi — mulți duplicați

Torvalds nu este împotriva AI — este împotriva utilizării sale fără responsabilitate

O clarificare importantă, pe care Torvalds o face explicit: nu este vorba de o poziție antitehnologie. El însuși recunoaște că folosește unelte AI în propriul flux de lucru. Problema identificată este alta — cercetătorii care primesc un rezultat brut de la un model AI și îl trimit direct pe lista de securitate, fără a verifica dacă bug-ul există cu adevărat, dacă a fost deja raportat sau deja corectat, și fără să adauge nicio valoare interpretativă.

Torvalds numește acest comportament „durere inutilă și muncă fictivă fără valoare reală" — nu o critică la adresa AI-ului ca instrument, ci la adresa utilizatorilor care acționează ca simpli intermediari între o unealtă automată și lista de corespondență, fără a adăuga judecată sau verificare proprie.

„Uneltele AI sunt extraordinare când chiar ajută — dar devin o problemă atunci când generează durere inutilă și muncă fictivă fără valoare reală. Cel care folosește AI pentru a găsi bug-uri trebuie să adauge valoare umană — nu să retransmită un rezultat brut."
— Linus Torvalds, Linux 7.1-rc4

Noua documentație din Linux 7.1: ce este și ce nu este vulnerabilitate

Răspunsul proiectului este practic și documentat: Willy Tarreau a redactat o nouă politică, integrată în arborele Git al kernelului înainte de Linux 7.1-rc4, care clarifică cu precizie ce tipuri de probleme merită să intre pe lista privată de securitate și care ar trebui tratate deschis pe listele publice de dezvoltare.

✓ Vulnerabilitate reală — canal privat

• Traversare limită user-space ↔ kernel
• Escaladare de privilegii exploatabilă realist
• Ocolire izolare memorie între procese
• Desfacere restricții ptrace
• Compromitere izolare IPC sau rețea
• Scurgere date prin user namespaces

✗ Bug obișnuit — canale publice

• Ramuri kernel depășite și nesuportate
• Opțiuni compilare insecure alese de admin
• Funcții exclusiv de depanare (KASAN, LOCKDEP)
• Cod experimental în staging
• Scenarii de laborator nerealiste
• Hardware fizic manipulat ca precondiție
• Scurgeri de info fără exploit clar

Principiul de bază al ghidului este simplu: bug-urile discutate în public primesc mai mulți ochi, mai mulți scenarii de utilizare acoperite și soluții de calitate mai ridicată. Canalul privat există pentru problemele care nu pot fi divulgate public înainte de existența unui patch — nu pentru orice potențial bug identificat de o unealtă automată.

Bug-uri găsite cu AI: tratate ca esențialmente publice

Una dintre schimbările de politică cu cel mai mare impact practic privește direct rapoartele generate cu ajutorul AI. Noua documentație stabilește că bug-urile detectate prin analiză automatizată trebuie tratate ca informații esențialmente publice — chiar dacă primul contact se face prin e-mail privat.

Motivul este empiric, nu filozofic: experiența recentă arată că aceleași bug-uri identificate de o unealtă AI ajung simultan la mai mulți cercetători care rulează aceleași unelte pe același cod. Orice așteptare de confidențialitate prelungită este nerealistă. Dacă o unealtă AI disponibilă publicului poate găsi un bug în câteva ore, este rezonabil să presupunem că alți actori — inclusiv potențiali atacatori — pot ajunge la același rezultat.

Asta nu înseamnă că toată informația trebuie publicată imediat. Documentația cere ca, în cazul bug-urilor găsite cu AI, cercetătorul să nu trimită imediat un reproductor funcțional complet — secvența exactă de cod sau pași care declanșează eroarea. Este suficient să se menționeze că reproductor-ul există și să se lase mentenantorii să îl solicite privat dacă este necesar pentru validarea corecției.

Cum trebuie să arate un raport de calitate generat cu AI

📝

Scurt, clar, în text simplu — fără MarkdownFormatele complexe nu supraviețuiesc bine în lanțuri de răspunsuri pe listele de corespondență. Mentenantorii trebuie să poată cita și retransmite mesajul fără a pierde informații sau a produce text ilizibil.

🔍

Rezumat inițial: fișier/subsistem, versiuni afectate, efect observabilPrimele rânduri trebuie să permită clasificarea rapidă a raportului — critic, moderat sau minor — fără a citi întregul document.

✅

Reproductor verificat personal înainte de trimitereDacă secvența nu declanșează bug-ul sau AI nu poate genera un reproductor funcțional, validitatea raportului este serios pusă la îndoială. Rapoartele neverificate adaugă zgomot și consumă timp.

⚖️

Impact bazat pe fapte verificabile, nu pe scenarii înlănțuite ipoteticRapoartele AI tind să exagereze consecințele teoretice. Documentul cere să se descrie concret ce capacități suplimentare ar obține un utilizator pe un sistem configurat standard — nu construcții narativ-ipotetice de atac.

🩹

Propunere de patch, dacă AI poate genera unulDocumentul notează că multe AI sunt mai bune la scris cod decât la evaluarea impactului. Cercetătorul ar trebui să ceară unealtei și o propunere de corecție — cu condiția de a o verifica și testa manual înainte de a o trimite.

📌

Tag „Fixes:" indicând commit-ul care a introdus bug-ulConform normelor standard de trimitere a patch-urilor în kernel. Fără această etichetă, integrarea corecției este mai lentă și mai dificilă.

Paralela cu fuzzing: o lecție deja trăită

📜 Un precedent relevant: syzkaller și fuzzing-ul

Situația actuală cu AI are un precedent direct în adoptarea unealtelor de fuzzing automatizat ca syzkaller, care la un moment dat au bombardat la rândul lor kernelul cu rapoarte de bug-uri detectate semi-automat. Comunitatea a trebuit atunci să integreze acel flux continuu în procesul de dezvoltare fără a colaps fluxul de lucru zilnic. Cu AI, fenomenul se repetă la o scară mult mai mare: nu se automatizează doar generarea de intrări care produc erori, ci și redactarea rapoartelor, analiza statică a codului și propunerea de patch-uri. Greg Kroah-Hartman — un alt mentenator cheie — a observat că rapoartele AI au trecut rapid de la „aproape întotdeauna inutilizabile" la „contribuții valide". Torvalds și Kroah-Hartman nu sunt în contradicție: reflectă cele două fețe ale aceluiași proces de adopție.

Mesajul final al noii politici este unul de invitație, nu de interdicție: proiectul Linux îi încurajează pe cercetători să folosească AI nu doar pentru a identifica bug-uri, ci și pentru a propune și testa patch-uri care urmează normele standard ale kernelului. Acel ciclu complet — descoperire, verificare, corecție, testare, trimitere — este contribuția pe care comunitatea o apreciază. Simpla retransmisie a unui rezultat brut de unealtă nu este.