CVE-2026-93202 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:
i3c: master: Sửa lỗi khóa đệ quy trong quá trình đăng ký thiết bị
Hàm `i3c_master_register_new_i3c_devs()` đăng ký các thiết bị mới được phát hiện trong khi đang giữ `i3c_bus_normaluse_lock()`, một mutex đọc (down_read). Hàm `device_register()` có thể ngay lập tức thực hiện probe cho thiết bị, và các callback của quá trình probe thường gọi đến các hàm trợ giúp I3C yêu cầu lấy lại khóa `i3c_bus_normaluse_lock()`, dẫn đến việc thu giữ đệ quy cùng một rwsem. Các rwsem không hỗ trợ khóa đọc đệ quy và có thể gây ra deadlock khi có một writer đang chờ đợi. Xem phần "Recursive read locks" trong tài liệu Documentation/locking/lockdep-design.rst.
Ví dụ, với Intel LPSS I3C, LOCKDEP tạo ra cảnh báo như sau: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370
but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0
Khắc phục vấn đề này bằng cách tách biệt quá trình tạo thiết bị và đăng ký thiết bị. Điền vào `desc->dev` dưới sự bảo vệ của khóa bảo trì (maintenance lock), thu thập các thiết bị vẫn cần được đăng ký vào một danh sách cục bộ, sau đó nhả khóa trước khi gọi `device_register()`. Cuối cùng, lấy lại khóa và dọn dẹp bất kỳ thiết bị nào không thể đăng ký thành công.
Sử dụng khóa bảo trì thay vì khóa sử dụng thông thường (normal-use lock) trong quá trình thêm các đối tượng thiết bị. Khóa bảo trì phía writer ngăn chặn việc đọc giả quan sát thấy `desc->dev` đang được khởi tạo một phần trong giai đoạn populate thiết ban đầu, hoặc tránh trường hợp `desc->dev` biến mất nếu quá trình đăng ký thất bại.
Danh sách cục bộ yêu cầu một nút danh sách (list node), do đó cần thêm thành viên nút danh sách vào struct i3c_device.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.