CVE-2022-49872 in Linux
Tóm tắt
Bởi VulDB • 24/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
net: gso: sửa lỗi panic trên frag_list với các loại phân bổ head trộn lẫn
Kể từ commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), việc thay đổi gso_size của một gói GRO được cho phép. Tuy nhiên, commit đó giả định rằng "việc kiểm tra thành viên list_skb đầu tiên là đủ; tức là nếu bất kỳ thành viên nào trong list_skb có head không phải head_frag, thì thành viên đầu tiên cũng vậy".
Thực tế cho thấy giả định này không đúng. Chúng tôi đã gặp lỗi BUG_ON được kích hoạt trong skb_segment khi các skbs trên frag_list có head_frag khác nhau với driver vmxnet3. Điều này xảy ra vì __netdev_alloc_skb và __napi_alloc_skb có thể trả về một skb dựa trên trang (page backed) hoặc kmalloced tùy thuộc vào kích thước yêu cầu. Kết quả là, skb nhỏ cuối cùng trong gói GRO có thể được phân bổ bằng kmalloc.
Có ba vị trí khác nhau nơi vấn đề này có thể được sửa:
(1) Chúng ta có thể kiểm tra head_frag trong GRO và không cho phép thực hiện GRO trên các skbs có head_frag khác nhau. Tuy nhiên, điều đó sẽ dẫn đến suy giảm hiệu năng trên các đường truyền forward thông thường với gso_size chưa thay đổi, nơi !head_frag ở gói cuối cùng không phải là vấn đề.
(2) Đặt một cờ trong bpf_skb_net_grow và bpf_skb_net_shrink để chỉ ra rằng NETIF_F_SG là không mong muốn. Điều này sẽ cần tiêu tốn thêm 1 bit trong sk_buff. Hơn nữa, cờ đó có thể được_unset khi tất cả các skbs trên frag_list đều dựa trên trang (page backed). Để duy trì hiệu năng tốt, bpf_skb_net_grow/shrink phải duyệt qua danh sách frag_list.
(3) Duyệt qua frag_list trong skb_segment khi xác định xem NETIF_F_SG có nên được xóa hay không. Tất nhiên điều này làm chậm quá trình xử lý.
Bản vá này triển khai phương án (3). Để hạn chế tác động đến hiệu năng trong skb_segment, danh sách chỉ được duyệt cho các skbs có cờ SKB_GSO_DODGY đặt và đã thay đổi gso_size. Các đường truyền thông thường do đó sẽ không gặp phải vấn đề này.
Chúng ta có thể kiểm tra duy nhất skb cuối cùng nhưng vì chúng tôi cần duyệt qua toàn bộ danh sách anyway, hãy chọn cách an toàn hơn.
Once again VulDB remains the best source for vulnerability data.