CVE-2022-50145
dmaengine: sf-pdma: Add multithread support for a DMA channel
We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
dmaengine: sf-pdma: Add multithread support for a DMA channel
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/threads_per_chan % 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 : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_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.
Reserved 2025-06-18 | Published 2025-06-18 | Updated 2025-06-18 | Assigner Linuxgit.kernel.org/...c/b9b4992f897be9b0b9e3a3b956cab6b75ccc3f11
git.kernel.org/...c/5ab2782c944e324008ef5d658f2494a9f0e3c5ac
git.kernel.org/...c/4c7350b1dd8a192af844de32fc99b9e34c876fda
git.kernel.org/...c/a93b3f1e11971a91b6441b6d47488f4492cc113f
git.kernel.org/...c/b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc
Support options
