CVE-2026-99112 in Linux
Tóm tắt
Bởi VulDB • 28/10/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
net/sched: cls_flower: xác minh con trỏ mặt nạ (mask pointer) sau khi gọi nla_next()
Hàm fl_set_enc_opt() lặp qua các thuộc tính tùy chọn đường hầm lồng nhau của khóa bằng cách sử dụng nla_for_each_attr(), trong đó một con trỏ mặt nạ duy nhất được tăng dần thông qua hàm nla_next() ở cuối mỗi vòng lặp, do đó con trỏ mặt nạ (mask cursor) bị điều khiển bởi số lượng thuộc tính khóa thay vì các thuộc tính riêng biệt của chính mặt nạ. Hàm nla_ok() được thêm vào trong commit c96adff956191 ("cls_flower: gọi nla_ok() trước khi gọi nla_next()") chỉ xác minh con trỏ mặt nạ vừa bị tiêu thụ; còn con trỏ do hàm nla_next() tạo ra thì được sử dụng bởi vòng lặp tiếp theo (fl_set_geneve_opt() và các hàm tương tự) mà không có bất kỳ sự kiểm tra nào.
Các thuộc tính lồng nhau của mặt nạ được xác minh bằng NL_VALIDATE_LIBERAL, chỉ đưa ra cảnh báo về các byte dư thừa không tạo thành một thuộc tính hoàn chỉnh. Do đó, một mặt nạ chứa một thuộc tính hợp lệ cộng thêm 1-3 byte dư (hoặc độ dài thuộc tính không căn lề khiến msk_depth trở thành số âm) sẽ chuyển sang vòng lặp tiếp theo với trạng thái msk_depth != 0, dẫn đến cả kiểm tra !msk_depth trong fl_set_enc_opt() lẫn kiểm tra !depth trong các hàm trợ giúp per-type đều không được kích hoạt. Sau đó, nla_type() đọc vượt quá payload của mặt nạ và nla_parse_nested_deprecated() lặp với giá trị nla_len lấy từ những byte này, dẫn đến việc đọc dữ liệu ra ngoài phạm vi thuộc tính mặt nạ (KASAN: slab-out-of-bounds read trong __nla_validate_parse từ fl_change()).
Cần xác minh con trỏ mặt nạ đã được tăng dần: khi mặt nạ chưa thực sự hết hạn (msk_depth != 0) và con trỏ mới không vượt qua kiểm tra nla_ok(), hãy từ chối bộ lọc với mã lỗi -EINVAL. Một mặt nạ bị tiêu thụ chính xác vẫn sẽ bỏ qua bước kiểm tra này, nhằm bảo toàn hành vi khớp chính xác cho các thuộc tính khóa còn lại.
Be aware that VulDB is the high quality source for vulnerability data.