Lỗi từ chối dịch vụ trong Penalty Handler của vllm-project vLLM có thể làm sập inference engine

Một lỗ hổng bảo mật đã được phát hiện trong vllm-project vLLM đến phiên bản 0.31.0. Lỗ hổng ảnh hưởng đến hàm get_token_bin_counts_and_mask trong tệp vllm/model_executor/layers/utils.py của thành phần Penalty Handler. Thao túng dữ liệu có thể dẫn đến từ chối dịch vụ. Có thể khai thác lỗ hổng từ xa. Exploit đã được công bố công khai và có thể được sử dụng để tấn công. Dự án đã được thông báo sớm về vấn đề thông qua một issue report nhưng vẫn chưa phản hồi.

• vllm-project vLLM: mô tả của CNA xác định sản phẩm bị ảnh hưởng đến phiên bản 0.31.0. Dữ liệu affected cập nhật trong CNA/GCVE bao phủ các bản 0.1 đến 0.31.0, gồm cả các nhánh 0.21 đến 0.31.0 vốn không xuất hiện trong danh sách affected_products ban đầu của record chuẩn hóa.
• Downstream Red Hat: VEX của Red Hat đánh dấu nhiều thành phần vLLM trong Red Hat AI Inference Server, Red Hat Enterprise Linux AI 3 và Red Hat OpenShift AI là known affected; một số thành phần CPU, Neuron và torch được đánh dấu known not affected trong phạm vi riêng của Red Hat. Các trạng thái downstream này không tự xác định ranh giới phiên bản của vLLM upstream.
• Chưa có fixed release vLLM được xác nhận trong bằng chứng hiện có. Các commit sửa lỗi trong lịch sử phát triển không nên được xem là bản phát hành đã khắc phục.

vllm-project vLLM xử lý penalty cho quá trình sinh token trong Penalty Handler, với điểm lỗi được xác định tại hàm get_token_bin_counts_and_mask trong vllm/model_executor/layers/utils.py. Issue kỹ thuật mô tả rằng các request sử dụng prompt_embeds không ghi các vị trí prompt tương ứng vào bộ đệm token ID trên CPU, dù các vị trí này được đánh dấu là không phải token ID. Khi tạo metadata sampling, đường xử lý penalty vẫn có thể sử dụng dữ liệu cũ còn lại trong bộ đệm và đưa chúng vào phép scatter mà không xét đến cờ is_token_ids. Với các penalty như repetition, presence hoặc frequency penalty và một số hình dạng batch, dữ liệu cũ hoặc nằm ngoài phạm vi có thể làm phát sinh lỗi CUDA device-side assert và khiến engine dừng; ngay cả khi không sập, penalty có thể được tính trên dữ liệu không đúng. Việc sửa được đề xuất chuyển các vị trí prompt_embeds thành giá trị token ID đệm không hợp lệ khi tạo metadata, nhưng bằng chứng hiện có chưa xác nhận bản sửa đã được phát hành trong một phiên bản vLLM chính thức.

Lỗ hổng có thể bị khai thác từ xa thông qua endpoint phục vụ inference khi máy chủ cho phép prompt_embeds. Reproducer công khai nhắm đến các request /v1/completions có prompt embedding kết hợp với repetition_penalty, presence_penalty hoặc frequency_penalty; điều kiện kích hoạt được mô tả là batch có các độ dài prompt khác nhau và request dùng embedding là prompt dài nhất. Issue cho biết một burst request có thể làm EngineCore chết, khiến các request đang xử lý và request tiếp theo trả về lỗi máy chủ cho đến khi tiến trình được khởi động lại. Hồ sơ CNA mô tả khả năng truy cập từ xa và yêu cầu đặc quyền thấp, trong khi VEX của Red Hat mô tả các client từ xa không cần xác thực đối với một số deployment downstream; yêu cầu xác thực chính xác phụ thuộc vào cấu hình triển khai vLLM. PoC đã được công khai, nhưng bằng chứng hiện có không nêu tên chiến dịch, nạn nhân hoặc vụ xâm nhập cụ thể.

