[gull] Pas mal d'exploits Linux kernel ces temps-ci, que faire?

Tue Sep 8 09:05:17 CEST 2026

Bonjour,

Il y a pas mal d'exploits kernel ces temps-ci. C'est aussi l'effet de l'IA et
un momentané inconvénient du logiciel à source accessible.  Et peut-être
également dû à un kernel bloat (trop de fonctionnalités dans le kernel).

Typiquement, il y a eu une vulnérabilité il y a quelques mois dans du code
kernel de chiffrement, et ils ont découvert que personne ne l'utilisait plus
(cryptsetup et autres utilisant une implémentation en user-space).

La bonne nouvelle est qu'une bonne partie de ces vulnérabilités se trouvent
dans des modules chargeables (en particulier sous Debian et dérivés; attention
sous Red Hat par exemple ce n'était pas toujours le cas), qu'on peut
blacklister et décharger en général.

Ces vulnérabilités sont rarement "remote" -- sauf que les OS Linux sont souvent
utilisés "localement" par des machines virtuelles ou des conteneurs (qui
partagent le kernel avec le host Linux) qui tournent du code pas forcément
audité, et sous contrôle de tiers (cloud).

Comme la réflexion de quel code exécuter quand dans sshd et surtout la
réduction de dépendances sur sshd dans les distributions Linux (éviter
les dépendances injectées notamment par systemd et donc la surface d'attaque),
qui a été faite avec succès (comparez un ldd /usr/sbin/sshd sur bookworm et
trixie, par exemple), il va y avoir du travail pour le kernel.

Avant ce nécessaire travail en amont, le debloating du kernel (par
configuration), par exemple pour des appliances, et ses avantages et
inconvénients a été étudié [1].

En attendant que ça bouge, vous pouvez:

   - recompiler vous-même un kernel comme on le faisait il y a 25 ans avec
     juste les drivers nécessaires (c'est fun, un peu moins fun s'il y a bcp de
     mises à jour concernant du code que vous avez activé): si vous le
     déployez ensuite sur 200 machines, votre temps sera négligeable

        make localmodconfig # crée une config de kernel avec uniquement
                            # les modules chargés actuellement

        (il existe aussi des dépôts tiers avec des kernels légers)

   - restreindre la surface d'attaque de certaines interfaces du kernel (API,
     /dev, etc) avec des outils comme app-armor ou eBPF (complexe)

        c'est l'approche "EDR", soit pour bloquer l'attaquant, soit pour
        le détecter

   - interdire tout chargement de modules, même pour root sans reboot, mais ça
     va compliquer certaines choses (sysctl kernel.modules_disabled=1)

   - désactiver certains sous-systèmes comme ptrace(2) jusqu'au prochain reboot
        sysctl kernel.yama.ptrace_scope=3 # ou 2 si vous utilisez p.ex. lxc
                                          # (root/CAP_SYS_TRACE aura le droit)

Mais ce qui précède est complexe, peut bloquer des fonctionnalités importantes
jusqu'au prochain reboot, etc.

Une solution plus simple que j'ai adoptée est la suivante: un peu après le
démarrage, mais avant le lancement de machines virtuelles ou de conteneurs,
le script suivant se lance:

   #! /bin/bash

   PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

   # adapt for your needs, see also /etc/modules on Debian
   for i in net-pf-16-proto-4-type-2 net-pf-16-proto-4-type-2-6
   do
      modprobe $i
   done

   # root can still change & do it; lxc requires that
   sysctl kernel.yama.ptrace_scope=2

   # better than disabling modules since root cannot revert
   echo /usr/local/sbin/fake-modprobe > /proc/sys/kernel/modprobe

   echo "applied RT#1694 kernel security measures"

Le script /usr/local/sbin/fake-modprobe lui, fait ceci:

   #! /bin/bash

   PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

   logger -t $0 -p user.warn "NOT loading module: $@"
   exit 1

Le principe est donc le suivant:

   - peu après le démarrage, il n'est plus possible de charger des
     modules kernel à la demande (p.ex. en ouvrant
     un fichier de /dev ou en faisant un ioctl(2) spécifique), ni
     de tracer les applications (sauf root réel ou CAP_SYS_TRACE)

   - les tentatives sont logguées dans syslog, l'administrateur les
     voit (indicateur de compromission ou simple information qu'il
     manque peut-être quelque chose)

   - root peut toujours tracer les applications et charger des modules
     au besoin avec modprobe (et les ajouter au for i ou à /etc/modules)

Evidemment, cela ne va pas bloquer toutes les attaques envisageables et cela
n'empêchera pas de devoir mettre à jour, mais peut-être moins urgemment.
Clairement, la grande majorité des vulnérabilités des derniers 6 mois
ont été évitées ainsi (ptrace(2) étant la seule dont je me rappelle où le
work-around était différent).

ATTENTION: cela peut bien entendu limiter les fonctionnalités disponibles,
           je ne le ferais pas sur un Desktop par exemple.  Mais c'est un
           compromis.

Voici un exemple de log:

   2026-09-06T15:15:28.309014+02:00 virtual /usr/local/sbin/fake-modprobe: NOT loading module: -q net-pf-2-proto-132

Sans cette précaution, mon kernel aurait chargé le module sctp.ko (sur demande
d'une application locale y.c. conteneur (*)) et donc un attaquant local aurait
pu faire des ioctl(2)s dessus, et un attaquant distant aurait pu envoyer une
attaque, dans la mesure où il y a une vulnérabilité dans le code. Ah oui, il y
en avait une en août [2].

(*) en théorie, le script ci-dessus peut logguer laquelle
    vu qu'il a accès au PPID -- sinon des outils comme auditd ou
    eBPF/bpftrace peuvent être utilisés

[1] https://dl.acm.org/doi/fullHtml/10.1145/3524301
[2] https://linuxjust4u.com/linux/sctphantom-cve-2026-64564-linux-sctp-kernel-exploit-fix/
    (exploitable uniquement localement y.c. conteneur, pas à distance)

----- Forwarded message from Yuan Tan <yuant at nebusec.ai> -----

Date: Mon, 7 Sep 2026 20:29:16 -0700
From: Yuan Tan <yuant at nebusec.ai>
To: oss-security at lists.openwall.com
Subject: [!DKIM] [oss-security] Linux kernel LPEs: ZcopyReaper (CVE-2026-43502) and 20 more
User-Agent: Mozilla Thunderbird

Hi all,

We found a Linux kernel local privilege escalation vulnerability in the
RDS zerocopy send path, tracked as CVE-2026-43502. We call the exploit
ZcopyReaper.

The vulnerability was introduced in Linux v4.17 and fixed by commit
44b550d88b26. The first mainline release containing the fix was Linux
v7.1-rc3.

We successfully demonstrated local privilege escalation on an openSUSE
system running Linux kernel 6.4.0-150600.23.100.

An unprivileged local user can trigger the vulnerability. The minimal
kernel configuration required to reach the vulnerable path is:

  CONFIG_INET=y
  CONFIG_AIO=y
  CONFIG_RDS=y or m
  CONFIG_RDS_TCP=y or m

When RDS is built as modules, rds.ko and rds_tcp.ko must either be
loaded or be available for automatic loading.

No Linux capabilities are required. CONFIG_USER_NS is not required.
Disabling unprivileged user namespace creation does not mitigate the
vulnerability.

In addition to CVE-2026-43502, there are 20 other Linux bugs that have
been confirmed to be exploitable, with public exploits available:

CVE-2026-80714
CVE-2026-74597
CVE-2026-74581
CVE-2026-74480
CVE-2026-72255
CVE-2026-72137
CVE-2026-68376
CVE-2026-68162
CVE-2026-64560 
CVE-2026-63834
CVE-2026-52933
CVE-2026-52929
CVE-2026-52924 
CVE-2026-52923
CVE-2026-52912
CVE-2026-43502
CVE-2026-43501
CVE-2026-43074 
CVE-2026-43042
CVE-2026-31678
CVE-2026-31659
CVE-2026-23274

These vulnerabilities were identified and exploited by NebuSec's
automatic exploit generation pipeline. The exploits are available at:
https://github.com/NebuSec/CyberMeowfia/blob/main/security-research