Microsoft made WSL containers generally available on September 29, 2026. The feature adds the command-line tool wslc.exe to the Windows Subsystem for Linux (WSL), so you can build and run Linux containers on Windows without Docker Desktop. A container packages an application together with the libraries it needs, so it behaves the same on every machine. Microsoft also added Intune settings and Defender for Endpoint support. This article covers use cases, installation, basic commands, the architecture, the admin controls, and limitations such as missing Compose support.

Source

Canonical has opened the upgrade path from Ubuntu 24.04 LTS to 26.04.1 LTS, with offers rolling out through Update Manager. The rollout follows a delay linked to regressions in Rust-based system tools; users who don’t want to wait can run `sudo do-release-upgrade`.

Source

Les Pays-Bas développent DAWO, un poste de travail souverain sous NixOS déjà testé dans huit communes. De quoi pérenniser des PC incompatibles Windows 11.

Le post DAWO : les Pays-Bas misent sur NixOS pour remplacer Windows 11 et Microsoft a été publié sur IT-Connect.

OpenSSL has fixed a high-severity DTLS bug that could expose fragments of heap memory in plaintext or crash affected applications. The issue, tracked as CVE-2026-84782, affects software that uses OpenSSL for DTLS, including some WebRTC and internet calling setups.

Source

Unknown attackers are moving beyond initial NetScaler compromise and using root access to plant two new payloads, WHIPSHOT and SLAPSHOT, on Citrix ADC and Gateway appliances. The campaign builds on the same ongoing NetScaler exploitation that has already hit organizations across North America and Europe, but now shows how intruders are modifying appliance configs to keep control and pivot deeper into internal networks.

Source

OpenClaw is getting an enterprise edition as Red Hat, Nvidia, OpenAI and others try to make agentic AI acceptable for corporate use. The project, now called OpenClaw Enterprise Edition, is meant to add stronger security, governance and auditability after businesses and security analysts warned that the original tool was too risky to deploy widely.

Source

Researchers have revived Spectre v2 in a new form called Branch Target Reuse, or BTR, and shown it can pry secrets from just-in-time code caches in browsers, language runtimes, and the Linux kernel. The attack abuses stale branch-prediction entries left behind after JIT code is freed and reused, turning them into a speculative execute-after-free primitive that can leak data even when some defenses are enabled.

Source

Nouvelle variante de Spectre v2, l'attaque BTR vise les moteurs JIT et vole le hash du mot de passe root sous Linux en 3 à 5 minutes. Comment se protéger ?

Le post 5 minutes pour voler le hash du mot de passe root sous Linux avec BTR, une variante de Spectre v2 a été publié sur IT-Connect.

A new Spectre v2 variant called Branch Target Reuse, or BTR, can pull a Linux root password hash from memory in just a few minutes on affected Intel systems. Researchers say the flaw abuses stale branch-prediction state left behind when JIT-compiled code is replaced, and fixes have already landed in the Linux kernel.

Source

Submergé par les CVE découvertes grâce à l'IA, Canonical abandonne le cycle 4/2 : Ubuntu recevra un nouveau noyau chaque semaine à partir de fin octobre 2026.

Le post Ubuntu : face à l’explosion des failles, Canonical va publier un nouveau noyau chaque semaine a été publié sur IT-Connect.

The Netherlands is moving from experimentation toward a standardized sovereign workplace as three government IT providers build DAWO, a Linux-based replacement for Windows desktops and proprietary collaboration tools. The pilot now covers eight municipalities, with NixOS selected as the client operating system for reproducible, centrally managed deployments. NixOS is a Linux distribution that defines software, settings, and system components declaratively in configuration files. This lets administrators reproduce the same workstation setup consistently, track changes, and roll back deployments when necessary.

Source

Dave Plummer, auteur du Gestionnaire des tâches de Windows, lance TMOG 1.0 sur Windows 11, Linux et Mac. Voici un premier aperçu de cet outil.

Le post TMOG 1.0 : le créateur du Gestionnaire des tâches lance son outil pour Windows, macOS et Linux a été publié sur IT-Connect.

