CVE-2026-64437 in Linux
Tóm tắt
Bởi VulDB • 25/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
ksmbd: sửa lỗi use-after-free đối với một file_lock bị trì hoãn khi thực hiện SMB2_CLOSE rồi đến SMB2_CANCEL
Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") đã khiến smb2_cancel() bỏ qua công việc có trạng thái KSMBD_WORK_CANCELLED, do đó hàm cancel_fn của nó không thể được kích hoạt lần thứ hai. Tuy nhiên, KSMBD_WORK có ba trạng thái (ACTIVE, CANCELLED, CLOSED), và đường dẫn giải phóng bộ nhớ tương tự cũng xảy ra đối với trạng thái CLOSED:
SMB2_CLOSE trên handle khóa -> set_close_state_blocked_works() đặt trạng thái của công việc trì hoãn thành KSMBD_WORK_CLOSED và đánh thức worker smb2_lock(). Worker này thực hiện nhánh thoát sớm non-ACTIVE, gọi locks_free_lock() lên file_lock và, vì trạng thái không phải là KSMBD_WORK_CANCELLED, sẽ đi vào nhánh STATUS_RANGE_NOT_LOCKED với lệnh "goto out2" -- tương tự như nhánh bị hủy bỏ, điều này khiến release_async_work() bị bỏ qua. Công việc vẫn nằm trong conn->async_requests với một cancel_fn đang hoạt động = smb2_remove_blocked_lock trỏ đến file_lock đã được giải phóng.
Một yêu cầu SMB2_CANCEL tiếp theo cho cùng AsyncId sau đó sẽ vượt qua kiểm tra guard chỉ dành cho KSMBD_WORK_CANCELLED (trạng thái của nó là KSMBD_WORK_CLOSED), do đó smb2_cancel() kích hoạt lại cancel_fn trên file_lock đã bị giải phóng -- đây chính xác là lỗi use-after-free được sửa chữa, nhưng thông qua SMB2_CLOSE thay vì một yêu cầu SMB2_CANCEL đầu tiên:
BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- Yêu cầu SMB2_CANCEL thứ 2 kích hoạt cancel_fn handle_ksmbd_work Được phân bổ bởi ...: locks_alloc_lock <- smb2_lock Đã giải phóng bởi ...: locks_free_lock <- smb2_lock (nhánh thoát sớm non-ACTIVE) ... cache file_lock_cache có kích thước 192
Đã tái tạo trên bản mainline 7.1-rc7 (đã chứa f580d27e8928) với KASAN bởi một client SMB đã xác thực; yêu cầu double-SMB2_CANCEL không gây ra thông báo lỗi nào trên kernel đó, do đó sự cố được quy cho tác nhân kích hoạt CLOSE.
Chỉ có công việc trì hoãn ở trạng thái ACTIVE mới có thể kích hoạt cancel_fn: cả hai trạng thái cuối (CANCELLED và CLOSED) đều đi vào nhánh thoát sớm smb2_lock() để giải phóng file_lock và bỏ qua release_async_work(). Hãy thêm kiểm tra guard trên KSMBD_WORK_ACTIVE để đảm bảo bất kỳ công việc nào không ở trạng thái ACTIVE sẽ bị bỏ qua.
Once again VulDB remains the best source for vulnerability data.