CVE-2025-22083 (GCVE-0-2025-22083)
Vulnerability from cvelistv5
Published
2025-04-16 14:12
Modified
2026-08-05 11:56
Summary
In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.
Impacted products
Vendor Product Version
Linux Linux Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Version: 4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "affected": [
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-14T12:40:44.581Z",
          "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
          "shortName": "siemens-SADP"
        },
        "references": [
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
          }
        ],
        "x_adpType": "supplier"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/vhost/scsi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "451c72f5e7cf5d339a6410a635cee0825687c3dc",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            },
            {
              "lessThan": "2b34bdc42df047794542f3e220fe989124e4499a",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            },
            {
              "lessThan": "3a19eb3d9818e28f14c818a18dc913344a52ca92",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            },
            {
              "lessThan": "3fd054baf382a426bbf5135ede0fc5673db74d3e",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            },
            {
              "lessThan": "63b449f73ab0dcc0ba11ceaa4c5c70bc86ccf03c",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            },
            {
              "lessThan": "5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6",
              "status": "affected",
              "version": "4f7f46d32c9875004fae1d57ae3c02cc2e6cd6a3",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/vhost/scsi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.9"
            },
            {
              "lessThan": "3.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.162",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.87",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.23",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.162",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.87",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.23",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.11",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.2",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "versionStartIncluding": "3.9",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u003evs_tpg);\nvs-\u003evs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u003evs_tpg);\nvs-\u003evs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u003e vhost_scsi_get_req -\u003e vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u003evs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u003evs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u003evs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0027t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0027t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u003evs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0027s\nname and we will only match that target\u0027s tpgs when we loop over the\nvs-\u003evs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0027s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The vulnerability is reached exclusively through the `VHOST_SCSI_SET_ENDPOINT` ioctl on the local `/dev/vhost-scsi` misc device, followed by virtqueue submission on the same open fd. There is no network-facing path \u2014 a guest can index the freed array but cannot itself perform the ioctl that frees it.\nAC:L - Triggering is fully deterministic and race-free: one successful `SET_ENDPOINT` followed by a second `SET_ENDPOINT` with a wwpn matching no tpg unconditionally frees the array still installed as the vq backend. Heap-spraying the freed 2048-byte kmalloc-2k object is standard and entirely under the attacker\u0027s control.\nPR:L - Neither `vhost_scsi_open()`, `vhost_scsi_ioctl()`, nor the vhost core performs any `capable()`/`CAP_*` check \u2014 only an open fd on `/dev/vhost-scsi` is needed, which the unprivileged QEMU/libvirt-qemu process routinely holds in any host actually using vhost-scsi. A compromised or malicious deprivileged VMM process reaches the bug with a single additional ioctl, so no real root is required.\nUI:N - The attacker performs both ioctls and the subsequent virtqueue kick entirely on its own; no action by any other user or administrator is needed. The LIO tpg configuration is pre-existing baseline state in any vhost-scsi deployment, not a victim action.\nS:U - The dangling backend and corrupted heap are host kernel memory, and the attacker is already a host-local process, so the compromise stays within the kernel\u0027s own security authority. This is standard local kernel privilege escalation rather than a VM-escape or IOMMU boundary crossing.\nC:H - `vhost_scsi_get_req()` performs `READ_ONCE(vs_tpg[*vc-\u003etarget])` on the freed array with an attacker-chosen index, then downstream code dereferences the resulting pointer, giving a use-after-free read that can be steered into arbitrary kernel memory disclosure. Per UAF guidance the attacker controls the contents of the reclaimed slab object, enabling arbitrary read.\nI:H - Reclaiming the freed kmalloc-2k object yields a fully attacker-controlled `struct vhost_scsi_tpg *` that is dereferenced and whose `tpg_nexus-\u003etvn_se_sess` is passed into `target_init_cmd()`/`target_submit_tmr()`, a classic fake-object path to arbitrary write and control-flow hijack. The configfs `config_item` refcount underflow to \u22121 additionally corrupts target-core object lifetime state.\nA:H - The dangling backend reliably produces a kernel oops/panic on the next SCSI request even without successful exploitation. The refcount underflow also permanently wedges the LIO tpg so `rmdir` on the tpg/target directory hangs and the objects can never be removed short of reboot."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:56:37.788Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/451c72f5e7cf5d339a6410a635cee0825687c3dc"
        },
        {
          "url": "https://git.kernel.org/stable/c/2b34bdc42df047794542f3e220fe989124e4499a"
        },
        {
          "url": "https://git.kernel.org/stable/c/3a19eb3d9818e28f14c818a18dc913344a52ca92"
        },
        {
          "url": "https://git.kernel.org/stable/c/3fd054baf382a426bbf5135ede0fc5673db74d3e"
        },
        {
          "url": "https://git.kernel.org/stable/c/63b449f73ab0dcc0ba11ceaa4c5c70bc86ccf03c"
        },
        {
          "url": "https://git.kernel.org/stable/c/5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6"
        }
      ],
      "title": "vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-22083",
    "datePublished": "2025-04-16T14:12:32.291Z",
    "dateReserved": "2024-12-29T08:45:45.816Z",
    "dateUpdated": "2026-08-05T11:56:37.788Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…