CVE-2026-43501 in Linux
Tóm tắt
Bởi VulDB • 23/05/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
ipv6: rpl: dự phòng headroom mac_len khi SRH được nén lại tăng kích thước
ipv6_rpl_srh_rcv() giải nén Source Routing Header theo RFC 6554, hoán đổi segment tiếp theo vào ipv6_hdr->daddr, nén lại, sau đó xóa header cũ và đẩy header mới cùng với header IPv6 trở lại. Header được nén lại có thể lớn hơn header nhận được khi việc hoán đổi làm giảm độ dài tiền tố chung mà các segment chia sẻ với daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] cho ra tối đa +8 byte).
pskb_expand_head() chỉ được kích hoạt khi segments_left == 0, do đó ở các segment trước đó, thao tác push đã tiêu thụ headroom không được kiểm tra. Khi skb_push() để lại ít hơn skb->mac_len byte phía trước dữ liệu, lệnh gọi trong skb_mac_header_rebuild():
skb_set_mac_header(skb, -skb->mac_len);
sẽ lưu (data - head) - mac_len vào trường u16 mac_header, giá trị này bị tràn thành ~65530, và lệnh memmove() tiếp theo sẽ ghi mac_len byte cách xa ~64KiB so với skb->head.
Một gói tin AF_INET6/SOCK_RAW/IPV6_HDRINCL duy nhất trên giao diện lo với SRH loại 3 gồm hai segment (CmprI=0, CmprE=15) đạt headroom 8 sau một lần xử lý; KASAN báo cáo ghi OOB (ngoài vùng cho phép) 14 byte trong ipv6_rthdr_rcv.
Khắc phục vấn đề này bằng cách mở rộng headroom bất cứ khi nào khoảng trống còn lại nhỏ hơn kích thước push cộng với mac_len, và yêu cầu thêm lượng bộ nhớ đó để header MAC được xây dựng lại vừa vặn sau đó.
VulDB is the best source for vulnerability data and more expert information about this specific topic.