Fragnesia CVE-2026-46300 : correctifs Linux et preuves du noyau actif

Fragnesia (CVE-2026-46300) est une vulnérabilité d’élévation locale de privilèges dans le noyau Linux. Appliquez les correctifs correspondant à la distribution et à la famille de noyau, puis vérifiez qu’ils sont actifs dans le noyau en cours d’exécution. La description officielle d’Ubuntu signale aussi une possible évasion de conteneur dans les conditions applicables. Utiliser Linux ne signifie pas que tous les systèmes ont la même exposition.

Cela donne-t-il directement les droits root à un attaquant sur Internet ?

Cette CVE est une élévation locale de privilèges. Elle exige que l’attaquant puisse exécuter du code sur le système et atteindre le chemin vulnérable du noyau. Distinguez-la d’une exécution de code à distance dans une application web. Les données KEV officielles de CISA indiquent le risque de l’enchaîner avec PHP2Shell CVE-2026-109618 et CVE-2026-109619. Vérifiez séparément la correction du runtime PHP et celle du noyau de l’hôte.

La fiche CVE d’origine décrit la perte d’un marqueur de fragment de page partagée pendant la fusion de tampons de socket. Un traitement ESP ultérieur peut confondre les pages partagées avec des pages privées et les modifier sur place. La CVE a été publiée le 23 mai 2026 ; CISA l’a ajoutée au KEV le 28 octobre. Ce n’est pas un défaut introduit pour la première fois en octobre. Interprétez l’échéance du 31 octobre du KEV dans le périmètre de la directive applicable, plutôt que comme une échéance universelle de changement pour tous les services.

Quel noyau faut-il mettre à jour ?

Ne réduisez pas le périmètre de correction à une seule CVE isolée. Les notes de l’équipe de sécurité Ubuntu conseillent de livrer ensemble les correctifs associés à CVE-2026-43284. Un autre correctif du chemin de transfert des fragments est aussi suivi sous CVE-2026-43503. CVE-2026-43284 est une entrée distincte de la famille Dirty Frag. Préférez le paquet corrigé complet du fournisseur ; appliquer un commit sélectionné ne prouve pas que la correction est terminée.

Voici une sélection de seuils de correction du paquet source linux d’Ubuntu, vérifiés le 31 octobre 2026. Faites d’abord correspondre le paquet binaire installé à son paquet source et à sa famille de noyau.

Version Ubuntu	Seuil de correction linux
22.04 LTS	5.15.0-181.191
24.04 LTS	6.8.0-124.124
26.04 LTS	7.0.0-22.22

Ne réutilisez pas ces seuils pour les noyaux AWS, Azure, HWE, OEM ou temps réel : noms de paquets, familles prises en charge et rétroportages fournisseurs diffèrent. Pour RHEL, suivez le statut produit et les RHSA liés depuis le bulletin Red Hat. Le bulletin propre à AWS explique le statut non affecté d’Amazon Linux et de Bottlerocket d’après leur configuration espintcp. N’étendez pas cette affirmation à des noyaux personnalisés arbitraires ou à d’autres distributions exécutées sur EC2.

Recueillir d’abord les preuves du noyau actif

Le schéma suit le collecteur ci-dessous. Il nécessite Python 3.10 ou ultérieur. Sur Linux avec dpkg-query, il interroge seulement deux noms de paquets dérivés de la version du noyau actif. Il n’utilise ni réseau, ni privilèges administrateur, ni chargement de modules, ni changement système. Ce n’est ni un détecteur de vulnérabilité ni un verdict d’achèvement de correction. Une preuve manquante n’est jamais présentée comme sûre.

kernel-evidence.py

import json
import platform
import shutil
import subprocess


