{"id":"CVE-2022-49789","summary":"scsi: zfcp: Fix double free of FSF request when qdio send fails","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zfcp: Fix double free of FSF request when qdio send fails\n\nWe used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache\nthe FSF request ID when sending a new FSF request. This is used in case the\nsending fails and we need to remove the request from our internal hash\ntable again (so we don't keep an invalid reference and use it when we free\nthe request again).\n\nIn 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32\nbit wide), but the rest of the zfcp code (and the firmware specification)\nhandles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x\nELF ABI]).  For one this has the obvious problem that when the ID grows\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\nwhen storing it in the cache variable and so doesn't match the original ID\nanymore.  The second less obvious problem is that even when the original ID\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\noriginal ID (0x80000000 = 2'147'483'648) we will have a mismatch when we\ncast it back to 'unsigned long'. As the cached variable is of a signed\ntype, the compiler will choose a sign-extending instruction to load the 32\nbit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once\nwe pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the\nrequest again all the leading zeros will be flipped to ones to extend the\nsign and won't match the original ID anymore (this has been observed in\npractice).\n\nIf we can't successfully remove the request from the hash table again after\n'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify\nthe adapter about new work because the adapter is already gone during\ne.g. a ChpID toggle) we will end up with a double free.  We unconditionally\nfree the request in the calling function when 'zfcp_fsf_req_send()' fails,\nbut because the request is still in the hash table we end up with a stale\nmemory reference, and once the zfcp adapter is either reset during recovery\nor shutdown we end up freeing the same memory twice.\n\nThe resulting stack traces vary depending on the kernel and have no direct\ncorrelation to the place where the bug occurs. Here are three examples that\nhave been seen in practice:\n\n  list_del corruption. next-\u003eprev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:62!\n  monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n  Modules linked in: ...\n  CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\n  Hardware name: ...\n  Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)\n             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n  Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\n             0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\n             00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\n             00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\n  Krnl Code: 00000003cbeea1e8: c020004f68a7        larl    %r2,00000003cc8d7336\n             00000003cbeea1ee: c0e50027fd65        brasl   %r14,00000003cc3e9cb8\n            #00000003cbeea1f4: af000000            mc      0,0\n            \u003e00000003cbeea1f8: c02000920440        larl    %r2,00000003cd12aa78\n             00000003cbeea1fe: c0e500289c25        brasl   %r14,00000003cc3fda48\n             00000003cbeea204: b9040043            lgr     %r4,%r3\n             00000003cbeea208: b9040051            lgr     %r5,%r1\n             00000003cbeea20c: b9040032            lgr     %r3,%r2\n  Call Trace:\n   [\u003c00000003cbeea1f8\u003e] __list_del_entry_valid+0x98/0x140\n  ([\u003c00000003cbeea1f4\u003e] __list_del_entry_valid+0x94/0x140)\n   [\u003c000003ff7ff502fe\u003e] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\n   [\u003c000003ff7ff49cd0\u003e] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\n---truncated---","modified":"2026-04-03T13:14:45.792795Z","published":"2025-05-01T14:09:21.481Z","related":["SUSE-SU-2025:01918-1","SUSE-SU-2025:01966-1","SUSE-SU-2025:01982-1","SUSE-SU-2025:01983-1","SUSE-SU-2025:01995-1","SUSE-SU-2025:02173-1","SUSE-SU-2025:02262-1"],"database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49789.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff"},{"type":"WEB","url":"https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96"},{"type":"WEB","url":"https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd"},{"type":"WEB","url":"https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49789.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49789"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934"},{"fixed":"1bf8ed585501bb2dd0b5f67c824eab45adfbdccd"},{"fixed":"d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab"},{"fixed":"11edbdee4399401f533adda9bffe94567aa08b96"},{"fixed":"90a49a6b015fa439cd62e45121390284c125a91f"},{"fixed":"0954256e970ecf371b03a6c9af2cf91b9c4085ff"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-49789.json"}}],"schema_version":"1.7.5"}