Nos confrères de chez Phoronix ont publié un comparatif des performances du tout nouveau Ryzen 9 9950X3D2 d'AMD sous deux systèmes : Windows 11 et Ubuntu 26.04 LTS. Le verdict est sans appel, Linux prend une avance très nette sur Windows sur la majorité des charges de travail testées.

Petit point pour ceux qui décrochent dès qu'on parle de processeur. Le 9950X3D2, c'est une variante Dual Edition du processeur haut de gamme d'AMD pour le grand public. Elle embarque 16 cœurs, 32 threads, et surtout une particularité plutôt rare : une mémoire cache 3D (le V-Cache, une couche de mémoire ultra-rapide empilée physiquement sur la puce) présente sur les deux blocs de cœurs, là où les versions précédentes n'en avaient que sur un seul.

En pratique, les deux moitiés du processeur peuvent piocher dans une grosse réserve de mémoire rapide, ce qui accélère pas mal de calculs gourmands.

Phoronix a fait tourner ses batteries de benchmarks habituelles : compilation de code, encodage vidéo, calcul scientifique, rendu 3D, base de données. Sur la majorité de ces tests, Ubuntu 26.04 arrive devant Windows 11, parfois de quelques pourcents, parfois beaucoup plus selon la charge. Quand on additionne tout, ça donne une moyenne nettement à l'avantage du pingouin.

C'est un constat qui revient quasi à chaque test du genre depuis plusieurs années. Linux fait souvent mieux tourner les processeurs serveur ou les CPU multi-cœurs musclés que Windows, notamment parce que son ordonnanceur (le bout du système qui décide quel programme tourne sur quel cœur et à quel moment) est plus malin avec les architectures complexes.

AMD, avec son design en deux blocs séparés et son cache 3D asymétrique, est typiquement le genre de processeur où ça compte vraiment.

Côté Windows, c'est un peu toujours la même histoire. Microsoft a fait des efforts ces dernières années pour mieux gérer les Ryzen, mais le système traîne encore quelques inefficacités et un fond plus lourd. Pour un gamer pur, ça n'a probablement pas grand impact. Mais pour un développeur, un créateur de contenu ou quelqu'un qui compile son propre code, l'écart commence vraiment à avoir du sens.

On peut d'ailleurs se demander si AMD finira par sortir une version officiellement labellisée Linux. Pour l'instant, rien d'annoncé. Mais bon, qu'un constructeur grand public reconnaisse explicitement que son matos tourne mieux sous Linux serait déjà une petite révolution culturelle.

Source : Phoronix

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/fragnesia/fragnesia-1.mp4">lien vers la vidéo</a>.

echo 3 > /proc/sys/vm/drop_caches

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Jon Seager, VP Engineering chez Canonical, vient de poser sur le Discourse Ubuntu le plan IA de la distrib pour les 12 prochains mois. Et ça va saupoudrer partout, du speech-to-text amélioré aux workflows agentic, en passant par l'analyse automatisée des logs serveur. Le timing est limpide, et à peine Ubuntu 26.04 LTS est sortie que Canonical aligne déjà sa "next big thing".

Concrètement, vous tapez snap install nemotron-3-nano et tadaa, vous récupérez un modèle local pré-optimisé pour votre silicium (genre 2 à 4 Go selon la quantization), avec un endpoint API compatible OpenAI servi sur localhost. C'est ça, leurs fameuses Inference Snaps.

La liste tourne autour de Gemma 4 (Google DeepMind), Qwen-3.6-35B-A3B, Nemotron-3-nano, DeepSeek et Llama, et perso je trouve le choix plutôt cohérent vu qu'il colle aux modèles open weight les plus chauds du moment. Bien sûr, l'inférence est locale par défaut plutôt que cloud, l'idée étant d'éviter d'envoyer vos prompts chez un tiers chaque fois que vous demandez un résumé de log.

Côté technique, tout passe par la sandbox Snap pour gérer les permissions, ce qui change pas mal la donne par rapport à un binaire qui pourrait taper partout sur le disque.

