Use-after-free trong WebTransport của Facebook proxygen có thể làm lộ dữ liệu tiến trình

Trong proxygen từ v2024.10.28.00 đến v2026.09.28.00, WebTransportImpl::terminateSessionStreams (WebTransportImpl::destroy trong các bản phát hành trước v2025.08.18.00) đã không hủy đăng ký read callback cho các stream không còn mở trước khi hủy chúng. Sau đó, transport có thể gọi một read callback đã được giải phóng.

• Facebook proxygen: bị ảnh hưởng từ v2024.10.28.00 đến các bản có version nhỏ hơn v2026.09.28.00, theo kiểu version semver và điều kiện lessThan trong record.
• Tên routine theo nhánh: lỗi được mô tả tại WebTransportImpl::terminateSessionStreams; trong các bản phát hành trước v2025.08.18.00, routine tương ứng được gọi là WebTransportImpl::destroy. Đây là thông tin về tên implementation theo nhánh, không phải bằng chứng rằng v2025.08.18.00 là fixed release.
• Record đặt default_status là unaffected và không liệt kê thêm sản phẩm hoặc nhánh song song nào. Trạng thái của các nhánh không được liệt kê không nên được suy đoán từ bản ghi này.

Facebook proxygen quản lý read callback của các WebTransport stream thông qua WebTransportImpl. Khi stream đã nhận dữ liệu kèm FIN, stream có thể không còn open() nhưng read callback vẫn được transport đăng ký. Trong quá trình kết thúc session, WebTransportImpl::terminateSessionStreams đã không hủy đăng ký callback này trước khi hủy stream handle, vì vậy transport có thể gọi vào callback đã được giải phóng, tạo ra lỗi Use After Free thuộc CWE-416. Ở các bản phát hành cũ hơn, routine tương ứng được mô tả là WebTransportImpl::destroy. Thay đổi upstream liên quan bổ sung trạng thái theo dõi callback và hủy đăng ký callback trước khi giải phóng handle; tuy nhiên, record không mô tả đầy đủ chuỗi input trên wire cần thiết để kích hoạt lỗi.

• Khả năng tiếp cận: lỗi nằm trong luồng xử lý WebTransport có thể được tiếp cận qua mạng.
• Điều kiện: record mô tả rằng không cần authentication hoặc user interaction, và độ phức tạp khai thác thấp. Peer từ xa kiểm soát traffic WebTransport, nhưng chuỗi stream cụ thể để đưa handle vào trạng thái lỗi không được công bố.
• Tình trạng khai thác: record không xác nhận known exploitation, đánh dấu không có public exploit, và không nêu campaign, nạn nhân hoặc exploit cụ thể.
• Không có IOC, log signature hoặc payload khai thác được xác nhận trong bằng chứng hiện có.

Lỗi cho phép transport có khả năng gọi một read callback trỏ tới object đã bị giải phóng trong quá trình WebTransport session teardown. Kết quả có thể là truy cập vùng nhớ không hợp lệ và rò rỉ dữ liệu trong process; record không chứng minh được khả năng thực thi mã, ghi đè dữ liệu hoặc làm gián đoạn dịch vụ. Tác động được cung cấp tập trung vào confidentiality, trong khi integrity và availability không được xác nhận là bị ảnh hưởng. Vì scope được mô tả là không thay đổi, hậu quả nằm trong context của service đang chạy proxygen, nhưng một peer mạng không cần quyền đặc biệt hoặc tương tác người dùng để tiếp cận đường xử lý được mô tả.

• Rủi ro dữ liệu: callback được gọi sau khi object đã bị giải phóng có thể dẫn đến truy cập dữ liệu trong vùng nhớ không còn hợp lệ và có khả năng làm lộ dữ liệu trong process. Record không xác nhận đã xảy ra exfiltration thực tế.
• Phạm vi cần ưu tiên: các service dùng proxygen để cung cấp WebTransport cho peer từ xa, đặc biệt service internet-facing hoặc nhận traffic từ mạng không tin cậy.
• Ảnh hưởng vận hành: thư viện có thể được đóng gói bên trong nhiều ứng dụng downstream, nên chỉ kiểm tra package cấp ứng dụng có thể bỏ sót bản proxygen dễ lỗi.
• Record không thiết lập hậu quả cụ thể về thay đổi dữ liệu hoặc gián đoạn dịch vụ; tác động chính được mô tả là rủi ro đối với confidentiality.

1. Nâng cấp Facebook proxygen lên v2026.09.28.00, là boundary đầu tiên nằm ngoài khoảng affected được cung cấp cho nhánh này. Không diễn giải boundary này thành cam kết rằng mọi nhánh phát hành sau đó đều đã được xác minh.
2. Với source build, áp dụng thay đổi upstream sửa việc theo dõi và hủy đăng ký read callback trước khi giải phóng WebTransport stream handle, sau đó rebuild và redeploy toàn bộ binary liên quan.
3. Nếu chưa thể cập nhật ngay, hạn chế network access đến các endpoint WebTransport sử dụng bản bị ảnh hưởng như một biện pháp giảm phơi nhiễm tạm thời. Đây là compensating control, không phải fixed của lỗi.
4. Kiểm thử lại session teardown trong đó stream đã nhận dữ liệu kèm FIN nhưng không còn open(), đồng thời xác nhận transport không còn giữ read callback khi handle bị hủy.
5. Sau khi triển khai, xác minh version thực tế trong artifact và image runtime, không chỉ version của source tree hoặc lockfile.

1. Kiểm kê các binary, package và source build có nhúng Facebook proxygen, sau đó đối chiếu chính xác với nhánh version bị ảnh hưởng.
2. Xác định các service có bật hoặc chấp nhận WebTransport, đặc biệt các service nhận kết nối từ mạng không tin cậy.
3. Với source build, kiểm tra WebTransportImpl::terminateSessionStreams và routine WebTransportImpl::destroy ở nhánh cũ để xác nhận read callback được hủy đăng ký trước khi stream handle bị hủy. Có thể đối chiếu với thay đổi upstream bổ sung trạng thái readCallbackRegistered và xử lý teardown tương ứng.
4. Rà soát memory-safety diagnostics, crash report hoặc sanitizer report liên quan đến WebTransport teardown như một biện pháp thận trọng, không xem đây là IOC đã được xác nhận.
5. Không thấy crash hoặc không có log phù hợp không chứng minh hệ thống an toàn, vì record không cung cấp indicator runtime cụ thể.