CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52569 – btrfs: remove BUG() after failure to insert delayed dir index item
https://notcve.org/view.php?id=CVE-2023-52569
In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items. • https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51 https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52566 – nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
https://notcve.org/view.php?id=CVE-2023-52566
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log] • https://git.kernel.org/stable/c/a3d93f709e893187d301aa5458b2248db9f22bd1 https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1 https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33 https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7 https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8 https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cd •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52561 – arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
https://notcve.org/view.php?id=CVE-2023-52561
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y. • https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2 https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6 •
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 •