CVE-2026-90179 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
apparmor: corrige deadlock na alteração de change_hat em modo complain
O uso de `change_hat` quando está no modo complain pode causar um deadlock (bloqueio mútuo) quando o hat não existe e um novo perfil de aprendizado é criado para o perfil ausente. Isso ocorre porque `change_hat()` adquire o lock para pesquisar na lista de hats, e a criação do novo perfil de aprendizado precisa adquirir o mesmo lock para adicioná-lo à lista.
Do relatório do bug:
Originalmente encontrado em 7.0.0 no LTS Ubuntu 26.04 com pam_apparmor + su no modo complain configurado para alterar hats. Depois verificado na versão mais recente do kernel vanilla que compilei para verificar se ainda estava presente:
7.2-rc7 vanilla -> afetado
verifiquei também alguns outros kernels: 6.18.44 vanilla -> afetado 6.12.95 com patches do Debian -> não afetado
Em sistemas sem o bug (por exemplo, 6.12.95 debian) apenas imprime:
aa_change_hat rc=0
Nos sistemas com o bug, o executável sempre trava, não imprime nada e torna-se impossível de ser encerrado. (E uma vez preso dessa forma, isso fará com que qualquer alteração posterior de hat também cause o processo em mudança a ficar travado)
Depois no syslog você pode encontrar indícios da causa:
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.
Para corrigir o problema, remova a aquisição de lock do núcleo da função `aa_new_learning_profile()`, introduza uma função wrapper que adquira o lock quando necessário e faça com que `build_change_hat()` chame a função central que já não adquire mais o lock.
Além disso, corrigem-se 4 outros problemas introduzidos pelo commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") - `aa_get_profile_rcu()` foi substituída por `aa_get_profile` sem a correspondente chamada a `rcu_dereference_protected()`; - um extra `aa_get_label(label)` foi introduzido no início de `change_hat()` sem uma correspondente `aa_put_label()`, causando vazamento na contagem de referências. - Um vazamento na contagem de referências foi introduzido no caso `label_is_stale(label)`, onde o perfil mais recente seria viciado em vez do label passado para a função. - Uma potencial UAF (Use-After-Free) ocorre quando a pesquisa sobe pela árvore com new_ns != ns, e o novo label refere-se... ---truncado---
If you want to get best quality of vulnerability data, you may have to visit VulDB.