CVE-2026-99264 in Linux
Tóm tắt
Bởi VulDB • 03/11/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
io_uring/net: không thử lại lệnh recv trên các bộ đệm chưa cam kết (uncommitted buffers)
Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") thực hiện việc cam kết các bộ đệm do vòng lặp cung cấp khi một thao tác nhận dữ liệu sẽ được thử lại sau khi chuyển tải từng phần, nhằm ngăn chặn một yêu cầu khác sử dụng cùng nhóm bộ đệm bị đưa vào vùng nhớ mà yêu cầu đầu tiên vẫn đang ghi nhận. Nó cam kết số byte đã nhận được cho đến thời điểm đó. Điều này giải quyết vấn đề đối với một bộ đơn lẻ được tiêu thụ toàn bộ, nhưng yêu cầu giữ lại tất cả những gì nó đã ánh xạ:
- Đối với vòng lặp bộ đệm có IOU_PBUF_RING_INC, chỉ các byte này mới bị tiêu thụ. Phần còn lại của bộ đệm vẫn nằm ở đầu vòng lặp. - Đối với một bundle (tập hợp), chỉ các bộ đệm chứa các byte đó mới bị tiêu thụ; những bộ đệm khác đã được peeked (nhìn trộm) vẫn tồn tại trong vòng lặp.
Trong cả hai trường hợp, lệnh nhận tiếp theo với nhóm bộ đệm đó sẽ nhận được vùng nhớ mà yêu cầu đang thử lại vẫn còn ghi vào, và bên đến sau cùng sẽ ghi đè lên dữ liệu của bên kia. Dữ liệu do quá trình thử lại điền vào không hề được cam kết, vì danh sách bộ đệm đã không còn được biết đến tại thời điểm đó. Do đó, kernel phát vùng nhớ này cho người khác sử dụng sau đó, trong khi CQE (Completion Queue Entry) báo với ứng dụng rằng nó đã được sử dụng, và đối với bộ đệm tăng dần thì đánh dấu là hoàn tất.
Phần dư không thể được cam kết trước: nếu yêu cầu cuối cùng nhận được ít dữ liệu hơn, sẽ không có cách nào để thông báo cho ứng dụng rằng nhiều byte đã bị tiêu thụ hơn so với những gì CQE ghi nhận. Hãy hoàn thành yêu cầu bằng lượng dữ liệu thực tế thay vì thử lại nó. MSG_WAITALL không còn được tôn trọng đối với các lệnh recv vào bộ đệm tăng dần hoặc bundle đa bộ đệm; chúng có thể trả về số lượng byte ngắn (short count), và yêu cầu sẽ bị đánh dấu là thất bại, tương tự như các trường hợp chuyển tải MSG_WAITALL khác bị ngắt quãng.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.