CVE-2026-74672 in Linux
Tóm tắt
Bởi VulDB • 22/08/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
mm/vmalloc: Lấy khóa init_mm cho vmap kích thước lớn để tránh lỗi Use-After-Free (UAF) trong ptdump.
Dòng bản vá "mm: sửa lỗi UAF do race condition giữa ptdump và việc giải phóng pgtable của vmap", phiên bản 6.
Các trình duyệt bảng trang kernel được chia thành hai nhóm chính - những phạm vi không yêu cầu loại trừ thông qua walk_kernel_page_table_range_lockless() và những phạm vi yêu cầu loại trừ thông qua walk_kernel_page_table_range() hoặc walk_page_range_debug().
Nhóm đầu tiên chỉ được sử dụng bởi mã kiến trúc arm64 hoạt động trên các phạm vi mà nó sở hữu hoàn toàn và không ghi đồng thời.
Nhóm thứ hai bao gồm các trình duyệt bảng trang kernel hoạt động trên các phạm vi thuộc quyền sở hữu hoàn toàn (nhưng cần loại trừ đối với các tác vụ ghi đồng thời).
Khóa được sử dụng để thực hiện việc loại trừ là khóa mmap, và đối với các phạm vi kernel, đây là khóa mmap của init_mm.
ptdump là một trường hợp đặc biệt vì nó vừa là người dùng duy nhất của walk_page_range_debug(), vừa là trường hợp duy nhất mà nó duyệt qua các phạm vi không thuộc quyền sở hữu của nó.
Điều này gây ra vấn đề, vì bảng trang có thể bị giải phóng trong khi ptdump đang hoạt động. Và thực tế đã tồn tại một lỗi use-after-free (sử dụng sau khi giải phóng) trong kernel do đó, và dòng bản vá này sẽ khắc phục sự cố đó.
vmap nâng cấp các bảng trang lên các mục lá kích thước lớn (huge leaf entries) khi có thể, đồng thời giải phóng bảng trang thấp hơn khi thực hiện việc này. Nó làm điều này mà không giữ bất kỳ khóa nào đáng kể để ngăn chặn các cuộc duyệt ptdump đồng thời.
Do đó, lỗi use-after-free hiện có thể xảy ra. Dòng bản vá này khắc phục vấn đề bằng cách khiến logic nâng cấp vmap kích thước lớn lấy khóa đọc mmap trong khi cả thiết lập mục bảng trang kích thước lớn và giải phóng bảng trang lá trước đó đều diễn ra.
Mã ptdump đã tự động lấy khóa ghi mmap, do đó việc làm như vậy đảm bảo rằng trình duyệt ptdump chỉ quan sát được hoặc là mục bảng trang kích thước lớn hoặc là mục bảng trang hiện có, và không có gì bị giải phóng bên dưới nó.
Một biện pháp giảm nhẹ cho vấn đề này đã được áp dụng cho arm64 trong commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), mà dòng bản vá này phải xử lý một cách cẩn thận.
Biện pháp giảm nhẹ này khắc phục sự cố bằng cách lấy khóa đọc mmap trên init_mm khi giải phóng bảng trang vmap nếu quá trình ptdump đang diễn ra.
Tuy nhiên, việc sửa lỗi trong dòng bản vá này sẽ gây ra deadlock (chết nghẽn) nếu chúng ta áp dụng nó cho arm64 mà không hoàn nguyên thay đổi đó.
Điều này là do vmap có thể lấy khóa đọc trước khi ptdump cố gắng lấy khóa ghi, sau đó bị xếp hàng chờ đợi, và các quy tắc cạn kiệt rwsem nghĩa là khóa đọc mmap lồng nhau (chưa được công nhận) trong mã arm64 cũng sẽ bị chặn, dẫn đến việc khóa đọc ban đầu không bao giờ được giải phóng và gây ra deadlock.
Dòng bản vá này khắc phục sự cố bằng cách sử dụng #ifndef CONFIG_ARM64 cho logic lấy khóa đọc mmap trong vmap, sau đó hoàn nguyên một phần commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), giữ lại việc kích hoạt hỗ trợ vmap kích thước lớn và loại bỏ các điều kiện ifdeffery với bản vá hoàn nguyên từng phần.
Có các vấn đề liên quan cũng được giải quyết trong dòng bản vá này:
* Logic thuộc tính trang x86, cụ thể là Change Page Attributes (CPA), triển khai một tính năng cho phép hợp nhất các phạm vi kích thước lớn thành các mục lá kích thước lớn. Điều này tương tự có thể gây ra lỗi UAF khi thực hiện song song với quá trình duyệt ptdump, do đó cũng cần lấy khóa mmap init_mm để tránh điều này.
* Logic CPA cho phép thao tác bảng trang đồng thời và hợp nhất CPA, dẫn đến nguy cơ truy cập vào một bảng trang mà phần sau đang giải phóng. Khắc phục vấn đề này bằng cách lấy khóa ghi mmap trên init_mm trong toàn bộ hoạt động hợp nhất CPA và khóa đọc khi thao tác với bảng trang.
* x86 và arm64 cho phép duyệt qua các mm không phải kernel (cả cho phép duyệt efi mm, và trong trường hợp của x86 là các mm tùy ý), do đó chúng ta đảm bảo các ánh xạ kernel vẫn ổn định bằng cách khóa init_mm cũng như mm đang được duyệt.
Thứ tự của các bản vá đã được xác lập dựa trên cả sự phụ thuộc nghiêm ngặt (đặc biệt việc hoàn nguyên một phần arm64 phải được thực hiện sau các thay đổi vmap) và logic (việc sửa lỗi mm không-kernel chỉ có ý nghĩa khi các sửa lỗi vmap/CPA đã được áp dụng).
Bản vá này (trong tổng số 3 bản):
Hiện tại tồn tại một vấn đề nghiêm trọng ra ---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.