CVE-2022-50362
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-17

Last updated on: 2025-12-10

Assigner: kernel.org

Description
In 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 Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-17
Last Modified
2025-12-10
Generated
2026-05-27
AI Q&A
2025-09-17
EPSS Evaluated
2026-05-25
NVD
CVE-2022-50362
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.6 (inc) to 5.10.150 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.75 (exc)
linux linux_kernel From 5.16 (inc) to 5.19.17 (exc)
linux linux_kernel From 6.0 (inc) to 6.0.3 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's DMA engine for Hisilicon devices when a DMA channel is used concurrently by multiple threads. The issue is a data race where multiple threads rewrite the DMA channel's descriptor simultaneously, causing the driver to lose track of the correct descriptor during interrupt handling. This leads to system errors such as kernel oops and system hangs due to transmission timeouts. The fix involves controlling access to the channel's descriptor so that it only changes when it is safe, preventing concurrent modification and ensuring proper handling of descriptors.


How can this vulnerability impact me? :

This vulnerability can cause the system to crash or hang when multiple threads use the same DMA channel, leading to kernel oops errors and system instability. This can result in downtime, data loss, or degraded system performance, especially in environments relying on stable DMA operations for hardware communication.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel logs for oops or system hangs related to DMA channel usage in multiple threads. The provided example commands to trigger and detect the issue are: % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run After running these, check kernel logs (e.g., using dmesg) for messages like 'Unable to handle kernel paging request', 'Internal error: Oops', or other related errors indicating the problem.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this vulnerability. The fix ensures that DMA channel descriptors are only changed when they are not in use and removes error reporting when the descriptor queue is empty, preventing data races and system hangs. Until the update is applied, avoid using DMA channels concurrently across multiple threads to prevent triggering the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart