CVE-2022-50145

Source
https://nvd.nist.gov/vuln/detail/CVE-2022-50145
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-50145.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-50145
Downstream
Related
Published
2025-06-18T11:15:44Z
Modified
2025-08-09T20:01:27Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: sf-pdma: Add multithread 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 64 > /sys/module/dmatest/parameters/threadsperchan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchanfinddesc+0x32/0x46 [ 89.513553] ra : sfpdmatx_status+0xca/0xd6

This happens because of data race. Each thread rewrite channels's descriptor as soon as deviceprepdma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one.

With current fixes a descriptor changes its 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. Now it is just possible to queue a descriptor for further processing.

References

Affected packages