Meta’s Muse personal AI agent now includes a complete Ubuntu Linux computer for every user, not merely a sandbox for running agent tasks. The free cloud machine expands the service launched with Sentinel guardrails into a general-purpose environment where users can install software, compile code, browse the web, and run arbitrary workloads.

Source

Canonical is moving Ubuntu to weekly kernel releases as AI-assisted bug discovery drives a surge in CVEs. The new cadence replaces separate four-week feature and two-week security schedules with overlapping two-week Stable Release Update cycles.

Source

Specops Device Trust is a cloud-based security product from Specops Software (part of Outpost24) that ties access decisions to user identity and the device's security state. It addresses a specific gap that multi-factor authentication (MFA) alone cannot close: an attacker who steals a session token or login credentials can still access your systems if access decisions are based solely on user identity. The product binds users to enrolled, verified devices and continuously checks device security throughout every session. This article covers how Specops Device Trust works, what it checks, and how to deploy it.

Source

Researchers have disclosed CVE-2026-89775, a critical flaw in the Linux kernel’s ARM64 KVM virtualization code. When nested virtualization is enabled, a guest can read and write freed host memory, creating a potential guest-to-host escape. Administrators should patch to Linux 6.18.51, 7.2.5, or 7.3-rc1, or verify that the experimental nested-virtualization feature is disabled.

Source

Valve publie le code source de Lepton, sa couche de compatibilité pour exécuter des jeux Android sous Linux via Steam.

Le post Valve publie Lepton pour jouer à des jeux Android sous Linux a été publié sur IT-Connect.

Linux 7.3-rc4 moves the kernel development cycle past its midpoint with an unusually large filesystem workload, following rc3’s XFS and SMB-heavy changes. The latest candidate emphasizes NTFS, SMB, and error-path cleanup, while most individual patches remain relatively small.

Source

Un programme se ferme brusquement et le terminal affiche Segmentation fault, parfois traduit par « erreur de segmentation » ? Sous Linux, ce message indique généralement que le processus a tenté d’accéder à une zone mémoire qu’il n’avait pas le droit d’utiliser. Le noyau lui envoie alors le signal SIGSEGV et met fin à son exécution.

Le message seul ne révèle pas la cause. Il faut d’abord identifier précisément l’application concernée, retrouver les événements enregistrés au moment du crash, puis examiner le core dump lorsqu’il existe. Cette démarche permet de différencier un bug de l’application, une bibliothèque incompatible, un pilote défaillant ou, plus rarement, un problème matériel.

Ce guide présente une méthode progressive avec journalctl, dmesg, coredumpctl et GDB. Il s’adresse aux utilisateurs Linux : il n’est pas nécessaire de savoir programmer pour recueillir une trace utile et choisir la bonne correction.

Qu’est-ce qu’une erreur « Segmentation fault » sous Linux ?

Comprendre simplement le signal SIGSEGV

Chaque programme dispose d’un espace mémoire protégé. Il y place son code, ses bibliothèques et les données dont il a besoin. Si le programme tente de lire ou d’écrire à une adresse invalide, le noyau bloque l’opération. Il envoie le signal SIGSEGV, généralement identifié par le numéro 11, puis arrête le processus.

Un segfault concerne donc d’abord un processus. Il ne signifie pas automatiquement que Linux entier est instable. Si l’écran se fige, si la machine redémarre ou si plusieurs services cessent de répondre en même temps, commencez plutôt par le guide consacré aux blocages et plantages généraux de Linux.

Les causes les plus fréquentes

• Un bug dans l’application : une mauvaise gestion de la mémoire peut provoquer un accès invalide. C’est la cause la plus probable lorsqu’un seul programme plante toujours de la même façon.
• Une extension ou un module : un greffon de navigateur, un module Python, un thème ou une extension native peut faire tomber le processus principal.
• Une bibliothèque incompatible : le programme peut charger une version de bibliothèque qui ne correspond pas à celle attendue, notamment après une mise à jour incomplète ou l’installation manuelle d’un logiciel.
• Un paquet ou un fichier corrompu : un binaire endommagé ou des données illisibles peuvent déclencher le crash au lancement ou lors d’une opération précise.
• Un pilote : les applications utilisant intensivement le GPU, le son ou un périphérique peuvent planter dans une bibliothèque liée au pilote.
• La mémoire vive : une RAM instable reste possible, mais elle est surtout suspecte lorsque des applications différentes plantent à des endroits variables.

