CVE-2026-90179 in Linux
Tóm tắt
Bởi VulDB • 18/09/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
apparmor: sửa lỗi deadlock khi thay đổi hat ở chế độ complain (báo cáo)
Việc sử dụng `change_hat` trong chế độ complain có thể gây ra tình trạng deadlock (chặn nhau chờ khóa) khi hat không tồn tại và một profile học tập mới được tạo cho profile bị thiếu. Nguyên nhân là do hàm `change_hat()` đã lấy khóa để tìm kiếm danh sách hat, trong việc tạo profile học tập mới cần phải lấy cùng khóa đó để thêm nó vào danh sách.
Từ báo cáo lỗi:
Ban đầu phát hiện ở phiên bản 7.0.0 trên Ubuntu LTS 26.04 với pam_apparmor + su khi chế độ complain được đặt thành thay đổi hats (hats). Sau đó đã xác minh lại trên kernel vanilla mới nhất mà tôi tự biên dịch để xem liệu vấn đề còn tồn tại hay không:
- 7.2-rc7 vanilla -> bị ảnh hưởng - Đã kiểm tra thêm một số kernel khác: - 6.18.44 vanilla -> bị ảnh hưởng - 6.12.95 với các bản vá của Debian -> không bị ảnh hưởng
Trên các hệ thống không có lỗi (ví dụ như 6.12.95 debian), nó chỉ in ra:
`aa_change_hat rc=0`
Trên các hệ thống có lỗi, chương trình thực thi luôn bị treo, không in gì và trở nên không thể giết được bằng tín hiệu thông thường. (Và một khi đã mắc kẹt theo cách này, bất kỳ thay đổi hat nào tiếp theo cũng sẽ khiến quá trình đang thay đổi bị chặn).
Sau đó trong syslog bạn có thể tìm thấy manh mối về nguyên nhân:
``` 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. ```
Để khắc phục vấn đề, hãy bỏ việc lấy khóa ra khỏi phần lõi của `aa_new_learning_profile()`, giới thiệu một hàm wrapper sẽ thực hiện việc lấy khóa khi cần thiết, và để cho `build_change_hat()` gọi đến hàm cốt lõi không còn tự động lấy khóa nữa.
Ngoài ra, sửa 4 vấn đề khác do commit `32e92764d6f8d` ("apparmor: grab ns lock and refresh when looking up changehat child profiles") gây ra: - `aa_get_profile_rcu()` đã được thay thế bằng `aa_get_profile` mà không có hàm đi kèm là `rcu_dereference_protected()`. - Một lệnh gọi thêm `aa_get_label(label)` đã được đưa vào đầu hàm `change_hat()` nhưng thiếu lệnh tương ứng là `aa_put_label()`, gây ra rò rỉ bộ đếm tham chiếu (reference count leak). - Một lỗi rò rỉ bộ đếm tham chiếu đã xuất hiện trong trường hợp `label_is_stale(label)`, nơi profile mới nhất bị rò rỉ thay vì label được truyền vào hàm. - Một tình trạng UAF (Use-After-Free - Sử dụng sau khi giải phóng tiềm ẩn) có thể xảy ra khi quá trình tìm kiếm duyệt lên cây với điều kiện `new_ns != ns` và nhãn mới không còn hợp lệ... ---truncated---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.