Une · Sécurité · Kubernetes · CRI-O
CVE-2026-92574 : un restore CRI-O peut ignorer le security context du pod
Red Hat a publié l’avis CVE-2026-92574 (score CVSS 3.1 base 8.8 High) : lors d’un restore depuis un checkpoint, CRI-O peut conserver credentials, capacités Linux, bit no_new_privs et état seccomp du checkpoint au lieu d’appliquer le security context demandé pour le pod destination. Versions amont supportées : CRI-O ≥ 1.34 ; OpenShift Container Platform ≥ 4.17. Correctifs ciblés sur les branches 1.34.14 / 1.35.9 / 1.36.6 — appliqués mais pas encore publiés au moment de l’advisory.
Mécanisme : CRIU reconstruit le processus depuis l’archive ; CRI-O n’impose pas alors l’identité et les restrictions du pod cible. Un attaquant qui peut créer un pod à partir d’une image checkpoint malveillante (souvent tirée d’un registry distant — le restore depuis registry est activé par défaut dans les versions concernées) peut faire exécuter le processus restauré avec des privilèges plus larges que la spec Kubernetes. Sur OpenShift, le feature gate ContainerCheckpoint (Tech Preview) n’est pas activé par défaut : les clusters qui ne l’ont pas explicitement allumé restent hors périmètre. Mitigation immédiate côté standalone CRI-O : enable_criu_support = false sous [crio.runtime].
Contexte : LinuxSecurity (22.09) rappelle qu’aucune exploitation active n’est confirmée. Distinguer : faille réelle du chemin restore ; exposition limitée aux environnements où le restore est disponible et où un acteur peut programmer un pod depuis un checkpoint non fiable. Priorité : inventaire des usages checkpoint, restriction RBAC create/update sur pods, allowlist de registries, puis upgrade dès les builds 1.34.14 / 1.35.9 / 1.36.6 (ou équivalent OCP).
Sources : Red Hat — CVE-2026-92574 · CVE.org — CVE-2026-92574 · LinuxSecurity, 22.09.2026
Modèles · OpenAI
GPT-6 Sol et Luna : OpenAI étend la génération 6 à moindre coût API
Mardi 22 septembre, OpenAI a annoncé des mises à jour de Sol et Luna dans la génération GPT-6 (après Astra plus tôt dans le mois). Sol vise le coding et les workflows agentiques ; Luna les tâches à volume — résumés, extraction, questions courtes. TechCrunch relie le lancement à une baisse annoncée du prix API d’environ 50 % face à la série 5.6 Sol/Luna, attribuée par OpenAI au caching et à l’inférence. Docs API : Sol à 2 $ / 10 $ pour 1 M tokens (input/output) ; Luna à 0,10 $ / 0,50 $ — fenêtres de contexte 1 050 000 tokens, max output 128 000.
OpenAI revendique aussi une meilleure factualité (évaluation interne : « environ moitié moins d’erreurs » pour Sol vs prédécesseur) et un taux d’erreur coding plus bas, plus des comparaisons favorables à Anthropic. Distinguer : disponibilité ChatGPT Work / Codex / API et prix documentés = confirmés ; scores de factualité et de coding = claims vendeur, sans benchmark indépendant publié ici. Anthropic a publié Opus 5.5 environ 90 minutes avant, selon TechCrunch.
Sources : TechCrunch, 22.09.2026 · OpenAI Docs — GPT-6 Sol · OpenAI Docs — GPT-6 Luna
Outils · GitHub Copilot
Claude Opus 5.5 disponible dans GitHub Copilot
Changelog GitHub (22.09) : Claude Opus 5.5 d’Anthropic est sélectionnable dans Copilot pour le coding agentique, les tâches longues et le knowledge work. Plans concernés : Pro+, Max, Business et Enterprise. Interfaces : VS Code, Visual Studio, Copilot CLI, coding agent, app GitHub, github.com, Mobile iOS/Android, JetBrains, Xcode, Eclipse. Facturation au list pricing du fournisseur (usage-based).
GitHub indique qu’en tests précoces Opus 5.5 résolvait des tâches de façon comparable à Opus 5 avec nettement moins d’étapes et de tokens, et se reprenait plus vite après erreur multi-étapes — assertions GitHub/Anthropic, pas mesures croisées. Les sorties texte portent un watermark Anthropic (sans coût ni tokens supplémentaires, selon le changelog). Accès Business/Enterprise gérable via la politique modèles ; rollout progressif.
Source : GitHub Changelog, 22.09.2026
Technique · Atelier
kbuild v3 : pourquoi un build noyau reste collé en single-thread — et comment le débloquer
Lorenzo Stoakes (ARM) a envoyé sur la LKML le 17 septembre 2026 la série [PATCH v3 00/20] kbuild: significantly speed up kernel builds. Objectif : réduire les goulets single-thread du pipeline (kbuild, kallsyms, modpost, objtool, rust, gzip). Les gains cités dans la cover letter — jusqu’à ~36 % allmodconfig, ~70 % incrémental, ~90 % noop — sont des mesures auteur sur Threadripper 9980X, EPYC 9754 bi-socket et MacBook M2, avec prérequis (séries modules/objtool voisines, KRUSTFLAGS=-Zthreads=8, pigz). On les traite comme claims de patch, pas comme chiffres universels.
Paralleliser ce qui était sérialisé. Un make -j$(nproc) ne parallélise que les compilations déjà découpées en jobs. Beaucoup d’étapes finales (kallsyms, modpost, finalisation de modules, parties d’objtool, gzip) restaient mono-thread. La série attaque chaque goulot : cache d’objets et depcheck pour les timestamps, cache modpost sur les mismatches de sections, lecture ELF directe au lieu de nm pour kallsyms, sondage toolchain une seule fois.
Modules en *.mod.S plutôt qu’en *.mod.c. Émettre les descripteurs de modules en assembleur plutôt qu’en C réduit d’un facteur ~10 le temps CPU de cette étape (claim cover letter). La finalisation des modules est aussi découpée en lots au lieu de dizaines de milliers de micro-runs. Effet surtout visible sur allmodconfig (énormément de modules).
objtool : hash par section + threads. Remplacement du hash de relocations par un index par section, dimensionnement du hash d’instructions sur le texte, et décodage / résolution de branches en parallèle sur le gros objet (vmlinux.o, étape --link). Moins de travail redondant, moins de contention sur les structures globales.
Rust à côté du C, puis pigz. Après construction de rust/ (toujours en premier), les crates peuvent avancer en parallèle du reste du build C. Dernier patch : si pigz est installé, compression du noyau via une implémentation gzip parallèle branchée sur le jobserver Make (KPGZIP). Un LLM a aidé au profiling et au code ; Stoakes signale audit manuel, Assisted-by, et tests boot/qemu multi-arch.
Leçon Atelier. Accélérer un build, ce n’est pas seulement « monter -j » : c’est inventaire des étapes encore sérialisées, remplacement des formats coûteux (C généré → asm), caches de dépendances, et parallélisme là où les structures de données le permettent (objtool, rust, pigz). Les pourcentages de la cover letter valent pour les machines et configs testées ; reproduire localement avant de décider d’une adoption.
Source : LKML / Openwall — Lorenzo Stoakes (ARM), [PATCH v3 00/20], 17.09.2026
