Une faille Linux vieille de 6 ans refait surface, offrant un accès à des fichiers comme /etc/shadow et d'autres fichiers sensibles. L'essentiel à savoir.
Le post Linux : cette dangereuse faille oubliée permet de voler vos clés SSH et lire les fichiers root a été publié sur IT-Connect.
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 :
Connexiongit clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp
Petite subtilité à connaître sur Ubuntu, AppArmor restreint les "user namespaces" (les bacs à sable du kernel) pour les utilisateurs non-privilégiés depuis Ubuntu 24.04. Du coup, avant de lancer l'exploit, faut faire sauter ce verrou de sécurité :
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
Et là vous récupérez un shell root sans crasher le kernel... vous allez voir, c'est presque magique !
⚠️ Attention, après le test, le /usr/bin/su en mémoire est toujours pété (il contient encore le code de l'attaquant). Donc avant de continuer à utiliser la machine, faut nettoyer ce cache mémoire :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, vous rebootez la VM puisque la corruption est uniquement en RAM.
Alors on fait quoi maintenant ?
D'abord, du côté patch, AlmaLinux a déjà sorti des kernels corrigés (kernel-4.18.0-553.124.3.el8_10 pour AL8, kernel-5.14.0-611.54.5.el9_7 pour AL9, et kernel-6.12.0-124.56.3.el10_1 pour AL10). Ensuite, pour les autres distros (Ubuntu, Debian, RHEL, SUSE, Fedora, Gentoo, Amazon Linux, CloudLinux), c'est en cours, mais pas encore disponible partout à l'heure où j'écris ces lignes.
En attendant, la mitigation est exactement la même que pour Dirty Frag, ce qui est plutôt cool, et même pratique, si vous l'aviez déjà appliquée la semaine dernière (rien à refaire, vous êtes déjà protégé contre la nouvelle bête, c'est cadeau). Si ce n'est pas le cas, voici la commande à coller en root, à exécuter sur chaque machine concernée :
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"
Cette ligne bloque les trois modules vulnérables (esp4, esp6 et rxrpc) pour qu'ils ne se rechargent pas au reboot, les décharge s'ils tournent déjà, et nettoie le cache mémoire au cas où il serait déjà corrompu.
Pour rappel, ces trois modules ne servent qu'à du VPN IPsec en mode transport et à un protocole réseau exotique d'Andrew File System. Du coup, 99% des desktops et serveurs classiques ne perdent rien à les désactiver. Si vous opérez du VPN IPsec en prod par contre, là attention, faudra attendre le patch officiel de votre distro et bricoler une rotation de modules en attendant.
Une fois que votre distro pousse le patch officiel (espérons que ce sera très bientôt côté Ubuntu et Debian), vous mettez à jour le noyau, vous rebootez la bécane, et vous retirez tranquillement la conf de modprobe.
Source : github.com/v12-security/pocs
Fragnesia (CVE-2026-46300), c'est le nom de la nouvelle faille critique offrant un accès root sur Linux ! L'essentiel à savoir sur ce nouvel exploit universel.
Le post Fragnesia : cette nouvelle faille dans le noyau Linux offre un accès root a été publié sur IT-Connect.
À quelques semaines du lancement de KDE Plasma 6.7, le projet KDE publie une mise à jour corrective estampillée KDE Plasma 6.6.5. Elle se focalise principalement sur plusieurs problèmes importants apparus récemment, notamment autours des pilotes graphiques NVIDIA 595. Des corrections de bugs Cette mise à jour se concentre avant tout sur la stabilité, les …
Cet article KDE 6.6.5 corrige des bugs gênants avant l’arrivée de Plasma 6.7 a été publié en premier par GinjFo.
OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.
ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.
La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.
C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.
Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.
Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.
Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.
Source : Phoronix
Un kill switch dans le noyau Linux pourrait désactiver des fonctions vulnérables, renforçant la sécurité en attendant un correctif pour une faille de sécurité.
Le post CopyFail, Dirty Frag : un mainteneur propose d’ajouter un kill switch à Linux a été publié sur IT-Connect.
L'adhésion de Lenovo et Dell au Linux Vendor Firmware Service est un nouveau signal positif aux utilisateurs de Linux envoyé par deux géants du PC.
Le post Linux : Dell et Lenovo rejoignent le projet Linux Vendor Firmware Service a été publié sur IT-Connect.
Alerte Zero-Day : la faille critique Dirty Frag permet d'obtenir les droits root sur Linux. Les patchs sont en attente : voici comment se protéger.
Le post Dirty Frag : cette faille zero-day donne les droits root sur Linux a été publié sur IT-Connect.
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
Ubuntu ne démarre plus, reste bloqué au démarrage ou affiche une erreur GRUB ?
Avant de réinstaller complètement Linux, plusieurs méthodes permettent souvent de réparer Ubuntu sans formater et perdre ses fichiers.
Selon le problème rencontré, vous pouvez :
fsckDans la majorité des cas, les documents du dossier /home peuvent être conservés pendant la réparation du système Linux.
Dans ce guide complet, vous trouverez les différentes méthodes pour réparer Ubuntu et retrouver un système fonctionnel sans formater entièrement le PC.
Dans de nombreux cas, il est possible de réparer Ubuntu sans formater Linux ni supprimer les fichiers personnels.
Cette solution est particulièrement utile lorsque :
L’objectif est alors de :
Dans la majorité des cas, les fichiers du dossier /home restent intacts pendant les réparations.
Si Ubuntu ne démarre plus, commencez par utiliser le mode recovery :
Pour réparer GRUB et le démarrage Linux :
Plusieurs méthodes de réparation d’Ubuntu sont présentées dans ce guide.
Consultez le tableau ci-dessous pour utiliser la bonne méthode en fonction des problèmes rencontrés.
| Problème Ubuntu | Méthode recommandée |
|---|---|
| Ubuntu démarre encore partiellement | Mode recovery Ubuntu |
| Ubuntu reste bloqué au démarrage | Vérifier le disque avec fsck |
Erreur grub rescue> | Réparer GRUB |
| Ubuntu ne démarre plus du tout | Live USB Ubuntu |
| Mise à jour Ubuntu cassée | Réparer les paquets avec dpkg |
| Mot de passe oublié | Réinitialiser le mot de passe Ubuntu |
| Système fortement corrompu | Réinstaller Ubuntu sans perte de données |
| Fichiers importants à récupérer | Sauvegarder Linux avec un Live USB |
Avant toute réparation importante d’Ubuntu, il est fortement conseillé de sauvegarder les fichiers importants afin d’éviter une perte de données en cas d’erreur ou de corruption du système Linux.
Même si les méthodes de réparation présentées dans ce guide sont conçues pour conserver les données personnelles, un problème disque ou une mauvaise manipulation peut toujours survenir.
Les fichiers les plus importants se trouvent généralement dans le dossier :
/homePensez notamment à sauvegarder :
Le plus simple consiste à utiliser un Live USB Ubuntu afin d’accéder aux partitions Linux et copier les fichiers vers :
Pour créer une clé USB bootable :
Pour accéder au mode rescue avec un Live USB :
/homeVous pouvez aussi utiliser le terminal Linux pour sauvegarder les données.
Par exemple :
cp -r /home/utilisateur/Documents /media/ubuntu/DisqueUSB/Si le disque Linux présente des erreurs ou des signes de défaillance :
fsck Vérifier l’état du disque sous Linux :
Une corruption du système de fichiers Linux ou un problème disque peut empêcher Ubuntu de démarrer correctement.
Les symptômes les plus fréquents sont :
fsckAvant de réinstaller Ubuntu, il est conseillé de vérifier :
Depuis le mode recovery Ubuntu ou un Live USB, ouvrez un terminal puis affichez les partitions Linux :
lsblk -fOu :
sudo fdisk -lCes commandes permettent de :
Plus d’aide dans leur utilisation :
La commande fsck permet de détecter et corriger les erreurs du système de fichiers Linux.
Par exemple :
sudo fsck -f /dev/sda2Remplacez /dev/sda2 par votre partition Ubuntu.
fsck peut corriger :
Guide complet :
Si Ubuntu plante régulièrement ou refuse de démarrer, le disque peut être défaillant.
Vous pouvez vérifier l’état SMART du disque avec smartctl.
Par exemple :
sudo apt install -y smartmontools
sudo smartctl -a /dev/sdaCette commande permet de :
Voir aussi :
Un disque saturé peut aussi empêcher Ubuntu de fonctionner correctement.
Depuis le terminal Linux :
df -hCela permet de vérifier :
Si la partition / est saturée :
/var/logAidez-vous de ce guide complet :
Ubuntu intègre un mode recovery accessible depuis GRUB qui permet de réparer Linux lorsqu’il ne démarre plus correctement.
Le mode recovery Ubuntu permet notamment :
fsckC’est généralement la première méthode à utiliser lorsque :
Lorsque Ubuntu est fortement corrompu ou instable, il est parfois possible de réinitialiser le système sans supprimer les fichiers personnels. L’objectif est de : Cette méthode peut être utile lorsque : Dans certains cas, une simple réparation des paquets Ubuntu suffit : Si Ubuntu reste inutilisable, vous pouvez envisager : Si Ubuntu ne démarre plus malgré les réparations, vous pouvez réinstaller le système Linux sans forcément supprimer les fichiers personnels. Le principe consiste à : Cette méthode permet souvent de : Cette option permet généralement : C’est la méthode la plus simple et recommandée pour la majorité des utilisateurs. Si vous utilisez : Vous pouvez choisir : Partitionnement manuelle Cette option permet : Dans ce cas : Attention : être fortement corrompu ou le problème être matériel. Dans cette situation, il est important : Le tableau ci-dessous permet d’identifier rapidement la méthode à utiliser selon la situation rencontrée. Oui, dans la majorité des cas il est possible de réparer Ubuntu sans supprimer les fichiers personnels. Non, le mode recovery Ubuntu sert uniquement à dépanner Linux. Oui, un Live USB Ubuntu permet souvent de réparer un système Linux qui ne démarre plus. GRUB peut être réparé : Oui, Ubuntu peut être réinstallé sans supprimer les données personnelles. Le message Oui, même si Ubuntu ne démarre plus, les fichiers restent souvent accessibles depuis un Live USB Linux. L’article Réparer Ubuntu sans perte de données : le guide complet est apparu en premier sur malekal.com. Suivre le guide complet :
Réinitialiser Ubuntu sans supprimer les fichiers personnels
/home
sudo apt --fix-broken install
sudo dpkg --configure -a
/homeRéinstaller Ubuntu sans formater la partition
/home
/home
Créer le Live USB Ubuntu et démarrer dessus
Aidez-vous de ce guide : Comment démarrer l’ordinateur sur clé USB
Utiliser l’option « Réinstaller Ubuntu »
L’option Réinstaller Ubuntu peut ne pas être disponible selon la version d’Ubuntu
Utiliser « Partitionnement manuelle » pour gérer les partitions manuellement
/home séparée
//home sans formatage
//home ne soit pas formatée
Que faire si Ubuntu ne démarre toujours pas
Problème Ubuntu Solution recommandée Ubuntu reste bloqué au démarrage Utiliser le mode recovery Ubuntu Message grub rescue>Réparer GRUB Écran noir après GRUB Utiliser systemd.unit=emergency.targetErreurs EXT4 ou messages fsckVérifier le disque avec fsckUbuntu ne démarre plus du tout Utiliser un Live USB Ubuntu Mise à jour Ubuntu cassée Réparer les paquets avec dpkgMot de passe Ubuntu oublié Réinitialiser le mot de passe Ubuntu Partition Linux inaccessible Monter les partitions avec un Live USB Données importantes à récupérer Sauvegarder Linux avant réparation Ubuntu fortement corrompu Réinstaller Ubuntu sans perte de données Résolvez gratuitement le problème sur le forum du site : FAQ
Peut-on réparer Ubuntu sans perdre ses données ?
Les documents du dossier /home restent généralement conservés lors :
– D’une réparation GRUB
– D’un fsck
– D’une réparation des paquets Linux
– D’une réinstallation Ubuntu sans formatage complet
Il est toutefois recommandé de sauvegarder les données importantes avant toute manipulation.Le mode recovery Ubuntu supprime-t-il les fichiers ?
Il permet notamment :
– Réparer les paquets cassés
– Vérifier le disque avec fsck
– Réparer GRUB
– Ouvrir un terminal root
Les fichiers personnels ne sont normalement pas supprimés. Voir aussi :
Peut-on réparer Ubuntu avec un Live USB ?
Vous pouvez notamment :
– Monter les partitions Linux
– Sauvegarder les fichiers
– Utiliser chroot
– Réinstaller GRUB
Réparer Ubuntu sans démarrer le système installé Utiliser un Live USB Ubuntu :
https://www.malekal.com/utiliser-live-usb-linux-acceder-mode-rescue/Comment réparer GRUB sur Ubuntu ?
– Depuis le mode recovery Ubuntu
– Depuis un Live USB Ubuntu
– Avec grub-install
– Avec update-grub Guide complet : Peut-on réinstaller Ubuntu sans formater le disque ?
Selon les versions Ubuntu :
– L’option « Réinstaller Ubuntu » peut être proposée automatiquement
– Sinon il faut utiliser le partitionnement manuel afin de conserver /home
Attention à ne pas sélectionner :
– « Effacer le disque et installer Ubuntu »Que faire si Ubuntu affiche grub rescue> ? grub rescue> indique généralement :
– Une corruption GRUB
– Une partition Linux introuvable
– Une erreur UEFI
– Un problème disque
Dans ce cas :
– Réparez GRUB
– Vérifiez les partitions Linux
– Lancez un fsck
Utilisez un Live USB Ubuntu si nécessaire Voir aussi : Peut-on récupérer ses fichiers si Ubuntu ne démarre plus ?
Vous pouvez alors :
– Monter les partitions Linux
– Copier les fichiers vers un disque externe
– Sauvegarder le dossier /home
Ressources utiles et articles liés
Omarchy 3.7 tente de gommer les réglages qui découragent les joueurs. Elle réunit Steam, RetroArch, Lutris, Heroic, Moonlight et Xbox Cloud Gaming dans un environnement Arch prêt à l’emploi.
Cet article Omarchy 3.7, Arch Linux se transforme pour le Gaming PC a été publié en premier par GinjFo.
Les patchs pour la CVE-2026-31431, alias CopyFail, sont-ils disponibles pour les distributions Linux : Debian, Ubuntu, RHEL, etc... Voici un récapitulatif.
Le post CopyFail sur Linux : les patchs de sécurité sont-ils disponibles ? a été publié sur IT-Connect.
La distribution AlmaLinux a publié sa version 10.2 Beta nommée "Lavender Lion", et elle fait un truc que la plupart des distros récentes refusent de faire : remettre du support 32-bit dans le système.
Pas un retour total, on s'entend, mais des packages userspace i686 pour faire tourner du logiciel ancien, des pipelines de CI un peu datées et des conteneurs qui dépendent encore de bibliothèques 32-bit. Pas d'ISO d'install i686, ça reste enterré pour de bon. Mais bon, vos vieux binaires repartent sur un x86_64 propre.
C'est intéressant parce que Red Hat a clairement tranché de l'autre côté avec RHEL. Plus de support 32-bit, plus de x86-64-v2 sur la version 10, c'est marche ou crève. AlmaLinux, qui se positionne comme rebuild compatible RHEL, prend un chemin un peu différent en disant : on garde la compat mais on rajoute des trucs qui rendent la vie plus simple aux entreprises avec du legacy à maintenir. Y'en a beaucoup.
Côté nouveautés plus classiques, vous récupérez Python 3.14, PostgreSQL 18, MariaDB 11.8, Ruby 4.0 et PHP 8.4 dans les packages, plus SDL3, libkrun et le tooling FIDO Device Onboard. La beta intègre aussi déjà le patch pour la vulnérabilité Copy Fail (CVE-2026-31431), ce qui veut dire que les équipes d'AlmaLinux suivent vraiment de près les correctifs amont, sans attendre la stable pour les pousser.
Le truc à retenir, c'est qu'AlmaLinux est en train de devenir le RHEL "raisonnable" pour les boîtes qui ont du parc informatique vieillissant.
Pendant que Red Hat optimise pour ses futurs gros clients cloud, AlmaLinux ramasse tous les autres : ceux qui ont encore une appli métier en 32-bit, ceux dont les serveurs ne valident pas x86-64-v3, ceux qui veulent juste que ça marche sans réécrire la moitié de leur stack.
Bref, choisir AlmaLinux plutôt que RHEL ressemble de plus en plus à une décision pragmatique.
Source : Phoronix
AMD a soumis des patchs HDMI 2.1 FRL pour AMDGPU sous Linux. Une avancée majeure pour les GPU Radeon, SteamOS et le jeu en 4K 120 Hz
Cet article AMD débloque enfin HDMI 2.1 sur Linux a été publié en premier par GinjFo.
