Découverte d’un 0-day distant dans une implémentation SMB de Linux avec o3

• Lors d’un audit de ksmbd, l’implémentation serveur SMB3 du noyau Linux, une vulnérabilité distante de type use-after-free, CVE-2025-37899, a été trouvée uniquement avec l’API o3 d’OpenAI, sans framework d’agent ni outil supplémentaire
• La vulnérabilité concerne l’accès persistant par un autre thread à sess->user, libéré pendant le traitement de la commande SMB logoff ; elle n’apparaît qu’en considérant à la fois les connexions concurrentes et l’état de session partagé
• Dans un benchmark basé sur CVE-2025-37778, trouvé manuellement, o3 a identifié la vulnérabilité 8 fois sur 100, contre 3 fois pour Claude Sonnet 3.7 et 0 fois pour Claude Sonnet 3.5
• Avec des entrées élargies à tous les gestionnaires de commandes SMB et au code de gestion des connexions, soit 12 kLoC / 100k tokens d’entrée, le taux de détection de la vulnérabilité connue est tombé à 1 sur 100, mais la nouvelle vulnérabilité CVE-2025-37899 est ressortie dans ces mêmes résultats
• Les faux positifs et les sorties sans intérêt restent nombreux, mais la probabilité d’obtenir une bonne réponse est devenue assez élevée pour que, dans une recherche réelle de vulnérabilités, une revue et une validation humaines en vaillent la peine

---

Expérience de détection d’une vulnérabilité dans ksmbd avec o3

• La cible de l’audit était ksmbd, qui implémente le partage de fichiers via le protocole SMB3 dans l’espace noyau Linux
• Le modèle o3 d’OpenAI a été appelé via l’API o3, sans scaffolding, framework d’agent ni outil supplémentaire
• La vulnérabilité découverte est CVE-2025-37899, et le correctif se trouve dans ce commit du noyau Linux
• Le problème central est un use-after-free dans le gestionnaire de la commande SMB logoff, où un objet sans compteur de références est libéré alors qu’il reste accessible depuis un autre thread
• Pour trouver cette vulnérabilité, il faut comprendre à la fois les connexions concurrentes au serveur et les objets partagés dans certaines situations
• L’analyse inclut l’appréciation selon laquelle il s’agirait du premier cas discuté publiquement où un LLM trouve une vulnérabilité de cette nature

Vulnérabilité de référence CVE-2025-37778

• CVE-2025-37778, d’abord trouvée manuellement, a été utilisée comme benchmark pour évaluer les performances d’o3
• Cette vulnérabilité est un use-after-free qui survient dans le chemin d’authentification Kerberos lors du traitement d’une requête session setup d’un client distant
• krb5_authenticate libère sess->user lorsque sess->state == SMB2_SESSION_VALID
• Le code qui suit repose sur l’hypothèse que ksmbd_krb5_authenticate le réinitialise avec une nouvelle valeur valide, ou qu’après un retour -EINVAL, sess->user n’est plus utilisé
• En réalité, il est possible de faire en sorte que ksmbd_krb5_authenticate ne réinitialise pas sess->user, et l’accès à sess->user reste possible même si krb5_authenticate renvoie -EINVAL

Configuration du benchmark et prompt

• CVE-2025-37778 a été utilisée comme benchmark parce qu’elle se situe sur une surface d’attaque distante et nécessite de raisonner à la fois sur la condition sess->state == SMB2_SESSION_VALID, sur un chemin sans réinitialisation et sur le chemin d’accès après libération
• Le code minimal nécessaire pour expliquer le chemin vulnérable a été estimé à environ 3,3 kLoC
• L’entrée de l’expérience incluait le gestionnaire de commande session setup ainsi que les fonctions qu’il appelle jusqu’à une profondeur d’appel de 3
• Le code de réception des paquets, de parsing des requêtes, de sélection des gestionnaires de commandes et de nettoyage des connexions après exécution des gestionnaires a également été inclus, afin de réduire les suppositions sur la façon dont les structures de données sont initialisées
• L’entrée finale représentait environ 3,3 kLoC / 27k tokens, et le fichier analysé est publié sous le nom session_setup_code.prompt
• Le prompt contenait les conditions suivantes
  • demander de trouver des vulnérabilités de type use-after-free
  • fournir une vue de haut niveau du rôle de ksmbd, de son architecture et du modèle de menace
  • orienter fortement le modèle pour qu’il préfère ne rien signaler plutôt que de rapporter des faux positifs
