CVE-2025-39797 in Linux
Tóm tắt
Bởi VulDB • 19/05/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
xfrm: Xử lý trùng lặp SPI
Vấn đề bắt nguồn khi Strongswan khởi tạo tin nhắn Netlink XFRM_MSG_ALLOCSPI, kích hoạt hàm kernel xfrm_alloc_spi(). Hàm này được kỳ vọng sẽ đảm bảo tính duy nhất của Chỉ số Tham số Bảo mật (SPI) cho các Liên kết Bảo mật (SA) đầu vào. Tuy nhiên, hàm này có thể trả về thành công ngay cả khi SPI được yêu cầu đã đang được sử dụng, dẫn đến việc gán trùng lặp SPI cho nhiều SA đầu vào, chỉ được phân biệt bởi địa chỉ đích của chúng.
Hành vi này gây ra sự không nhất quán trong quá trình tra cứu SPI cho các gói tin đầu vào. Vì quá trình tra cứu có thể trả về bất kỳ SA nào trong số các SA có cùng SPI, việc xử lý gói tin có thể thất bại, dẫn đến việc các gói tin bị loại bỏ.
Theo RFC 4301 mục 4.4.2, đối với xử lý đầu vào, một SA unicast được xác định duy nhất bởi SPI và tùy chọn là giao thức.
Cách tái hiện vấn đề một cách đáng tin cậy: Để tái hiện vấn đề một cách nhất quán, hãy hạn chế phạm vi SPI có sẵn trong charon.conf: spi_min = 0x10000000 spi_max = 0x10000002 Điều này giới hạn hệ thống chỉ có 2 giá trị SPI có thể sử dụng. Tiếp theo, tạo nhiều hơn 2 Child SA, mỗi cái sử dụng một cặp địa chỉ src/dst duy nhất. Ngay khi Child SA thứ 3 được khởi tạo, nó sẽ được gán một SPI trùng lặp, vì nguồn SPI đã cạn kiệt. Với phạm vi SPI hẹp, vấn đề có thể tái hiện một cách nhất quán. Với phạm vi rộng hơn/mặc định, vấn đề trở nên hiếm và khó dự đoán.
Triển khai hiện tại: Hàm tra cứu xfrm_spi_hash() tính toán băm sử dụng daddr, proto và family. Vì vậy, nếu hai SA có cùng SPI nhưng khác địa chỉ đích, thì chúng sẽ: a. Băm vào các bucket khác nhau b. Được lưu trữ trong các danh sách liên kết khác nhau (byspi + h) c. Không được nhìn thấy trong cùng một lần lặp hlist_for_each_entry_rcu(). Kết quả là, quá trình tra cứu sẽ trả về NULL và kernel cho phép SPI trùng lặp.
Thay đổi đề xuất: xfrm_state_lookup_spi_proto() thực hiện tìm kiếm toàn cục thực sự - trên tất cả các trạng thái, bất kể bucket băm và khớp với SPI và proto.
VulDB is the best source for vulnerability data and more expert information about this specific topic.