def collect():
    result = {"patch_status": "not-assessed", "scope": "current-execution-context"}
    if platform.system() != "Linux":
        return {**result, "error": "linux-required"}, 2
    try:
        release = platform.release()
        distro = platform.freedesktop_os_release()
    except OSError:
        return {**result, "error": "os-evidence-unavailable"}, 2
    result.update(running_kernel=release,
                  os={key: distro.get(key) for key in ("ID", "VERSION_ID")}, queries=[])
    command = shutil.which("dpkg-query")
    if not command:
        return {**result, "package_query": "dpkg-query-unavailable"}, 0
    result["package_query"] = "dpkg-query"
    for name in ("linux-image-" + release, "linux-image-unsigned-" + release):
        row = {"package": name}
        try:
            answer = subprocess.run(
                [command, "-W", "-f=${Package}\t${Version}\t${db:Status-Status}\n", name],
                capture_output=True, text=True, timeout=5, check=False)
        except (OSError, subprocess.TimeoutExpired):
            row["state"] = "query-error"
        else:
            fields = answer.stdout.rstrip("\n").split("\t")
            if answer.returncode == 1:
                row["state"] = "not-found"
            elif answer.returncode != 0:
                row["state"] = "query-error"
            elif len(fields) != 3 or fields[0] != name or not fields[1]:
                row["state"] = "unexpected-output"
            elif fields[2] != "installed":
                row["state"] = "not-installed"
            else:
                row.update(state="installed", version=fields[1])
        result["queries"].append(row)
    return result, 0


if __name__ == "__main__":
    evidence, status = collect()
    print(json.dumps(evidence, ensure_ascii=False, indent=2, sort_keys=True))
    raise SystemExit(status)

python3 kernel-evidence.py

Un environnement non Linux ou l’indisponibilité des preuves du système renvoie le code de sortie 2. Même lorsque la collecte Linux se termine, une requête de paquet individuelle peut échouer : lisez package_query et chaque state. Le code de sortie 0 ne prouve pas que la correction est terminée. Ces deux requêtes ne peuvent pas identifier le paquet propriétaire pour les noyaux RPM ou personnalisés.

La sortie suivante a été exécutée et vérifiée avec des entrées synthétiques : Ubuntu 24.04, noyau actif 6.8.0-124-generic, premier paquet installé et second absent. Elle ne provient pas d’un hôte Ubuntu de production. Les contrôles d’exécution reproduisent cette sortie et les branches d’échec de requête ; ils ne testent pas la vulnérabilité réelle du noyau, l’adoption du correctif ou l’exploitation.

{
  "os": {
    "ID": "ubuntu",
    "VERSION_ID": "24.04"
  },
  "package_query": "dpkg-query",
  "patch_status": "not-assessed",
  "queries": [
    {
      "package": "linux-image-6.8.0-124-generic",
      "state": "installed",
      "version": "6.8.0-124.124"
    },
    {
      "package": "linux-image-unsigned-6.8.0-124-generic",
      "state": "not-found"
    }
  ],
  "running_kernel": "6.8.0-124-generic",
  "scope": "current-execution-context"
}

Dans un conteneur, le système et la base de paquets peuvent appartenir au conteneur tandis que le noyau appartient à l’hôte partagé. Recueillez de nouveau les informations via le chemin d’administration de l’hôte ou de la VM. Un paquet de noyau nouvellement installé peut aussi différer du noyau actif. Ce collecteur n’interroge que des noms liés à la version courante ; il n’énumère pas tous les noyaux installés. Il ne vérifie ni signatures des paquets, ni intégrité, ni état du livepatch.

Que vérifier après l’application du correctif ?

1. Faites correspondre distribution, noyau actif et famille de paquets de l’actif à la CVE ou à l’avis de sécurité du fournisseur. Ne comparez pas des versions de familles différentes par une simple comparaison de chaînes.
2. Appliquez les paquets corrigés depuis les dépôts ou images pris en charge, puis remplacez ou redémarrez les nœuds par étapes. Ubuntu USN-8388-1 demande un redémarrage après une mise à jour standard et traite des changements ABI pour les modules tiers du noyau. Si vous vous appuyez uniquement sur le livepatch, vérifiez séparément sa prise en charge et son application réelle pour la CVE et le noyau actif.
3. Recueillez les mêmes preuves après redémarrage, comparez le noyau actif aux preuves de correction du fournisseur, puis vérifiez santé des services, stockage et réseau. Redémarrer seulement un pod Kubernetes ne remplace pas le noyau du nœud.
4. Enquêtez aussi sur un éventuel accès initial et une persistance. Une correction réussie ne prouve pas l’absence d’un webshell existant ou d’identifiants volés.

Si une mise à jour immédiate est impossible, consultez les consignes de mitigation temporaire Ubuntu et celles de votre fournisseur. Les restrictions de modules peuvent entrer en conflit avec des fonctionnalités comme VPN/IPsec ; les chemins déjà chargés ou intégrés au noyau nécessitent une évaluation distincte. L’absence d’un module dans une liste n’établit pas un statut non affecté. Réduire l’exposition et restreindre le code non fiable sont des mesures temporaires, pas des substituts à l’application de paquets corrigés.