Évitez donc de réinstaller immédiatement le système ou de remplacer la RAM après un seul segfault. Les journaux et la trace d’appels permettent souvent de réduire fortement le champ des causes.

Identifier l’application qui provoque le segfault

Reproduire le plantage et relever le message affiché

Notez l’heure exacte du problème, le nom de l’application et l’action effectuée juste avant sa fermeture. Si le programme possède une commande de lancement, exécutez-la depuis un terminal. Vous verrez ainsi ses messages d’erreur au lieu de constater seulement la disparition de sa fenêtre.

nom-du-programme
echo $?

Le code de sortie ne suffit pas à établir la cause, mais il confirme que le programme ne s’est pas terminé normalement. Ne reproduisez pas plusieurs fois une opération susceptible d’endommager des données. Travaillez sur une copie si le crash survient lors de l’ouverture ou de la conversion d’un fichier important.

Consulter les erreurs avec journalctl

Sur une distribution utilisant systemd, journalctl centralise les événements du système et des services. Commencez par limiter la recherche à la période du crash :

journalctl --since "10 minutes ago"
journalctl -b --grep='segfault|segmentation fault|SIGSEGV'

L’option -b limite la sortie au démarrage actuel. La recherche avec --grep nécessite une version relativement récente de systemd. Si elle n’est pas reconnue, affichez simplement la période utile puis recherchez le nom du programme dans la sortie.

Pour une application lancée comme service systemd, interrogez directement son unité :

journalctl -u nom-du-service --since "30 minutes ago"

Recherchez notamment le nom de l’exécutable, segfault, SIGSEGV, le signal 11 et le nom d’une bibliothèque se terminant par .so. Conservez plusieurs lignes avant et après l’événement afin de ne pas perdre son contexte.

Le guide complet :

Examiner les messages du noyau avec dmesg

Le noyau peut lui aussi enregistrer le processus fautif, l’adresse mémoire et la bibliothèque impliquée. La commande suivante rend les dates plus lisibles et filtre les événements courants :

sudo dmesg --ctime | grep -i -E 'segfault|general protection|trap'

Selon la politique de sécurité de la distribution, la lecture de dmesg peut être réservée à l’administrateur, d’où l’emploi de sudo. Une ligne mentionnant toujours le même exécutable ou la même bibliothèque oriente vers un défaut logiciel reproductible. Des processus très différents, des adresses changeantes et d’autres erreurs matérielles justifient une vérification plus large.

Le tutoriel complet d’utilisation :

Retrouver et examiner un core dump

Lister les plantages avec coredumpctl

Un core dump est un instantané de la mémoire et de l’état du processus au moment de son arrêt. Lorsqu’il est géré par systemd-coredump, coredumpctl permet de retrouver les crashes sans chercher manuellement un fichier core.

Selon la distribution, systemd-coredump peut être absent ou désactivé. L’absence de résultat avec coredumpctl ne signifie donc pas qu’aucun segfault ne s’est produit.

coredumpctl list
coredumpctl list nom-du-programme
coredumpctl -1 info

La liste indique notamment la date, le PID, le signal, le chemin de l’exécutable et l’état du core dump. Dans la colonne correspondante, present signifie que le fichier est encore accessible. missing indique que son entrée existe toujours dans le journal mais que le fichier a été supprimé. truncated signale un enregistrement incomplet.

Pour éviter d’analyser le mauvais crash, utilisez le PID affiché ou le chemin complet de l’exécutable :

coredumpctl info 12345
coredumpctl info /chemin/vers/le-programme

Que faire lorsqu’aucun core dump n’est disponible ?

L’absence de résultat ne prouve pas l’absence de segfault. Le stockage peut être désactivé, le fichier peut avoir expiré, votre compte peut ne pas avoir les droits nécessaires ou la distribution peut ne pas utiliser systemd-coredump. Vérifiez d’abord la limite appliquée au shell et la destination configurée par le noyau :

