CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52517 – spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain
https://notcve.org/view.php?id=CVE-2023-52517
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. • https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209 https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097 https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52516 – dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
https://notcve.org/view.php?id=CVE-2023-52516
In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- • https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3 https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2023-52515 – RDMA/srp: Do not call scsi_done() from srp_abort()
https://notcve.org/view.php?id=CVE-2023-52515
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. • https://git.kernel.org/stable/c/d8536670916a685df116b5c2cb256573fd25e4e3 https://git.kernel.org/stable/c/738589592a04180e39b6fb5fe8205d85b7dc69f6 https://git.kernel.org/stable/c/0575df129e2eb4a801beae0e6e041787480f42b9 https://git.kernel.org/stable/c/22fb582405002812d8fb89d0ed1264e97d3d25ad https://git.kernel.org/stable/c/39d6594c457c4728794cb4c3c7be53f93f1ef3ae https://git.kernel.org/stable/c/b3f3b814add77a464911df0080d812b18f61ff38 https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42c •
CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52511 – spi: sun6i: reduce DMA RX transfer width to single byte
https://notcve.org/view.php?id=CVE-2023-52511
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue. • https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355 https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52510 – ieee802154: ca8210: Fix a potential UAF in ca8210_probe
https://notcve.org/view.php?id=CVE-2023-52510
In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). • https://git.kernel.org/stable/c/ded845a781a578dfb0b5b2c138e5a067aa3b1242 https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66 https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f03541 •