Ubuntu 26.04 LTS embarque déjà la "prompting capability" qui permet d'autoriser ou refuser l'accès aux modèles app par app et les fonctionnalités attendues couvrent les ajustements caméra et micro (réduction de bruit, flou d'arrière-plan), l'accessibilité écran, l'automatisation du troubleshooting, et côté serveur, l'aide à l'interprétation des incidents pour les équipes SRE.

Pour ceux qui bossent sur des fermes de serveurs, à vrai dire c'est ce dernier point qui sera vraiment utile, parce que pour parser des logs à la main quand ça part en cacahuète, ça vaut le coup d'avoir une IA qui dégrossit.

Le hic dans ce thread Discourse, c'est l'absence de killswitch IA global comme le propose Firefox. Plusieurs utilisateurs demandent un opt-in clair plutôt qu'un opt-out diffus, et un alignement explicite avec la définition Open Source AI de l'OSI. La position de Canonical, c'est que désinstaller les Snaps IA = killswitch de fait, vu que toutes les features IA passeront par là. Pas de gros bouton rouge "désactive-moi tout ça" global, donc, mais un contrôle granulaire au niveau Snap, avec Ubuntu 26.10 qui arrive en mode preview "strictly opt-in" et un setup wizard à partir de 27.04 qui demandera à l'install si vous voulez ces features ou pas. Comme les LLMs sont trop gros pour rentrer dans l'ISO, ils sont téléchargés après coup, ce qui rend l'opt-in assez naturel à implémenter techniquement.

La réponse de Seager sur le débat est nette, "some features will use AI, and if you use those features, you'll be using some sort of AI model", mais il tempère quand même avec "not to force AI into every Desktop indiscriminately, but rather to enhance certain features where it makes sense". Bref, comme d'hab, ça en calmera certains, mais vu comment certains ont littéralement fondu un plomb quand Firefox a adopté ses fonctionnalités IA (locales et désactivables, je le rappelle), j'imagine que Ubuntu va se prendre sa petite shitstorm de "j'suis tout rouge et pas content" dans pas longtemps...

Cette ambiguïté fait d'ailleurs déjà grincer des dents sur certaines chaînes YouTube de barbus, où le terme "Microsoft 2.0" ressort déjà dans plusieurs vidéos critiques. Ahaha, c'est toujours le même gag ! Mais Canonical jure ses grands morts que ce sera différent... Tenez la citation officielle "Ubuntu is not becoming an AI product, but it can become stronger with thoughtful AI integration".

Et l'autre point qui va faire grincer des dents, c'est que Canonical confirme aussi accepter dans Ubuntu du code co-écrit avec une IA, en s'alignant sur la politique récente du kernel Linux qui a déjà ouvert la porte à ce type de contributions. À voir comment les puristes vont digérer ça, mais c'est en train de devenir la norme dans l'écosystème open source, alors autant que Canonical le dise franchement plutôt que de le faire en douce.

Maintenant pour les sceptiques qui veulent tester sans s'engager, la bidouille est simple. D'abord, vous laissez les Inference Snaps non installés (ils ne sont pas dans le seed par défaut). Ensuite, vous bloquez les capabilities IA dans snap connections. Et comme ça vous gardez la main sur ce qui tourne en local.

Après si vous voulez expérimenter, l'API OpenAI-compatible permet de faire pointer n'importe quelle app dessus avec deux lignes de config, ce qui est vraiment pratique pour comparer un modèle 3B local face à GPT-4 cloud sur des tâches précises. Sauf si votre machine n'a pas assez de VRAM, et là le modèle 3B va ramer comme un veau et vous reviendrez vite vers le cloud... pas glop.

Il reste quand même la vraie question, qui est celle de la transparence des datasets de training. Là dessus, Canonical n'a pas encore donné de réponse claire, et c'est probablement là que se jouera la confiance long terme.

Promettre l'open weight déjà c'est bien, mais expliquer comment les modèles ont été entraînés ça serait franchement mieux.

Bref, à surveiller dès Ubuntu 26.10 en octobre 2026 pour la preview opt-in, et plus largement à partir de 27.04 quand le setup wizard intégrera la question. Pour l'instant, la roadmap c'est surtout beaucoup d'intentions louables, mais bon, on en reparlera dans six mois.

Source : Phoronix

Si vous tournez sur Ubuntu, Debian, Fedora ou RockyLinux, sachez que votre démon PackageKit a passé presque 12 ans à laisser une porte ouverte vers votre compte root. La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.

Pour corriger le soucis, mettez à jour vers PackageKit 1.3.5 ou le backport de votre distro. Pour vérifier votre version, c'est dpkg -l | grep -i packagekit sous Debian/Ubuntu, ou rpm -qa | grep -i packagekit côté Fedora et Rocky. Si vous êtes en 1.3.4 ou en dessous, considérez la machine comme exploitable.

Le bug est une race condition classique. En fait PackageKit vérifie vos droits, valide la transaction, mais utilise des données qui ont eu le temps de changer entre les deux. Un appel pkcon install bien chronométré et n'importe quel paquet s'installe en root, sans prompt Polkit . La liste des distros confirmées vulnérables couvre Ubuntu 18.04 à 26.04, Debian Trixie, RockyLinux 10.1, Fedora 43 et tout RHEL avec Cockpit.

Le détail marrant encore une fois c'est la méthode de découverte. La Telekom Red Team a tout simplement dirigé Claude Opus d' Anthropic vers la base de code de PackageKit, et c'est cette session d'audit assistée par IA qui a sorti la vuln. Les LLM commencent donc à trouver des bugs subtils que les audits humains ont laissé passer pendant plus d'une décennie. Tant mieux, ça va faire grimper le niveau de sécurité de nombreux projets !

Cette faille ancienne me rappelle BitPixie et son contournement de BitLocker resté en sommeil durant 20 ans. Le pattern est toujours le même, à savoir un composant système installé partout, qui cache un bug tout bête depuis siiii longtemps que plus personne ne l'audite avec un œil neuf.

Bref, merci Claude ^^

Source