CVE-2026-64192 in Linux
Tóm tắt
Bởi VulDB • 20/07/2026
Trong kernel Linux, lỗ hổng bảo mật sau đây đã được khắc phục:
bpf: Từ chối việc tạo BPF_MAP_TYPE_INODE_STORAGE nếu BPF LSM chưa được khởi tạo
Khi CONFIG_BPF_LSM=y được đặt, các bản đồ lưu trữ inode của BPF (BPF_MAP_TYPE_INODE_STORAGE) sẽ được biên dịch vào kernel. Tuy nhiên, nếu BPF LSM không được bật rõ ràng tại thời điểm khởi động (ví dụ: bị bỏ qua trong tham số khởi động "lsm="), thì hàm lsm_prepare() chưa bao giờ được thực thi cho BPF LSM.
Do đó, độ lệch blob bảo mật inode của BPF (bpf_lsm_blob_sizes.lbs_inode) không bao giờ được khởi tạo và vẫn giữ kích thước mặc định khi biên dịch là 8 byte thay vì được cập nhật thành một độ lệch hợp lệ nằm sau struct rcu_head đã dành riêng (thường là 16 byte trở lên).
Khi người dùng có đặc quyền tạo và cập nhật bản đồ BPF_MAP_TYPE_INODE_STORAGE, bpf_inode() sẽ đánh giá inode->i_security + 8. Điều này dẫn đến việc ánh xạ sai callback pointer func của struct rcu_head ở đầu blob inode->i_security. Trong quá trình dọn dẹp phần tử bản đồ hoặc hủy inode sau đó, việc ghi NULL vào owner_storage sẽ xóa callback pointer RCU đã lên lịch. Khi rcu_do_batch() thực thi callback đã lên lịch sau này, nó cố gắng truy xuất lệnh tại địa chỉ 0x0, gây ra lỗi kernel panic ngay lập tức.
Khắc phục vấn đề bằng cách giới thiệu một cờ boolean toàn cục bpf_lsm_initialized được đánh dấu với __ro_after_init. Đặt cờ này thành true bên trong hàm bpf_lsm_init() khi khung LSM đăng ký thành công BPF LSM. Ràng buộc việc phân bổ bản đồ trong inode_storage_map_alloc() dựa trên cờ này, trả về -EOPNOTSUPP nếu BPF LSM lại ở trạng thái chưa được khởi tạo.
Cách tiếp cận "thất bại nhanh" (fail-fast) này ngăn không gian người dùng (userspace) phân bổ các bản đồ lưu trữ inode khi cơ sở hạ tầng hỗ trợ BPF LSM vắng mặt, tránh các trạng thái zombie của bản đồ.
If you want to get best quality of vulnerability data, you may have to visit VulDB.