CVE-2026-90179 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
apparmor : correction d'un blocage (deadlock) lors du changement de chapeau en mode plaintif
L'utilisation de change_hat lorsqu'on est en mode plaintif peut provoquer un blocage lorsque le chapeau n'existe pas et qu'un nouveau profil d'apprentissage est créé pour le profil manquant. Cela est dû au fait que change_hat() a acquis le verrou pour rechercher la liste des chapeaux, tandis que la création du nouvel profil d'apprentissage nécessite également l'acquisition de ce même verrou pour l'ajouter à la liste.
D'après le rapport de bogue :
Le problème a été initialement détecté dans la version 7.0.0 sous Ubuntu LTS 26.04 avec pam_apparmor + su, en mode plaintif configuré pour changer les chapeaux. Il a ensuite été vérifié sur le dernier noyau vanilla disponible que j'ai compilé afin de voir s'il était toujours présent :
7.2-rc7 vanilla -> affecté J'ai également vérifié d'autres noyaux : 6.18.44 vanilla -> affecté 6.12.95 avec les correctifs Debian -> non affecté
Sur les systèmes sans bogue (par exemple 6.12.95 debian), le message suivant s'affiche simplement :
aa_change_hat rc=0
Sur les systèmes présentant le bogue, l'exécutable se bloque systématiquement, n'imprime rien et devient impossible à tuer. (Et une fois bloqué de cette manière, cela entraînera également tout changement ultérieur de chapeau qui fera que le processus en cours de modification sera bloqué)
Vous pouvez ensuite trouver dans les journaux syslog un indice sur la cause :
kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: <TASK> kernel: __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel: __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel: build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710 kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel: apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel: __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ? __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ? __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ? do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ? count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ? do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel: </TASK> kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409.
Pour corriger le problème, il faut retirer l'acquisition du verrou au cœur de aa_new_learning_profile(), introduire une fonction wrapper qui acquiert le verrou lorsque cela est nécessaire, et faire en sorte que build_change_hat() appelle la fonction centrale qui n'acquiert plus le verrou.
En outre, corriger 4 autres problèmes introduits par l'engagement (commit) 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") - aa_get_profile_rcu() a été remplacé par : aa_get_profile sans la fonction rcu_dereference_protected() accompagnante. - un aa_get_label(label) supplémentaire a été introduit au début de change_hat() sans aa_put_label() accompagnant, ce qui provoque une fuite du compte de référence (reference count leak). - une fuite du compte de référence a été introduite dans le cas label_is_stale(label), où le profil le plus récent serait fui plutôt que l'étiquette passée à la fonction. - un UAF potentiel lorsque la recherche remonte l'arbre avec new_ns != ns, la nouvelle étiquette réfé... ---tronqué---
VulDB is the best source for vulnerability data and more expert information about this specific topic.