CWE-617

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-20",
      "CWE-617",
      "CWE-639",
      "CWE-668",
      "CWE-704"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:42:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Affected\n\n- **Ecosystem / package:** pip / `vllm`\n- **Affected versions:** vLLM \u2264 0.25.1 (confirmed on 0.25.1, commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34)). The lower bound predates 0.25.1; maintainers can confirm how far back the scale-out transport path reaches.\n\n## Summary\n\nvLLM\u0027s disaggregated **scale-out** transport splits a multimodal request into a trusted render step (`POST /v1/chat/completions/render`) and a separate generate step (`POST /inference/v1/generate`). The generate route decodes a caller-supplied `features` object \u2014 serialized encoder tensors (`kwargs_data`), multimodal hashes (`mm_hashes`), placeholder ranges (`mm_placeholders`), and the internal field-processor selection \u2014 and forwards it into the engine **as if it had come from the trusted renderer**, with no rebinding to (or validation against) the active model\u0027s renderer contract. Because the two routes are ordinary auth-guarded HTTP endpoints (the `/inference` prefix is registered by default on generate-capable servers), any authenticated caller can submit an otherwise-valid render body with a single forged field.\n\nDepending on which field is forged, this produces:\n\n- an **engine-fatal crash** of the shared EngineCore process (denial of service), reproduced as a CUDA illegal-memory-access, a post-admission rank-mismatch `ValueError`, and a hard `assert` \u2014 three independent forged fields (sites 1, 2, 3);\n- **silent cross-request encoder-cache poisoning / disclosure** of shared encoder state when the cache-key hash is not bound to the payload (site 4);\n- **transport-level integrity loss** when sparse placeholder masks are dropped during render-to-generate replay (site 5).\n\nAll five share one root cause and one fix shape: the reconstructed multimodal state on the scale-out path is trusted without being rebound to, and validated against, the active model\u0027s renderer output before it reaches the engine.\n\nThese sites are distinct from prior multimodal hardening. Site 1 survives [GHSA-wv77-2vpf-vmmg](https://github.com/vllm-project/vllm/security/advisories/GHSA-wv77-2vpf-vmmg) (that fix validates full tensor shape in `MultiModalDataParser`/`get_input_embeddings` on the prompt-embeds path), because our request forges `image_grid_thw` metadata with the pixel bytes intact and reaches the Qwen2 vision RoPE/`cu_seqlens` and `image_embeds.split` sink, which the shape-check fix does not rebind. Site 4 is distinct from [GHSA-c65p-x677-fgj6](https://github.com/vllm-project/vllm/security/advisories/GHSA-c65p-x677-fgj6) (which folds metadata into `MultiModalHasher.serialize_item` to stop hash collisions), because the scale-out generate path trusts a caller-supplied `mm_hash` as the cache key with no origin binding, so that fix does not stop a caller from submitting a victim\u0027s hash or a `kwargs_data=None` cache read.\n\n## Affected code\n\nLinks pinned to the confirmed commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34) (v0.25.1).\n\nShared entry point and control surface for all five sites:\n\n- `POST /inference/v1/generate` route: [`vllm/entrypoints/scale_out/token_in_token_out/api_router.py#L46-L75`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/api_router.py#L46-L75).\n- Public `features` schema (`kwargs_data`, `mm_hashes`, `mm_placeholders`): [`vllm/entrypoints/scale_out/token_in_token_out/protocol.py#L42-L63`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/protocol.py#L42-L63).\n- `ServingTokens.serve_tokens()` copies the decoded geometry and hashes into engine structures without rebinding to the renderer schema: [`vllm/entrypoints/scale_out/token_in_token_out/serving.py#L145-L172`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/serving.py#L145-L172).\n- The scale-out routers are registered by default on generate-capable servers and `/inference` is treated as an ordinary auth-guarded prefix: [`vllm/entrypoints/openai/api_server.py#L217-L219`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/api_server.py#L217-L219).\n\n**Site 1 \u2014 forged Qwen grid geometry (engine-fatal DoS).** The decoded `image_grid_thw` is never rebound to the rendered pixel-tensor element count.\n\n- Reconstruction with no model-specific geometry invariant: [`serving.py#L147-L172`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/serving.py#L147-L172).\n- `Qwen2VisionTransformer.prepare_encoder_metadata()` derives RoPE tables, `cu_seqlens`, and the FlashAttention `max_seqlen` from the caller-supplied grid: [`qwen2_vl.py#L658-L712`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L658-L712), consumed in [`forward()` (`#L713-L751`)](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L713-L751).\n- `_process_image_input()` computes `image_embeds.split(sizes)` from the same untrusted metadata: [`qwen2_vl.py#L1348-L1369`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L1348-L1369); M-RoPE positions at [`qwen2_vl.py#L1223`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L1223).\n\nThe only shape check is `assert grid_thw.ndim == 2`; the split sizes and the vision-encoder call are then derived directly from the caller-supplied grid, with no cross-check against the pixel-tensor row count:\n\n```python\n# vllm/model_executor/models/qwen2_vl.py Lines 1348-1369\n    def _process_image_input(\n        self, image_input: Qwen2VLImageInputs\n    ) -\u003e tuple[torch.Tensor, ...]:\n        grid_thw = image_input[\"image_grid_thw\"]\n        assert grid_thw.ndim == 2\n\n        if image_input[\"type\"] == \"image_embeds\":\n            image_embeds = image_input[\"image_embeds\"]\n        else:\n            pixel_values = image_input[\"pixel_values\"]\n\n            if self.use_data_parallel:\n                return run_dp_sharded_mrope_vision_model(\n                    self.visual, pixel_values, grid_thw.tolist(), rope_type=\"rope_3d\"\n                )\n            else:\n                image_embeds = self.visual(pixel_values, grid_thw=grid_thw)\n\n        # Split concatenated embeddings for each image item.\n        merge_size = self.visual.spatial_merge_size\n        sizes = (grid_thw.prod(-1) // merge_size // merge_size).tolist()\n        return image_embeds.split(sizes)\n```\n\n**Site 2 \u2014 wire-selected field-processor type confusion (engine-fatal DoS).** `MsgpackDecoder._decode_mm_field_elem()` trusts a wire-selected field-factory name and constructs the internal field processor directly from caller data.\n\n- [`vllm/v1/serial_utils.py#L440-L454`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/serial_utils.py#L440-L454) reads `factory_meth_name, factory_kw = obj[\"field\"]` and calls `getattr(MultiModalFieldConfig, factory_meth_name)`.\n- Qwen2-VL field/schema contract: [`qwen2_vl.py#L763-L791`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L763-L791) and [`Qwen2VLImagePixelInputs` (`#L119-L144`)](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L119-L144); parse/validate at [`qwen2_vl.py#L1300`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/model_executor/models/qwen2_vl.py#L1300).\n- Rank mismatch raised post-admission: [`vllm/utils/tensor_schema.py#L155-L171`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/utils/tensor_schema.py#L155-L171), reached from [`TensorSchema.__init__` \u2192 `validate()` (`#L63`)](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/utils/tensor_schema.py#L63).\n\n**Site 3 \u2014 non-positive placeholder length (engine-fatal DoS via reachable assert).** `PlaceholderRangeInfo{offset,length}` is accepted as unconstrained integers and copied verbatim into the engine\u0027s `PlaceholderRange`.\n\n- Schema: [`protocol.py#L28-L35`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/protocol.py#L28-L35).\n- Copied into `PlaceholderRange`: [`serving.py#L147-L153`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/serving.py#L147-L153).\n- The only guard is an upper bound on embed count (`num_embeds \u003e mm_encoder_cache_size`), with no non-positive check: [`vllm/v1/engine/input_processor.py#L459-L464`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/input_processor.py#L459-L464); raw length returned by [`vllm/multimodal/inputs.py#L152-L154`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/multimodal/inputs.py#L152-L154); window selection assumes non-empty ranges at [`vllm/multimodal/utils.py#L114-L134`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/multimodal/utils.py#L114-L134).\n- Sink: `assert start_idx \u003c end_idx` at [`vllm/v1/worker/gpu/mm/encoder_runner.py#L114`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/worker/gpu/mm/encoder_runner.py#L114) (duplicated at [`vllm/v1/worker/gpu_model_runner.py#L3192`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/worker/gpu_model_runner.py#L3192)); turned into a fatal shutdown by EngineCore\u0027s uncaught-exception path at [`vllm/v1/engine/core.py#L1229-L1233`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/core.py#L1229-L1233).\n\nA `length` of `0` makes `num_encoder_tokens == 0`, so `end_idx` collapses to `0` and the bare `assert` fires inside the engine worker:\n\n```python\n# vllm/v1/worker/gpu/mm/encoder_runner.py Lines 108-114\n                pos_info = mm_feature.mm_position\n                start_pos = pos_info.offset\n                num_encoder_tokens = pos_info.length\n\n                start_idx = max(cur_query_start - start_pos, 0)\n                end_idx = min(cur_query_end - start_pos, num_encoder_tokens)\n                assert start_idx \u003c end_idx\n```\n\n**Site 4 \u2014 cache hash not bound to payload (integrity / disclosure).** `features.mm_hashes` (the cache key) and `kwargs_data` (the tensor) are independent fields with no origin or integrity binding.\n\n- Schema exposing the caller-controlled hash and the `None` = resolve-from-cache semantics: [`protocol.py#L42-L63`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/protocol.py#L42-L63).\n- Handler forwards the caller\u0027s hashes unchanged into `mm_input(...)`: [`serving.py#L164-L170`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/serving.py#L164-L170).\n- Input processing copies the caller hash into the feature identifier with only a string-type check: [`vllm/v1/engine/input_processor.py#L165-L181`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/input_processor.py#L165-L181).\n- Sink \u2014 the receiver cache returns the cached tensor solely by that key (`cache_key = feature.mm_hash or feature.identifier`): [`vllm/multimodal/cache.py#L602-L607`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/multimodal/cache.py#L602-L607).\n\nThe cache key is the caller-supplied hash with no verification against the tensor bytes, so a forged `mm_hash` both stores under and reads back another request\u0027s slot:\n\n```python\n# vllm/multimodal/cache.py Lines 601-607\n        for feature in mm_features:\n            cache_key = feature.mm_hash or feature.identifier\n            self.touch_receiver_cache_item(cache_key, feature.data)\n\n        for feature in mm_features:\n            cache_key = feature.mm_hash or feature.identifier\n            feature.data = self.get_and_update_item(feature.data, cache_key)\n        return mm_features\n```\n\n**Site 5 \u2014 dropped sparse placeholder mask (transport integrity loss).** The render path serializes placeholders as only `offset`/`length`, so models relying on sparse `is_embed` masks lose the mask during render-to-generate replay.\n\n- `ServingRender._extract_mm_features()` builds each `PlaceholderRangeInfo(offset=p.offset, length=p.length)`, discarding `is_embed`: [`vllm/entrypoints/scale_out/render/serving.py#L212-L229`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/render/serving.py#L212-L229).\n- Transport schema carries no field for the mask: [`protocol.py#L28`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/protocol.py#L28).\n- `ServingTokens.serve_tokens()` reconstructs a dense `PlaceholderRange` regardless of the original: [`serving.py#L148-L152`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/scale_out/token_in_token_out/serving.py#L148-L152).\n\n## Impact\n\nA single authenticated request to a scale-out multimodal deployment can:\n\n- **Crash the shared EngineCore process** (sites 1, 2, 3), taking the served model down for every tenant (`/health` \u2192 503). Availability-only; no code execution or data disclosure demonstrated for these sites.\n- **Silently poison or read back another request\u0027s shared encoder-cache state** (site 4) \u2014 an integrity/disclosure primitive. Attack complexity is High because the attacker must know or induce the victim\u0027s content hash; there is no availability impact for this site.\n- **Corrupt backend-visible placeholder semantics across the render-to-generate boundary** (site 5) for models that depend on sparse `is_embed` masks.\n\nThe forged multimodal payload is small; only the trust in its self-declared geometry/identity is the defect.\n\n\n## Suggested Fix\n\nOn the scale-out path, do not trust caller-supplied multimodal state as renderer-produced. After decoding `features`, **rebind and validate** the reconstructed `MultiModalKwargsItem` against the active model\u0027s renderer contract at the HTTP boundary:\n\n1. Reject any request whose decoded grid geometry is inconsistent with the rendered pixel-tensor element count and declared placeholder span, before it reaches `prepare_encoder_metadata()` (site 1).\n2. Rebind each field\u0027s processor type to the schema the active model\u0027s renderer declares (or reject if it differs), instead of reconstructing internal field processors from wire-selected factory names (site 2).\n3. Reject any `PlaceholderRangeInfo` with `length \u003c= 0` (or out-of-range `offset`) with a request-scoped 4xx, and convert the encoder-runner invariant into a checked, request-scoped error rather than a process-fatal `assert` (site 3).\n4. Recompute or verify the content hash for submitted `kwargs_data` before using it as a cache key, and namespace receiver-cache keys to a server-generated or principal scope, refusing cache-reads for hashes the caller did not legitimately produce (site 4).\n5. Serialize `is_embed` in `PlaceholderRangeInfo`, validate its length against the placeholder span, and reconstruct it on replay (site 5).\n\n**Site 1 \u2014 validate grid geometry before the vision encoder.** Replace the bare `assert grid_thw.ndim == 2` in `_process_image_input()`/`_process_video_input()` with a shared helper that recomputes the split sizes and rejects a grid whose patch-row count does not match the pixel tensor (and rejects non-positive / non-merge-divisible dims), so the mismatch never reaches `image_embeds.split()`:\n\n```python\n# vllm/model_executor/models/qwen2_vl.py \u2014 _process_image_input()\n-        grid_thw = image_input[\"image_grid_thw\"]\n-        assert grid_thw.ndim == 2\n+        grid_thw = image_input[\"image_grid_thw\"]\n+        input_type = image_input[\"type\"]\n+        input_tensor = (\n+            image_input[\"image_embeds\"]\n+            if input_type == \"image_embeds\"\n+            else image_input[\"pixel_values\"]\n+        )\n+        sizes = _validate_qwen2_vl_input_geometry(\n+            modality=\"image\",\n+            input_type=input_type,\n+            input_tensor=input_tensor,\n+            grid_thw=grid_thw,\n+            spatial_merge_size=self.visual.spatial_merge_size,\n+        )\n...\n-        # Split concatenated embeddings for each image item.\n-        merge_size = self.visual.spatial_merge_size\n-        sizes = (grid_thw.prod(-1) // merge_size // merge_size).tolist()\n         return image_embeds.split(sizes)\n```\n\nwhere the helper raises before the encoder runs:\n\n```python\n# vllm/model_executor/models/qwen2_vl.py \u2014 new _validate_qwen2_vl_input_geometry()\n        if t \u003c= 0 or h \u003c= 0 or w \u003c= 0:\n            raise ValueError(f\"{modality} grid_thw row {index} must be positive ...\")\n        if h % spatial_merge_size != 0 or w % spatial_merge_size != 0:\n            raise ValueError(f\"{modality} grid_thw row {index} must be divisible ...\")\n        ...\n        if actual_rows != expected_rows:\n            raise ValueError(\n                f\"{modality} {row_kind} do not match grid_thw: \"\n                f\"expected {expected_rows}, got {actual_rows}.\"\n            )\n```\n\n**Site 3 \u2014 constrain the placeholder schema.** Make `PlaceholderRangeInfo` reject non-positive lengths and negative offsets at the Pydantic boundary (plus parallel-length, non-overlapping, and within-prompt validators), turning the process-fatal `assert` into a request-scoped 422:\n\n```python\n# vllm/entrypoints/scale_out/token_in_token_out/protocol.py \u2014 PlaceholderRangeInfo\n-    offset: int\n-    length: int\n+    offset: int = Field(ge=0)\n+    length: int = Field(gt=0)\n```\n\n**Site 4 \u2014 bind the cache key to the payload.** Derive each cache key by hashing the submitted serialized tensor (ignoring the caller\u0027s `mm_hashes`) and refuse cache-only reads, so a forged hash can neither poison nor read a victim\u0027s slot:\n\n```python\n# vllm/entrypoints/scale_out/token_in_token_out/serving.py \u2014 serve_tokens()\n+            mm_hashes = _bind_mm_hashes_to_kwargs_data(\n+                features.mm_hashes, features.kwargs_data,\n+            )\n             engine_input = mm_input(\n                 prompt_token_ids=request.token_ids,\n                 mm_kwargs=MultiModalKwargsItems(mm_kwargs),\n-                mm_hashes=features.mm_hashes,\n+                mm_hashes=mm_hashes,\n                 mm_placeholders=mm_placeholders,\n                 cache_salt=request.cache_salt,\n             )\n```\n\nwhere `_bind_mm_hashes_to_kwargs_data()` raises on `kwargs_data is None` (cache-only read) and derives `sha256(modality || \"\\0\" || serialized_item)` per item. Site 2 applies the same rebind-to-declared-schema pattern in `mm_serde.py` (passing `modality` + `mm_processor` into `decode_mm_kwargs_item`), and site 5 adds an `is_embed` field to `PlaceholderRangeInfo` with `from_placeholder_range`/`to_placeholder_range` helpers so the sparse mask survives render-to-generate replay. Each site fix ships with a regression test. This packet groups the five sites because they share one entry point (`/inference/v1/generate` + `/render`) and one root cause; we are happy to split it into per-component advisories (for example, engine-fatal input-validation vs. cache-key binding vs. transport-schema integrity) if the vLLM team prefers.\n\n## Credit\n\n**Reported by:** Patch the Planet (Trail of Bits + OpenAI collaboration)\n\nThese vulnerabilities were discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.\n\n---\n\n**Proposed fix:** a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51898",
  "id": "GHSA-ph72-cqr5-qpp7",
  "modified": "2026-10-05T23:42:50Z",
  "published": "2026-10-05T23:42:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-ph72-cqr5-qpp7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/51898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/1970f3ed4be7fa8620e4ddc4a12c36a8384cfc27"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/releases/tag/v0.30.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: Scale-out disaggregated multimodal transport trusts caller-supplied features"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-18T19:46:06Z",
    "nvd_published_at": "2021-05-14T20:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\nAn attacker can cause a denial of service by exploiting a `CHECK`-failure coming from the implementation of `tf.raw_ops.RFFT`:\n    \n```python\nimport tensorflow as tf\n\ninputs = tf.constant([1], shape=[1], dtype=tf.float32)\nfft_length = tf.constant([0], shape=[1], dtype=tf.int32)\n\ntf.raw_ops.RFFT(input=inputs, fft_length=fft_length)\n```\n\nThe above example causes Eigen code to operate on an empty matrix. This triggers on an assertion and causes program termination.\n    \n### Patches\nWe have patched the issue in GitHub commit [31bd5026304677faa8a0b77602c6154171b9aec1](https://github.com/tensorflow/tensorflow/commit/31bd5026304677faa8a0b77602c6154171b9aec1).\n\nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. \n\n### Attribution\nThis vulnerability has been reported by Yakun Zhang and Ying Wang of Baidu X-Team.",
  "id": "GHSA-ph87-fvjr-v33w",
  "modified": "2024-11-01T16:55:05Z",
  "published": "2021-05-21T14:25:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-ph87-fvjr-v33w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29563"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/31bd5026304677faa8a0b77602c6154171b9aec1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-491.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-689.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-200.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CHECK-fail in `tf.raw_ops.RFFT`"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-38503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-16T11:15:42Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion when building free space tree\n\nWhen building the free space tree with the block group tree feature\nenabled, we can hit an assertion failure like this:\n\n  BTRFS info (device loop0 state M): rebuilding free space tree\n  assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/free-space-tree.c:1102!\n  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  sp : ffff8000a4ce7600\n  x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8\n  x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001\n  x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160\n  x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff\n  x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0\n  x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff\n  x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00\n  x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001\n  x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0\n  x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e\n  Call trace:\n   populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)\n   btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337\n   btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n   btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n   btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n   reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n   do_remount fs/namespace.c:3365 [inline]\n   path_mount+0xb34/0xde0 fs/namespace.c:4200\n   do_mount fs/namespace.c:4221 [inline]\n   __do_sys_mount fs/namespace.c:4432 [inline]\n   __se_sys_mount fs/namespace.c:4409 [inline]\n   __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n   el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n   el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n  Code: f0047182 91178042 528089c3 9771d47b (d4210000)\n  ---[ end trace 0000000000000000 ]---\n\nThis happens because we are processing an empty block group, which has\nno extents allocated from it, there are no items for this block group,\nincluding the block group item since block group items are stored in a\ndedicated tree when using the block group tree feature. It also means\nthis is the block group with the highest start offset, so there are no\nhigher keys in the extent root, hence btrfs_search_slot_for_read()\nreturns 1 (no higher key found).\n\nFix this by asserting \u0027ret\u0027 is 0 only if the block group tree feature\nis not enabled, in which case we should find a block group item for\nthe block group since it\u0027s stored in the extent root and block group\nitem keys are greater than extent item keys (the value for\nBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and\nBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).\nIn case \u0027ret\u0027 is 1, we just need to add a record to the free space\ntree which spans the whole block group, and we can achieve this by\nmaking \u0027ret == 0\u0027 as the while loop\u0027s condition.",
  "id": "GHSA-pm7p-wjq9-6m43",
  "modified": "2026-01-22T18:50:53Z",
  "published": "2025-08-16T12:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38503"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0bcc14f36c7ad37121cf5c0ae18cdde5bfad9c4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1961d20f6fa8903266ed9bd77c691924c22c8f02"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6bbe6530b1db7b4365ce9e86144c18c5d73b2c5b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c77df23324f60bcff0ea44392e2c82e9486640c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f4428b2d4c68732653e93f748f538bdee639ff80"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-49154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: fix panic on out-of-bounds guest IRQ\n\nAs guest_irq is coming from KVM_IRQFD API call, it may trigger\ncrash in svm_update_pi_irte() due to out-of-bounds:\n\ncrash\u003e bt\nPID: 22218  TASK: ffff951a6ad74980  CPU: 73  COMMAND: \"vcpu8\"\n #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397\n #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d\n #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d\n #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d\n #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9\n #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51\n #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace\n    [exception RIP: svm_update_pi_irte+227]\n    RIP: ffffffffc0761b53  RSP: ffffb1ba6707fd08  RFLAGS: 00010086\n    RAX: ffffb1ba6707fd78  RBX: ffffb1ba66d91000  RCX: 0000000000000001\n    RDX: 00003c803f63f1c0  RSI: 000000000000019a  RDI: ffffb1ba66db2ab8\n    RBP: 000000000000019a   R8: 0000000000000040   R9: ffff94ca41b82200\n    R10: ffffffffffffffcf  R11: 0000000000000001  R12: 0000000000000001\n    R13: 0000000000000001  R14: ffffffffffffffcf  R15: 000000000000005f\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm]\n #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm]\n #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm]\n    RIP: 00007f143c36488b  RSP: 00007f143a4e04b8  RFLAGS: 00000246\n    RAX: ffffffffffffffda  RBX: 00007f05780041d0  RCX: 00007f143c36488b\n    RDX: 00007f05780041d0  RSI: 000000004008ae6a  RDI: 0000000000000020\n    RBP: 00000000000004e8   R8: 0000000000000008   R9: 00007f05780041e0\n    R10: 00007f0578004560  R11: 0000000000000246  R12: 00000000000004e0\n    R13: 000000000000001a  R14: 00007f1424001c60  R15: 00007f0578003bc0\n    ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b\n\nVmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on\nout-of-bounds guest IRQ), so we can just copy source from that to fix\nthis.",
  "id": "GHSA-pmg5-cqg9-w979",
  "modified": "2025-09-23T15:31:07Z",
  "published": "2025-09-23T15:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49154"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0fb470eb48892e131d10aa3be6915239e65758f3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3fa2d747960521a646fc1aad7aea82e95e139a68"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6ffdebfb6a9c2ffeed902b544b96fe67498210e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a80ced6ea514000d34bf1239d47553de0d1ee89e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e4d153d53d9648513481eb4ef8c212e7f1f8173d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-46705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-05T15:15:38Z",
    "severity": "CRITICAL"
  },
  "details": "A denial of service vulnerability exists in the g_assert_not_reached functionality of Entr\u0026#39;ouvert Lasso 2.5.1 and 2.8.2. A specially crafted SAML assertion response can lead to a denial of service. An attacker can send a malformed SAML response to trigger this vulnerability.",
  "id": "GHSA-pmj8-xcc6-hfrp",
  "modified": "2025-11-05T17:48:28Z",
  "published": "2025-11-05T15:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46705"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2196"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2196"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-52621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-26T18:15:08Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() before calling bpf map helpers\n\nThese three bpf_map_{lookup,update,delete}_elem() helpers are also\navailable for sleepable bpf program, so add the corresponding lock\nassertion for sleepable bpf program, otherwise the following warning\nwill be reported when a sleepable bpf program manipulates bpf map under\ninterpreter mode (aka bpf_jit_enable=0):\n\n  WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......\n  CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......\n  RIP: 0010:bpf_map_lookup_elem+0x54/0x60\n  ......\n  Call Trace:\n   \u003cTASK\u003e\n   ? __warn+0xa5/0x240\n   ? bpf_map_lookup_elem+0x54/0x60\n   ? report_bug+0x1ba/0x1f0\n   ? handle_bug+0x40/0x80\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1b/0x20\n   ? __pfx_bpf_map_lookup_elem+0x10/0x10\n   ? rcu_lockdep_current_cpu_online+0x65/0xb0\n   ? rcu_is_watching+0x23/0x50\n   ? bpf_map_lookup_elem+0x54/0x60\n   ? __pfx_bpf_map_lookup_elem+0x10/0x10\n   ___bpf_prog_run+0x513/0x3b70\n   __bpf_prog_run32+0x9d/0xd0\n   ? __bpf_prog_enter_sleepable_recur+0xad/0x120\n   ? __bpf_prog_enter_sleepable_recur+0x3e/0x120\n   bpf_trampoline_6442580665+0x4d/0x1000\n   __x64_sys_getpgid+0x5/0x30\n   ? do_syscall_64+0x36/0xb0\n   entry_SYSCALL_64_after_hwframe+0x6e/0x76\n   \u003c/TASK\u003e",
  "id": "GHSA-pmx2-4vwx-fc3h",
  "modified": "2025-11-03T21:31:01Z",
  "published": "2024-03-26T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52621"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-9749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T23:17:04Z",
    "severity": "HIGH"
  },
  "details": "This issue can occur when running an aggregation pipeline that uses the internal $exchange stage configured with key-range partitioning and order-preserving delivery. If a single key range produces enough documents to fill its exchange buffer (that is, many results are routed to the same consumer), the server reaches the code path where a full per-consumer buffer is detected but the internal \"high watermark\" for that key range is not updated as intended.",
  "id": "GHSA-ppxc-fr36-g8v9",
  "modified": "2026-06-10T00:31:50Z",
  "published": "2026-06-10T00:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9749"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-124031"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-3488"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-26T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Processing of repeated responses to the same query, where both responses contain ECS pseudo-options, but where the first is broken in some way, can cause BIND to exit with an assertion failure. \u0027Broken\u0027 in this context is anything that would cause the resolver to reject the query response, such as a mismatch between query and answer name. This issue affects BIND 9 versions 9.11.4-S1 through 9.11.37-S1 and 9.16.8-S1 through 9.16.36-S1.",
  "id": "GHSA-pq6j-95q4-4mhj",
  "modified": "2023-02-03T18:30:23Z",
  "published": "2023-01-26T21:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3488"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2022-3488"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-49347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix bug_on in ext4_writepages\n\nwe got issue as follows:\nEXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls\n------------[ cut here ]------------\nkernel BUG at fs/ext4/inode.c:2708!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155\nRIP: 0010:ext4_writepages+0x1977/0x1c10\nRSP: 0018:ffff88811d3e7880 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000\nRDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002\nRBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000\nR10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001\nR13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028\nFS:  00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n do_writepages+0x130/0x3a0\n filemap_fdatawrite_wbc+0x83/0xa0\n filemap_flush+0xab/0xe0\n ext4_alloc_da_blocks+0x51/0x120\n __ext4_ioctl+0x1534/0x3210\n __x64_sys_ioctl+0x12c/0x170\n do_syscall_64+0x3b/0x90\n\nIt may happen as follows:\n1. write inline_data inode\nvfs_write\n  new_sync_write\n    ext4_file_write_iter\n      ext4_buffered_write_iter\n        generic_perform_write\n          ext4_da_write_begin\n            ext4_da_write_inline_data_begin -\u003e If inline data size too\n            small will allocate block to write, then mapping will has\n            dirty page\n                ext4_da_convert_inline_data_to_extent -\u003eclear EXT4_STATE_MAY_INLINE_DATA\n2. fallocate\ndo_vfs_ioctl\n  ioctl_preallocate\n    vfs_fallocate\n      ext4_fallocate\n        ext4_convert_inline_data\n          ext4_convert_inline_data_nolock\n            ext4_map_blocks -\u003e fail will goto restore data\n            ext4_restore_inline_data\n              ext4_create_inline_data\n              ext4_write_inline_data\n              ext4_set_inode_state -\u003e set inode EXT4_STATE_MAY_INLINE_DATA\n3. writepages\n__ext4_ioctl\n  ext4_alloc_da_blocks\n    filemap_flush\n      filemap_fdatawrite_wbc\n        do_writepages\n          ext4_writepages\n            if (ext4_has_inline_data(inode))\n              BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))\n\nThe root cause of this issue is we destory inline data until call\next4_writepages under delay allocation mode.  But there maybe already\nconvert from inline to extent.  To solve this issue, we call\nfilemap_flush first..",
  "id": "GHSA-pqc9-xfp2-368x",
  "modified": "2025-09-22T21:30:16Z",
  "published": "2025-09-22T21:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49347"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-33043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-05T03:15:11Z",
    "severity": "HIGH"
  },
  "details": "Transient DOS in Modem when a Beam switch request is made with a non-configured BWP.",
  "id": "GHSA-pqhc-9r4h-w7g3",
  "modified": "2023-12-05T03:30:22Z",
  "published": "2023-12-05T03:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33043"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/december-2023-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}