ulimit -c
cat /proc/sys/kernel/core_pattern

Une limite égale à 0 interdit la création d’un core dump pour les programmes lancés depuis ce shell. Pour un test ponctuel, vous pouvez ouvrir un nouveau terminal, autoriser les core dumps dans cette session, puis lancer l’application depuis ce même terminal :

ulimit -c unlimited
nom-du-programme

Cette modification concerne la session et les processus qu’elle lance ; elle ne constitue pas une configuration permanente de tout le système. Un core dump peut contenir des données présentes dans la mémoire de l’application, par exemple des documents, des URL ou des jetons de session. Ne le publiez pas tel quel sur un forum ou un gestionnaire de bugs.

Analyser le segfault avec GDB

Installer GDB et ouvrir le core dump

GDB est un débogueur, mais quelques commandes suffisent pour obtenir une trace utile sans modifier le programme. Installez-le avec le gestionnaire de paquets de votre distribution :

# Debian, Ubuntu et dérivées
sudo apt install gdb

# Fedora
sudo dnf install gdb

# Arch Linux et dérivées
sudo pacman -S gdb

Avec systemd, le moyen le plus simple consiste à demander à coredumpctl d’ouvrir le dernier crash correspondant :

coredumpctl debug nom-du-programme

Si plusieurs entrées portent ce nom, utilisez le PID relevé précédemment. GDB charge alors l’exécutable et le core dump associés. Pour un core dump conservé manuellement, la syntaxe générale est :

gdb /chemin/vers/le-programme /chemin/vers/le-fichier-core

Générer une trace avec backtrace

Lorsque l’invite (gdb) apparaît, lancez la commande backtrace, abrégée en bt :

bt
thread apply all bt
quit

La première commande affiche la pile d’appels du thread qui a planté. La seconde affiche la trace de tous les threads ; elle est utile pour les applications multithreadées. Chaque ligne représente une fonction appelée avant le crash. La trame #0 correspond au point où l’exécution s’est arrêtée, puis #1, #2 et les suivantes remontent la chaîne des appels.

Si la sortie contient principalement des adresses hexadécimales, des points d’interrogation ou la mention no debugging symbols found, les symboles de débogage manquent. Le core dump reste valide, mais la trace sera moins parlante. Les paquets de symboles portent des noms différents selon la distribution ; recherchez ceux de l’application et de la bibliothèque citée dans les premières trames.

Repérer l’application ou la bibliothèque en cause

Ne concluez pas automatiquement que la fonction affichée en #0 contient le bug. Elle peut avoir reçu des données invalides d’un appel précédent. Pour un utilisateur, l’objectif est surtout d’identifier un motif :

• le nom de l’application revient dans les premières trames : cherchez une mise à jour ou un rapport de bug correspondant à cette version ;
• une extension ou un module tiers apparaît : désactivez-le temporairement et refaites le test ;
• une bibliothèque graphique ou un pilote revient systématiquement : comparez avec les dernières mises à jour du pilote et testez, si l’application le permet, sans accélération matérielle ;
• la trace change à chaque crash et plusieurs logiciels sont concernés : examinez la mémoire et le matériel avant d’accuser une application précise.

Avant de transmettre la trace, relisez-la et retirez les chemins contenant votre nom d’utilisateur ainsi que toute donnée confidentielle. Conservez toutefois les versions des paquets, le signal, les noms des bibliothèques et les numéros de trame.

Corriger le segfault selon son origine

Mettre à jour ou réinstaller le paquet concerné

Commencez par relever la version du programme, puis installez les mises à jour normales de votre distribution. Évitez de mélanger un paquet officiel avec des bibliothèques copiées manuellement dans /usr/local ou avec une archive téléchargée depuis une autre distribution.

Si le problème touche un seul paquet et persiste après la mise à jour, réinstallez uniquement ce paquet :

# Debian, Ubuntu et dérivées
sudo apt install --reinstall <nom-du-paquet>

# Fedora
sudo dnf reinstall <nom-du-paquet>

# Arch Linux et dérivées
sudo pacman -S <nom-du-paquet>

