CVE-2022-50362
MediumIn the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing.
CVSS 3.1 score
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected versions
Linux kernel versions
5.6
and later are affected. Fixed in
5.10.150,
5.15.75,
5.19.17,
6.0.3,
6.1
and their respective stable series.
References
The following references provide additional information about CVE-2022-50362 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.
-
PatchKernel patch commithttps://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79
-
PatchKernel patch commithttps://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c
-
PatchKernel patch commithttps://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888
Frequently asked questions
-
What is CVE-2022-50362?
CVE-2022-50362 is a Medium severity Linux kernel vulnerability with a CVSS score of 5.5 out of 10 . It affects Linux kernel versions from 5.6 onward and has been patched in 5.10.150, 5.15.75, 5.19.17 and others. CVE-2022-50362 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
What is the CVSS score for CVE-2022-50362?
CVE-2022-50362 has a CVSS score of 5.5 out of 10, rated Medium severity (CVSS 3.1). The vector string is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. -
Is there a patch available for CVE-2022-50362?
Yes — CVE-2022-50362 has been patched. Fixed versions include 5.10.150, 5.15.75, 5.19.17 and others. If you are running Linux kernel 5.6 or later up to the fix versions, apply the relevant patch for your kernel branch.
-
Is CVE-2022-50362 actively exploited?
No — CVE-2022-50362 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.