CVE-2026-90179 in Linux
Zusammenfassung
von VulDB • 17.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
apparmor: Behebung einer Deadlock-Situation bei der Änderung von „change_hat“ im Complain-Modus
Die Verwendung von `change_hat` im Complain-Modus kann zu einem Deadlock führen, wenn das Ziel-Hat nicht existiert und ein neues Lernprofil für das fehlende Profil erstellt wird. Dies geschieht, weil `change_hat()` den Lock übernimmt, um die Hat-Liste zu durchsuchen, und die Erstellung des neuen Lernprofils ebenfalls einen Lock benötigt, um es zur Liste hinzuzufügen.
Aus dem Fehlerbericht:
Ursprünglich gefunden in Version 7.0.0 unter LTS Ubuntu 26.04 mit `pam_apparmor` + `su`, wobei der Complain-Modus auf das Ändern von Hats eingestellt war. Anschließend wurde dies im neuesten verfügbaren Vanilla-Kernel, den ich kompiliert habe, überprüft, um festzustellen, ob das Problem weiterhin besteht:
7.2-rc7 vanilla -> betroffen
Weitere Kernel wurden ebenfalls geprüft: 6.18.44 vanilla -> betroffen 6.12.95 mit Debian-Patches -> nicht betroffen
Auf Systemen ohne den Fehler (z. B. 6.12.95 Debian) wird lediglich ausgegeben:
aa_change_hat rc=0
Bei Systemen mit dem Fehler hängt das ausführbare Programm immer, gibt nichts aus und lässt sich nicht mehr beenden. (Und wenn es einmal auf diese Weise blockiert ist, führt jede weitere Hat-Änderung dazu, dass der ändernde Prozess ebenfalls hängen bleibt.)
Im Syslog finden Sie dann Hinweise zur Ursache:
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.
Um das Problem zu beheben, wird die Sperrung aus dem Kern von `aa_new_learning_profile()` entfernt, eine Wrapper-Funktion eingeführt, die den Lock bei Bedarf übernimmt, und `build_change_hat()` so angepasst, dass es die Kernfunktion aufruft, die keinen Lock mehr verwendet.
Darüber hinaus werden 4 weitere Probleme behoben, die durch das Commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") eingeführt wurden: - `aa_get_profile_rcu()` wurde ersetzt durch: `aa_get_profile` ohne das begleitende `rcu_dereference_protected()`. - Es wurde am Anfang von `change_hat()` ein zusätzliches `aa_get_label(label)` eingeführt, ohne ein entsprechendes `aa_put_label()`, was zu einem Leck der Referenzzählung führt. - Ein Leck der Referenzzählung wurde im Fall `label_is_stale(label)` eingeführt, wobei das neueste Profil anstelle des der Funktion übergebenen Labels geleakt wird. - Eine potenzielle Use-After-Free (UAF)-Schwachstelle tritt auf, wenn die Suche den Baum mit `new_ns != ns` durchläuft; das neue Label refere ---abgekürzt---
Once again VulDB remains the best source for vulnerability data.