Kết quả kỹ thuật trực tiếp là suy giảm hoặc mất tính sẵn sàng của model-serving engine. Một request từ xa có thể làm phát sinh lỗi trong đường xử lý penalty, dẫn đến CUDA device-side assert, EngineDeadError, HTTP 500 và yêu cầu restart tiến trình. Phạm vi ảnh hưởng có thể bao trùm toàn bộ các request đang dùng cùng engine thay vì chỉ request độc hại. Record không cho thấy khả năng đọc dữ liệu, sửa dữ liệu hoặc nâng quyền; tác động tổ chức thực tế là gián đoạn inference, lỗi các workload phụ thuộc và thời gian khôi phục dịch vụ. Khả năng kích hoạt phụ thuộc vào việc deployment hỗ trợ prompt embeddings, penalty parameters và hình dạng batch phù hợp.

Lỗi chủ yếu ảnh hưởng đến tính sẵn sàng của dịch vụ inference:

• Một request được chế tạo có thể làm dừng EngineCore hoặc tiến trình phục vụ model, khiến nhiều user cùng sử dụng instance bị gián đoạn.
• Các request đang xử lý và request tiếp theo có thể thất bại, còn health check có thể không thành công cho đến khi dịch vụ được khởi động hoặc khôi phục.
• Đội vận hành có thể phải restart workload, điều tra lỗi GPU và xử lý các request bị gián đoạn trong thời gian phục hồi.
• Bằng chứng hiện có không cho thấy tác động đến tính bí mật hoặc tính toàn vẹn của dữ liệu; không nên suy diễn từ lỗi này thành một kịch bản rò rỉ dữ liệu.

1. Kiểm kê tất cả instance vLLM, image hoặc package đang triển khai và đối chiếu với phạm vi affected được nêu ở trên. Kiểm tra riêng các deployment có bật --enable-prompt-embeds.
2. Ưu tiên nâng cấp lên bản sửa lỗi chính thức do vLLM hoặc nhà cung cấp downstream công bố khi bản đó có sẵn. Hiện chưa có fixed release chính thức được xác nhận, vì vậy không nên tự suy ra rằng một bản mới hơn đã an toàn.
3. Trong thời gian chờ bản sửa, giới hạn khả năng truy cập mạng đến inference service cho các network hoặc client được ủy quyền. Với môi trường OpenShift AI, áp dụng NetworkPolicy để chỉ cho phép ingress từ gateway hoặc namespace tin cậy.
4. Nếu phù hợp với vận hành, tạm thời giới hạn hoặc vô hiệu hóa quyền sử dụng request kết hợp prompt_embeds với các sampling penalty. Đây là biện pháp giảm phơi nhiễm tạm thời, không phải bản vá đã được xác nhận.
5. Sau khi thay đổi cấu hình hoặc triển khai bản sửa, kiểm tra health endpoint, gửi request inference hợp lệ và xác nhận engine không còn restart hoặc trả lỗi sau các batch có penalty.
6. Nếu xảy ra crash, cô lập endpoint khỏi client không tin cậy, lưu log GPU và engine để điều tra, sau đó khởi động lại dịch vụ theo quy trình vận hành.

1. Kiểm kê các instance vLLM và xác định phiên bản thực tế đang chạy, đặc biệt các nhánh được CNA xác định là bị ảnh hưởng.
2. Kiểm tra cấu hình máy chủ để xác định tùy chọn --enable-prompt-embeds và các endpoint inference có nhận trường prompt_embeds hay không.
3. Rà soát request telemetry cho việc kết hợp prompt_embeds với repetition_penalty, presence_penalty hoặc frequency_penalty, đặc biệt trong các batch có độ dài prompt khác nhau. Đây là điều kiện phơi nhiễm đã được mô tả, không phải IOC độc lập.
4. Kiểm tra log GPU và log engine để tìm các chuỗi như scatter gather kernel index out of bounds, CUDA error: device-side assert triggered, EngineCore encountered a fatal error hoặc EngineDeadError.
5. Đối chiếu thời điểm lỗi với HTTP 500, lỗi health check và việc các request bình thường thất bại sau một batch có penalty. Việc không thấy các dấu hiệu này không chứng minh hệ thống an toàn.
6. Có thể bổ sung giám sát generic về restart bất thường, tăng lỗi inference và gián đoạn health check như biện pháp cảnh báo, nhưng các tín hiệu này không phải indicator đã được xác nhận riêng cho lỗ hổng.