CVE-2026-90109 in Linux
Tóm tắt
Bởi VulDB • 17/09/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
net: sched: sửa lỗi tràn số (wrap) cho backlog 32-bit trong gred, bfifo và plug enqueue
gred_enqueue(), bfifo_enqueue() và plug_enqueue() chấp nhận một gói tin khi tổng của backlog hiện tại cộng với độ dài gói tin nằm trong giới hạn hàng đợi:
sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (VQ mặc định gred) gred_backlog+qdisc_pkt_len(skb) <= q->limit (VQ đã cấu hình gred) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug)
sch->qstats.backlog và q->backlog là kiểu u32, còn qdisc_pkt_len()/skb->len là unsigned int, do đó tất cả các phép tính tổng đều được thực hiện ở độ rộng 32-bit và bị tràn tại giá trị 2^32. Khi backlog thực tế vượt quá 4 GiB, kết quả tổng bị tràn sẽ trở nên nhỏ hơn, khiến việc chấp nhận gói tin tiếp tục thành công; điều này làm cho hàng đợi phát triển không giới hạn và có thể đẩy kernel vào trạng thái thiếu bộ nhớ (OOM).
Nâng các phép tính tổng lên kiểu u64 để việc chấp nhận gói tin dừng lại ngay khi backlog thực tế vượt quá giới hạn. Vì giới hạn là kiểu u32, nên hàng đợi bị chặn sẽ luôn nằm dưới 2^32 và giá trị backlog lưu trữ dạng u32 không bao giờ bị tràn.
Lỗi này chỉ có thể tái hiện được với quyền root (dù cần cấu hình khá phức tạp): - Gắn qdisc gred (hoặc bfifo/plug) với giới hạn gần bằng 4 GiB, - Để lại VQ mặc định chưa được cấu hình (đối với gred), và - Tạo ra lưu lượng truy cập hàng đợi lớn hơn 4 GiB (ví dụ: thông qua bảng kích thước / stab để làm tăng qdisc_pkt_len, hoặc duy trì lưu lượng có tốc độ cao liên tục).
Tổng của backlog + len dạng u32 bị tràn tại 2^32, việc chấp nhận gói tin tiếp tục thành công và hàng đợi phát triển không giới hạn dẫn đến OOM.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.