Une réinstallation remplace les fichiers gérés par le paquet, mais ne supprime généralement pas votre configuration personnelle. Si le crash semble lié au profil utilisateur, renommez son dossier de configuration pour effectuer un essai avec un profil neuf. Gardez l’ancien dossier comme sauvegarde et ne le supprimez qu’après avoir récupéré les données utiles.

Les guides :

Revenir à une version précédente après une régression

Un segfault apparu immédiatement après une mise à jour peut être une régression. Vérifiez l’historique du gestionnaire de paquets et la version signalée dans le core dump. Si votre distribution fournit encore la version précédente, un retour temporaire peut confirmer le diagnostic.

Ne téléchargez pas au hasard une ancienne bibliothèque depuis un site tiers et ne remplacez pas manuellement un fichier système. Une rétrogradation doit rester limitée au paquet concerné, utiliser les dépôts ou le cache de la distribution et être suivie d’une recherche de correctif. Notez la manipulation afin de pouvoir revenir à la version courante.

Vérifier les bibliothèques et les pilotes

Une trace pointant vers une bibliothèque ne prouve pas que celle-ci est seule responsable, mais elle fournit une piste. Comparez son paquet avec la version de l’application et terminez toute mise à jour interrompue. Pour un logiciel installé manuellement, testez si possible la version fournie par la distribution ou un format isolé officiellement proposé par l’éditeur.

Si le crash se produit lors de l’affichage 3D, de la lecture vidéo ou de l’ouverture d’une interface graphique, recherchez le pilote graphique dans journalctl, dmesg et la backtrace. Désactiver provisoirement l’accélération matérielle dans l’application peut servir de test, mais ce contournement ne remplace pas la mise à jour ou la correction du pilote.

Tester la mémoire lorsque plusieurs applications plantent

Une panne de RAM devient crédible lorsque des programmes sans rapport plantent aléatoirement, que les traces varient ou que les journaux contiennent aussi des erreurs matérielles. Vérifiez alors les événements du noyau et suivez une procédure de diagnostic matériel complète. L’article Diagnostiquer le matériel sous Linux en ligne de commandes détaille les contrôles de la mémoire, des disques, du processeur et des températures.

Avant un test prolongé, sauvegardez les données importantes. Si un profil XMP ou EXPO, un overclocking ou un réglage manuel de tension est actif, revenez aux valeurs stables recommandées par le fabricant pour vérifier si les erreurs cessent.

Checklist rapide pour résoudre un segfault

Les commandes à exécuter dans l’ordre

• Notez l’heure, le nom du programme, l’action effectuée et la fréquence du crash.
• Lancez si possible l’application dans un terminal pour récupérer son message d’erreur.
• Consultez la période correspondante avec journalctl --since "10 minutes ago".
• Recherchez les événements du noyau avec sudo dmesg --ctime.
• Listez les crashes avec coredumpctl list, puis ouvrez l’entrée pertinente avec coredumpctl info.
• Si un core dump est disponible, lancez coredumpctl debug, puis bt.
• Mettez à jour ou réinstallez seulement le paquet identifié, puis refaites le test.
• Si plusieurs programmes plantent de façon aléatoire, élargissez le diagnostic à la mémoire, aux pilotes, au stockage et à la stabilité matérielle.

Les informations à conserver pour demander de l’aide

• la distribution Linux, sa version et la version du noyau obtenue avec uname -r ;
• le nom exact et la version de l’application ;
• les étapes permettant de reproduire le crash ;
• les lignes pertinentes de journalctl et dmesg ;
• le signal, le PID et le chemin de l’exécutable indiqués par coredumpctl info ;
• la sortie de bt, nettoyée de toute donnée personnelle ou sensible ;
• la date d’apparition du problème et les mises à jour installées juste avant.

Cette méthode transforme un message très général en diagnostic exploitable. Dans la majorité des cas, la combinaison des journaux, du core dump et de la backtrace permet au minimum d’identifier le composant concerné et d’éviter les corrections radicales sans rapport avec la cause réelle.

L’article Segmentation fault sous Linux : diagnostiquer et corriger un segfault est apparu en premier sur malekal.com.