Linux: Double Free
CVE-2022-49789 is a high-severity double free vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd, d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab, 11edbdee4399401f533adda9bffe94567aa08b96 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.2% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd or d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab or 11edbdee4399401f533adda9bffe94567aa08b96 or 90a49a6b015fa439cd62e45121390284c125a91f, whichever matches your release line, or a later version.
- Update Linux Kernel to 5.4.225 or 5.10.156 or 5.15.80 or 6.0.10, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 up to, but not including, 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd; e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 up to, but not including, d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab; e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 up to, but not including, 11edbdee4399401f533adda9bffe94567aa08b96; e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 up to, but not including, 90a49a6b015fa439cd62e45121390284c125a91f; e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934 up to, but not including, 0954256e970ecf371b03a6c9af2cf91b9c4085ff; 2.6.34 | 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd, d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab, 11edbdee4399401f533adda9bffe94567aa08b96, 90a49a6b015fa439cd62e45121390284c125a91f, 0954256e970ecf371b03a6c9af2cf91b9c4085ff |
| Linux | Linux Kernel | 2.6.34 up to, but not including, 5.4.225; 5.5 up to, but not including, 5.10.156; 5.11 up to, but not including, 5.15.80; 5.16 up to, but not including, 6.0.10; 6.1 | 5.4.225, 5.10.156, 5.15.80, 6.0.10 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 3.1 | 7.0 | High | CNA |
| CVSS 3.1 | 7.8 | High | NVD |
Official description
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---
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Double Free
The product calls free() twice on the same memory address.
How developers prevent this class of flaw
- Choose a language that provides automatic memory management.
- Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.
- Use a static analysis tool to find double free instances.
Timeline
- CVE record published.
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
- git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff
- git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96
- git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd
- git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f
- git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab
Recent Double Free vulnerabilities
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
Spotted an error? Tell us.