CVE-2022-49789: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-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 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 memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) 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 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated---

AI Analysis

Technical Summary

CVE-2022-49789 is a vulnerability in the Linux kernel's SCSI subsystem, specifically within the zfcp (Fibre Channel Protocol for IBM System z) driver. The flaw arises from improper handling of the FSF request ID caching in the function zfcp_fsf_req_send(). The request ID is originally an unsigned 64-bit value (unsigned long/u64) per the firmware specification and the rest of the zfcp code, but it was incorrectly cached as a signed 32-bit integer (int). This truncation and sign extension cause mismatches when the system attempts to remove the request from an internal hash table after a send failure. When zfcp_qdio_send() fails (a common occurrence when the adapter is unavailable, such as during a ChpID toggle), the system tries to remove the request from the hash table using the cached ID. Due to the mismatch, the request remains in the hash table, leading to a stale reference. Subsequently, the system unconditionally frees the request memory, and later, during adapter reset or shutdown, attempts to free the same memory again, resulting in a double free vulnerability. This double free can cause kernel memory corruption, leading to unpredictable kernel crashes, including list corruption and kernel BUGs, as observed in real-world stack traces. The vulnerability is specific to the zfcp driver used primarily on IBM System z (s390x) architectures and affects certain Linux kernel versions identified by specific commits. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations utilizing IBM System z mainframes running affected Linux kernel versions with the zfcp driver, this vulnerability poses a significant risk to system stability and availability. The double free can cause kernel panics and crashes, potentially leading to denial of service conditions. Given that System z platforms are often used in critical enterprise environments such as banking, finance, government, and large-scale data centers across Europe, the impact could be severe, disrupting mission-critical workloads. Although exploitation does not appear to allow privilege escalation or direct data compromise, the resulting instability could indirectly affect confidentiality and integrity by causing unexpected system behavior or downtime. Organizations relying on zfcp for Fibre Channel storage connectivity may experience degraded storage access or outages during adapter resets triggered by this bug. The lack of known exploits suggests limited immediate threat, but the vulnerability's nature means it could be triggered by normal hardware or driver error conditions, making it a reliability and availability concern.

Mitigation Recommendations

To mitigate this vulnerability, European organizations should prioritize updating their Linux kernels to versions where this bug is fixed, ensuring the zfcp driver correctly handles the FSF request ID as an unsigned 64-bit value. Kernel updates should be tested and deployed promptly on all affected IBM System z systems. Additionally, organizations should monitor system logs for signs of zfcp_qdio_send() failures and kernel warnings related to list corruption or double free errors. Implementing robust hardware monitoring and maintenance procedures to minimize adapter failures or ChpID toggles can reduce the likelihood of triggering this bug. Where immediate patching is not feasible, temporarily disabling or limiting use of the zfcp driver or related Fibre Channel adapters may be considered, though this could impact storage connectivity. Engaging with Linux distribution vendors and IBM support for backported patches and guidance is recommended. Finally, maintaining comprehensive backups and recovery plans is essential to mitigate potential downtime caused by kernel crashes.