• Le fichier complet du prompt se trouve dans le dépôt o3_finds_cve-2025-37899
• L’exécution a utilisé l’outil llm de Simon Willison

Résultats du benchmark CVE-2025-37778

• Le harnais d’expérimentation a exécuté la même requête 100 fois et enregistré les résultats
• o3 a trouvé CVE-2025-37778 8 fois sur 100
• Dans 66 cas sur 100, il a estimé qu’il n’y avait pas de bug, ce qui a produit des faux négatifs
• Les 28 cas restants étaient des faux positifs
• Les résultats comparatifs sont les suivants
  • Claude Sonnet 3.7 : 3 détections sur 100
  • Claude Sonnet 3.5 : 0 détection sur 100
• Dans ce benchmark, o3 affiche une amélioration d’un facteur 2 à 3 par rapport à Claude Sonnet 3.7
• Des exemples de rapports sont publiés pour les résultats d’o3 et les résultats de Sonnet 3.7
• Les sorties d’o3, par leur structure et leur focalisation, se lisent comme des rapports de bug abrégés écrits par un humain, mais peuvent parfois être trop courtes et manquer de clarté
• Les sorties de Sonnet 3.7 ressemblent davantage à un fil de raisonnement ou à un journal de travail

Expérience élargie à tous les gestionnaires de commandes

• Dans l’expérience suivante, le code fourni à o3 ne se limitait pas au gestionnaire session setup, mais incluait tous les gestionnaires de commandes SMB
• Ces gestionnaires se trouvent dans smb2pdu.c, un fichier d’environ 9 kLoC
• En combinant tous les gestionnaires, le code de configuration et de nettoyage des connexions, ainsi que la routine de dispatch des gestionnaires de commandes, on obtient environ 12 kLoC / 100k tokens d’entrée
• Dans ces conditions, l’expérience a également été exécutée 100 fois
• o3 n’a trouvé la vulnérabilité Kerberos connue CVE-2025-37778 qu’1 fois sur 100, avec une baisse de performance nette liée à l’augmentation du nombre de tokens d’entrée
• Dans ce même lot de résultats, un rapport portant sur une nouvelle vulnérabilité jusqu’alors inconnue, CVE-2025-37899, a été identifié

Chemin vulnérable de CVE-2025-37899

• La nouvelle vulnérabilité est elle aussi liée à la libération de sess->user, mais cette fois dans le gestionnaire de session logoff
• smb2_session_logoff fonctionne dans l’ordre suivant
  • appel à ksmbd_close_session_fds(work)
  • appel à ksmbd_conn_wait_idle(conn)
  • passage de l’état de la session à SMB2_SESSION_EXPIRED
  • si sess->user existe, libération via ksmbd_free_user(sess->user) puis définition de sess->user = NULL
• Le scénario vulnérable décrit dans le rapport d’o3 est le suivant
  • avec SMB 3.0 ou plus récent, un second transport est lié à la session existante et conn->binding == true
  • Worker-A traite une requête ordinaire comme WRITE sur une autre connexion C2
  • smb2_check_user_session() stocke dans work->sess le pointeur struct ksmbd_session existant et incrémente le compteur de références de la session, mais ne prend pas de référence distincte sur sess->user
  • Worker-B traite un SMB2 LOGOFF pour la même session sur la première connexion C1 et exécute smb2_session_logoff()
  • ksmbd_conn_wait_idle(conn) n’attend que les requêtes en cours sur cette connexion, et pas celles d’autres connexions utilisant la même session
  • Worker-A continue à s’exécuter et peut effectuer des accès tels que user_guest(sess->user), ksmbd_compare_user(sess->user, …) ou sess->user->uid
• Selon le timing, cela peut devenir un use-after-free pointant vers un objet slab libéré, ou une lecture après sess->user = NULL peut provoquer un déréférencement NULL et un DoS

Correctif erroné et valeur des résultats d’o3

• Le premier correctif proposé pour CVE-2025-37778 consistait à ajouter sess->user = NULL après ksmbd_free_user(sess->user)
• La lecture du rapport sur CVE-2025-37899 a montré que ce correctif était insuffisant
• Le gestionnaire logoff exécute déjà sess->user = NULL, mais le protocole SMB permet de lier deux connexions différentes à une même session, ce qui laisse la vulnérabilité présente
• Dans le chemin d’authentification Kerberos aussi, un autre thread peut accéder à sess->user dans la courte fenêtre suivant sa libération et précédant sa mise à NULL
• Certains rapports d’o3 commettaient la même erreur, mais d’autres relevaient qu’en raison de la possibilité de liaison de session, sess->user = NULL seul ne suffisait pas
• Le ratio de vrais positifs par rapport aux faux positifs étant élevé, une limite est qu’il n’est pas certain que tous les rapports aient été examinés avec suffisamment d’attention

