[SRU][J][PATCH 0/1] CVE-2025-22083

[Cengiz Can]

https://ubuntu.com/security/CVE-2025-22083

[ Impact ]

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.

[ Fix ]

jammy/linux: backported from 5dd639a1646e

[ Test Plan ]

Build and boot tested.

[ Where Problems Could Occur ]

A bad fix would affect virtualization hosts that use the vhost-scsi driver to
present SCSI storage to KVM/QEMU guests, and only when userspace configures
the endpoint via the VHOST_SCSI_SET_ENDPOINT ioctl; a regression could reject
a legitimate first-time endpoint setup or break clear/re-setup sequences, so
affected guests may fail to attach their vhost-scsi storage. Hosts and guests
that do not use vhost-scsi, and setups that never issue this ioctl more than
once, are not affected.

[ Other Info ]

Kybele flow-v11-25-ga27c0fa6. Reference: 3c00f234/v1