GHSA-8pw2-6jv3-mj5j vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation

• PyPI vllm: < 0.28.0 → fixed in 0.28.0

Summary Current vLLM `main` lets an inference request choose the PyNvVideoCodec GPU video decoder through `media_io_kwargs.video.video_backend`, but engine GPU memory reservation is computed only from static startup configuration and `VLLM_VIDEO_LOADER_BACKEND`. If the server starts with the default OpenCV/software backend and no `--mm-ipc-gpu-memory-gb` budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget. Technical Details The vulnerable boundary is the split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker. Request bodies for Chat Completions and Responses expose `media_io_kwargs`, and those values are forwarded to the shared media connector. For video inputs, `MediaConnector.fetch_video()` copies `self.media_io_kwargs["video"]` into `video_io_kwargs`, only setting a model-derived backend when `video_backend` is absent. `VideoMediaIO.__init__()` then consumes `video_backend` from those kwargs and loads that backend from `VIDEO_LOADER_REGISTRY`. The relevant request-side source path is: ```python video_io_kwargs = dict(self.media_io_kwargs.get("video", {})) if "video_backend" not in video_io_kwargs and ( video_backend := get_video_loader_backend_for_processor(video_processor) ): video_io_kwargs["video_backend"] = video_backend video_io = VideoMediaIO(image_io, **video_io_kwargs) ``` ```python video_loader_backend = ( kwargs.pop("video_backend", None) or envs.VLLM_VIDEO_LOADER_BACKEND ) self.video_loader = VIDEO_LOADER_REGISTRY.load(video_loader_backend) ``` `VideoBackend.load_bytes()` then dispatches `backend == "pynvvideocodec"` into `decode_frames_pynvvideocodec()`, which constructs a PyNvVideoCodec decoder, creates or uses a CUDA stream, reads stream metadata, decodes selected frames on the GPU, and copies those frames into pinned host memory. The new frontend GPU memory pool accounts only for raw decoded frame bytes when a pool exists; it does not make request-time backend selection safe when no startup reservation was made. The engine-side reservation code makes its decision from static model config and environment only: ```python def _uses_pynvvideocodec_video_backend(mm_config) -> bool: video_kwargs = mm_config.media_io_kwargs.get("video", {}) video_loader_backend = ( video_kwargs.get("video_backend") or envs.VLLM_VIDEO_LOADER_BACKEND ) codec_backend = video_kwargs.get("backend") return ( video_loader_backend == PYNVVIDEOCODEC_VIDEO_BACKEND or codec_backend == PYNVVIDEOCODEC_VIDEO_BACKEND ) ``` ```python decoder_reserved_bytes = ( num_api_servers * per_server_decoder_bytes if self._uses_pynvvideocodec_video_backend(mm_config) else 0 ) reserved_bytes = raw_frame_reserved_bytes + decoder_reserved_bytes if reserved_bytes "}} ] } ], "media_io_kwargs": { "video": { "video_backend": "pynvvideocodec" } } } ``` The following bounded source-level check confirms the code path without allocating GPU memory: ```bash git clone --filter=blob:none https://github.com/vllm-project/vllm.git cd vllm git checkout ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a python3 check_pynv_backend_reservation.py --repo . ``` PoC The bounded check validates current source markers, simulates the exact static reservation predicate, and compares vulnerable and negative-control configurations. Key output: ```json { "vulnerable": true, "head": "ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a", "reservation_simulation": { "env_video_loader_backend": "opencv", "request_selects_pynv_after_startup": true, "vulnerable_static_reserved_bytes": 0, "negative_control_static_pynv_reserved_bytes": 2066953011, "raw_frame_only_control_reserved_bytes": 268435456, "unreserved_decoder_bytes_when_only_request_selects_pynv": 2066953011 } } ``` The negative control is important: when PyNvVideoCodec is selected statically, the worker reserves `2066953011` bytes per API process for decoder surfaces plus CUDA context. The vulnerable case reserves `0` bytes for the same decoder overhead because PyNvVideoCodec is selected only by the later request. A second control with static OpenCV plus `mm_ipc_gpu_memory_gb=0.25` reserves only the raw-frame semaphore budget and still does not reserve PyNv decoder/CUDA-context bytes. Impact An attacker who can submit video requests to a vLLM deployment with PyNvVideoCodec available can force frontend GPU decoding even when the engine did not reserve memory for that decoder during startup. On high-utilization serving deployments, the unreserved CUDA context, retained decoder surfaces, and decoded-frame allocations can reduce or exhaust GPU memory that the engine assumed was available for weights, activations, or KV cache, causing request failures, worker crashes, or service-level denial of service. Suggested severity is Medium with conservative CVSS v3.1 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H` (6.5). If a deployment exposes the affected API without authentication, `PR:N` would raise the deployment-specific score. Suggested weaknesses are `CWE-770` (Allocation of Resources Without Limits or Throttling) and `CWE-400` (Uncontrolled Resource Consumption). This should not be rated Low because the affected resource is shared GPU memory in the serving path and the code already treats the PyNv decoder/CUDA-context footprint as large enough to reserve at startup when statically configured. Limitations: exploitation requires a GPU deployment where PyNvVideoCodec is installed and usable, and the request must reach a video-capable model/path. The issue does not claim code execution, data disclosure, or SSRF. Suggested Fix Do not allow untrusted request fields to select a GPU decoder that was not included in startup memory reservation. The simplest fix is to reject request-level `media_io_kwargs.video.video_backend="pynvvideocodec"` unless the static server configuration already selected PyNvVideoCodec and reserved its decoder/CUDA-context budget. If dynamic backend selection remains supported, split software and GPU decoder policies: allow request selection among CPU/software decoders only, require an explicit operator allowlist for GPU decoders, and include every request-selectable GPU decoder in the startup reservation predicate. Add regression coverage for static OpenCV startup config plus request-level PyNvVideoCodec override, and preserve the negative control where static PyNvVideoCodec configuration reserves decoder/CUDA-context bytes. Affected Package/Versions Package: `vllm` from `vllm-project/vllm`. Confirmed affected: current `main` at `ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a`. Introduced by: `af16446bf39de047ab57649c933063cf1cbf1e50`, `Vram semaphore infra (#44465)`, committed 2026-06-26T17:32:51-07:00. Release status checked: `git tag --contains af16446bf` returned no release tags in the fresh checkout. GitHub repository metadata reported latest published release `…