Place pratique dans la recherche de vulnérabilités

• Les LLM se situent, en matière de créativité, de flexibilité et de généralité, plus près d’un auditeur humain de code que des techniques classiques d’analyse de programmes
• Les comparaisons mentionnées incluent symbolic execution, abstract interpretation et fuzzing
• Depuis GPT-4, le potentiel des LLM pour la recherche de vulnérabilités existait, mais sur de vrais problèmes, les résultats étaient en deçà des attentes
• o3 fonctionne assez bien en raisonnement sur le code, questions-réponses, programmation et résolution de problèmes pour améliorer les performances d’un chercheur réel en vulnérabilités
• Il reste imparfait et risque fortement de générer des résultats sans intérêt qui frustrent l’utilisateur
• Ce qui a changé, c’est que la probabilité d’obtenir une bonne réponse est jugée, pour la première fois, suffisamment élevée pour tenter l’application à de vrais problèmes

[GN⁺]

Avis sur Hacker News

• C’est un détail, mais la façon dont l’auteur structure son projet semble utile. Il crée des fichiers .prompt distincts pour le prompt système, le contexte et les instructions auxiliaires [1], puis les exécute avec llm
  Cela montre qu’une bonne utilisation des LLM, comme les autres outils d’ingénierie, nécessite une approche méthodique et une réflexion d’ingénierie centrée sur des spécifications réfléchies, tenant compte de manière équilibrée des contraintes de conception
  [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

  • C’est amusant de le voir ainsi, puisque l’auteur reconnaît justement avoir fait cette partie-là au feeling

    In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

  • Je ne sais pas comment il faudrait benchmarker ces différentes méthodologies
    Tout ressemble à des incantations fondées sur l’intuition. Des formulations comme « Vous êtes un expert en détection de vulnérabilités », « Ne signalez que de vraies vulnérabilités, sans faux positifs », ou encore l’organisation avec de fausses balises HTML parce que le modèle semble aimer ça. Je ne vois pas où se trouve l’ingénierie là-dedans
  • Il est intéressant de voir des gens appliquer des principes d’ingénierie à des systèmes intrinsèquement instables et imprévisibles pour obtenir un sentiment de contrôle
    Ces prompts devraient être appelés des indices, pas des instructions. Tous les LLM actuels ignorent le prompt dès qu’il entre en conflit avec leur unique objectif supérieur : produire une réponse, qu’elle soit vraie ou non
  • Ce qui est amusant, c’est que si l’on demande à un LLM les bonnes pratiques de structuration de prompts, il donne des indications dans ce sens
    Demander à un LLM de vous aider à rédiger des prompts est aussi étonnamment efficace. Tous mes fragments de prompts ont été conçus avec l’aide d’un LLM
    Personnellement, je mets tout dans des fichiers org-mode et je copie-colle dans une conversation ChatGPT quand j’en ai besoin. Je préfère des interactions plus « conversationnelles », mais l’approche est la même
  • Au final, l’essentiel, c’est le rangement : https://taoofmac.com/space/blog/2025/05/13/2230

• L’article dit que le rapport signal/bruit est d’environ 1:50. L’auteur connaît très bien cette base de code, ce qui le place dans une bonne position pour distinguer le signal au milieu du bruit
  Le vrai progrès viendra de l’automatisation de cette partie, donc je vais continuer à suivre ça

  • Pendant quelques années, j’ai créé plusieurs exercices d’entretien à faire chez soi, conçus pour être courts et faciles pour un développeur expérimenté, mais difficiles si l’on ne connaît pas le langage. Ils étaient tous issus de problèmes réels que j’avais résolus au travail, réduits à leur forme minimale
    À chaque nouveau LLM de pointe, en excluant les modèles qui utilisent les entrées comme données d’entraînement, je leur fais passer ces exercices. J’ai été surpris de voir que la proportion de réponses fonctionnelles au premier essai reste constamment autour de 1:10, et qu’il faut souvent plus de 10 tours pour lui faire trouver ses propres erreurs
    Donc ce rapport signal/bruit sur un sujet plus obscur me paraît plausible
  • Je construis un système qui augmente fortement le rapport signal/bruit dans la détection de bugs, tout en ayant benchmarké de manière approfondie les agents logiciels connus en général
    Les résultats varient pas mal, et je publierai tout lors d’une prochaine présentation en conférence, donc vous pouvez vous y attendre. Cela donnera une assez bonne image de l’état actuel du domaine
    Modification : la formulation était confuse
  • Je me suis demandé récemment s’il ne serait pas possible de faire une sorte de fine-tuning sur tous les changements git du noyau Linux, les listes de diffusion, etc.
    Un tel LLM ne serait-il pas une version synthétique assez proche de quelqu’un qui a travaillé pendant des années sur la base de code et en a appris toutes les particularités ?
    On peut vraiment mettre énormément de choses dans un long contexte, mais certaines bases de code font déjà 200 000 tokens rien qu’avec le code, donc je ne sais pas trop
  • L’automatisation de cette partie me paraît simple. En général, un LLM doté d’une capacité sémantique X pour accomplir une tâche a une capacité supérieure à X pour déterminer, parmi N réponses à cette même tâche, laquelle est la meilleure
    C’est d’autant plus vrai avec une approche de tournoi binaire, comme RAInk qui a été présenté ici il y a quelques semaines, et il existe aussi des méthodes utilisant le consensus entre différents LLM. Je suis surpris qu’ils n’aient pas utilisé Gemini 2.5 PRO ici : d’après mon expérience, c’est le LLM le plus puissant pour ce type de travail
  • 1:50 est un excellent taux de détection pour chercher une aiguille dans une botte de foin

• Le point le plus intéressant et important de cet article, c’est que l’auteur a lancé 100 recherches de vulnérabilités pour chaque modèle
  C’est bien plus de calcul que ce que j’avais prévu d’utiliser pour la plupart des problèmes que j’ai essayés avec de grands modèles de langage, mais peut-être faut-il simplement laisser tourner le modèle encore et encore

  • Je me rends compte que je ne l’ai pas écrit dans l’article, mais si cela vous intéresse, exécuter 100 fois la version à 100 000 tokens a coûté environ 116 dollars
  • Les zero-days peuvent se vendre très cher, et les bug bounties peuvent aussi rapporter. Le coût des LLM est probablement une goutte d’eau dans l’océan en comparaison
    Je ne sais pas à quoi ressemblera le monde de la cybersécurité quand le coût d’inférence sera proche de zéro, mais ce sera un espace très différent de celui d’aujourd’hui
  • Il suffit d’avoir assez d’argent~
  • « 100 fois par modèle » implique une consommation d’énergie considérable. Le fait d’avoir trouvé la vulnérabilité la plus courante dans une base de code en C rend le résultat moins impressionnant
    Cela revient plutôt à célébrer le luxe et le gaspillage. Alors même que nous faisons face au changement climatique mondial, nous continuons à brûler des ressources pour des choses triviales comme dans les années 1950

• Soit j’ai eu beaucoup de chance, soit, comme je le soupçonnais, Gemini 2.5 PRO semble trouver cette vulnérabilité plus facilement. Le taux de réussite étant élevé, il a suffi de lancer quelques fois le prompt suivant : https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

• Ce schéma se répète souvent ces derniers temps
  Quand il existe un problème avec une définition claire et une fonction d’évaluation, on laisse le LLM réduire l’espace des solutions. Les LLM sont très forts pour reconstruire des motifs, et si la réponse ressemble à un motif déjà connu, cela peut bien fonctionner
  Ici, le problème est un type précis de vulnérabilité de sécurité, et l’évaluateur est un expert. Même si l’échelle est différente, c’est assez proche, dans l’esprit, des tentatives récentes d’utiliser les LLM pour de l’optimisation génétique
  « Mathematical discoveries from program search with large language models » est aussi une lecture intéressante, et il me semble que c’était déjà passé sur HN
  https://www.nature.com/articles/s41586-023-06924-6
  Cela dit, conclure que les LLM raisonnent sur le code sur la seule base de cette expérience me paraît personnellement un peu excessif

• J’espère que c’est vrai, et que ce n’est pas le même genre d’histoire que ce qui arrive sans cesse avec curl
  [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

• Je ne suis pas convaincu par l’affirmation selon laquelle ce serait la première vulnérabilité découverte par un LLM. Par exemple, OSS-Fuzz [0] en a trouvé quelques-unes par fuzzing, et Big Sleep en a aussi trouvé via une approche par agent [1]
  [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
  [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

  • Ce n’est clairement pas la première vulnérabilité découverte par un LLM =) J’aurais peut-être dû formuler ça plus précisément
    Ce que disait l’article, c’était : « Pour comprendre la vulnérabilité, il faut raisonner sur des connexions simultanées au serveur et sur la manière dont plusieurs objets sont partagés dans certaines situations. o3 a compris cela et a trouvé l’endroit où un objet précis, non compté par référence, est libéré alors qu’il reste accessible depuis un autre thread. À ma connaissance, c’est la première discussion publique d’un LLM trouvant une vulnérabilité de cette nature »
    Ce que je voulais dire, c’est qu’à ma connaissance, c’est la première documentation publique d’un LLM trouvant ce genre de bug : un bug issu d’une quantité non triviale de code et d’un accès concurrent à des ressources partagées. En tout cas, pour moi, c’est un marqueur intéressant des progrès des LLM

• Vu la valeur de la découverte de zero-days, si l’on peut en trouver de manière fiable avec seulement quelques centaines d’appels API, presque tous les services de renseignement du monde vont y consacrer de l’argent
  D’autant plus s’il est possible de fine-tuner les modèles avec de nombreux exemples, et je doute qu’OpenAI et consorts proposent ce genre de chose via une API publique

  • Exact. À cause de l’ingénierie autour du contrôle des sorties, autrement dit de la censure, et des conditions d’utilisation, on crée une incitation à pousser le modèle à trouver des bugs possibles tout en lui interdisant de produire le résultat
    Pour les agences gouvernementales ou d’autres organisations, ces contraintes ne posent évidemment pas problème. Elles ne s’appliquent qu’à tous les autres. Les gens vont donc utiliser d’autres modèles et agents qui n’ont pas ces restrictions
    On peut considérer sans grand risque qu’il existe de nombreuses vulnérabilités dans des logiciels critiques. Désormais, on peut les trouver. Une situation où la théorie des jeux d’une course aux armements s’applique à la sécurité informatique et au hacking va commencer. Et probablement plus tôt qu’on ne le pense

• Je comprends que quelques développeurs du noyau aient « validé » ce bug, mais je me demande si quelqu’un a réellement créé et testé une preuve de concept
  C’est une partie tellement centrale du processus, et pourtant la preuve de concept est totalement absente. Sans preuve de concept, on ne sait pas quels problèmes peuvent survenir en chemin, et on ne peut donc pas juger de l’exploitabilité ni de l’impact. Au moins, l’auteur ne l’a pas qualifié d’exécution de code à distance sans validation
  Mais que se passerait-il s’il existait une pièce du puzzle que l’auteur et les développeurs auraient manquée, ou qu’ils auraient supposé traitée par o3 alors qu’elle se trouvait en réalité hors du contexte d’o3, et qui invaliderait cette vulnérabilité elle-même ?
  Je ne dis pas qu’une telle chose existe, ni que je vais prendre le temps de faire le travail de l’auteur à sa place. Simplement, ce rapport n’est pas entièrement validé et, compte tenu du fait qu’il pourrait devenir un billet de blog influent dans le domaine de la recherche de vulnérabilités par LLM, cela me semble être un précédent dangereux
  Personnellement, je pense qu’il faut appliquer PoC || GTFO plus strictement que jamais à tout rapport de vulnérabilité généré par un modèle
  L’idée qu’o3 est bien meilleur que les modèles précédents ou que les autres modèles actuels reste valable, et la méthodologie est intéressante. Je comprends l’envie et le besoin de formuler les choses ainsi pour attirer l’attention sur un point précis. C’est le problème du clickbait. Mais, s’il vous plaît, il faut faire mieux. Il faut construire une preuve de concept et vérifier les affirmations, pas être paresseux. Si vous écrivez un billet de blog susceptible d’influencer la façon dont les chercheurs en vulnérabilités travaillent, il faut encourager la validation, pas les hypothèses théoriques. Sinon, au lieu d’approfondir la compréhension des systèmes avec des rapports vérifiables et démontrés, des rapports faux mais plausibles propageront l’ignorance

  • Je suis l’auteur. Oui, j’ai créé une preuve de concept. Oui, elle a déclenché un rapport KASAN et un crash
  • Je me demande si vous voulez une preuve de concept qui provoque un crash par use-after-free, ou si seule une preuve de concept complète d’exécution de code à distance vous satisferait

• Il y a un superbe petit passage qui capture parfaitement le déroulement de la plupart de mes sessions de développement de prompts

  I tried to strongly guide it to not report false positives, and to favour not reporting any bugs over reporting false positives. I have no idea if this helps, but I’d like it to help, so here we are. In fact my entire system prompt is speculative in that I haven’t ran a sufficient number of evaluations to determine if it helps or hinders, so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering. Once I have ran those evaluations I’ll let you know.