cbcvebase.
CVE-2022-49789
published 2025-05-01

CVE-2022-49789: In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong…

PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.18%
8.4th percentile
In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale

Affected

16 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.0.10-1 (bookworm)linux 6.0.10-1 (bookworm)
linuxlinux——
linuxlinux>= e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 < 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd1bf8ed585501bb2dd0b5f67c824eab45adfbdccd
linuxlinux>= e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 < d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0abd2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab
linuxlinux>= e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 < 11edbdee4399401f533adda9bffe94567aa08b9611edbdee4399401f533adda9bffe94567aa08b96
linuxlinux>= e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 < 90a49a6b015fa439cd62e45121390284c125a91f90a49a6b015fa439cd62e45121390284c125a91f
linuxlinux>= e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 < 0954256e970ecf371b03a6c9af2cf91b9c4085ff0954256e970ecf371b03a6c9af2cf91b9c4085ff
linuxlinux_kernel——
linuxlinux_kernel>= 0 < 5.10.158-15.10.158-1
linuxlinux_kernel>= 0 < 6.0.10-16.0.10-1
linuxlinux_kernel>= 0 < 6.0.10-16.0.10-1
linuxlinux_kernel>= 0 < 6.0.10-16.0.10-1
linuxlinux_kernel>= 2.6.34 < 5.4.2255.4.225
linuxlinux_kernel>= 5.11 < 5.15.805.15.80
linuxlinux_kernel>= 5.16 < 6.0.106.0.10
linuxlinux_kernel>= 5.5 < 5.10.1565.10.156

CVSS provenance

nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.