CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2023-52854 – padata: Fix refcnt handling in padata_free_shell()
https://notcve.org/view.php?id=CVE-2023-52854
In the Linux kernel, the following vulnerability has been resolved: padata: Fix refcnt handling in padata_free_shell() In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrige el manejo de refcnt en padata_free_shell(). • https://git.kernel.org/stable/c/07928d9bfc81640bab36f5190e8725894d93b659 https://git.kernel.org/stable/c/13721e447acc2b82c19cf72e9e6c4291c77693ed https://git.kernel.org/stable/c/7a2ccb65f90168edc2348495bb56093c466ffa39 https://git.kernel.org/stable/c/928cf3d733c4efc221e1a78b14cb2ee066627260 https://git.kernel.org/stable/c/c9da8ee1491719001a444f4af688b75e72b58418 https://git.kernel.org/stable/c/dc34710a7aba5207e7cb99d11588c04535b3c53d https://git.kernel.org/stable/c/5fefc9b3e3584a1ce98da27c38e1b8dda1939d74 https://git.kernel.org/stable/c/26daf8e6515c2dcd25d235468420b9f46 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52853 – hid: cp2112: Fix duplicate workqueue initialization
https://notcve.org/view.php?id=CVE-2023-52853
In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: cp2112: corrige la inicialización duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores después de una solicitud inicial. Esto resultó en una advertencia en set_work_data en workqueue.c, así como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. • https://git.kernel.org/stable/c/13de9cca514ed63604263cad87ca8cb36e9b6489 https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6 https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819 https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38 https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592 https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01f •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52852 – f2fs: compress: fix to avoid use-after-free on dic
https://notcve.org/view.php?id=CVE-2023-52852
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to avoid use-after-free on dic Call trace: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_unbounded+0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8/0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if we hit cached page in compress_inode's cache, dic may be released, it needs break the loop rather than continuing it, in order to avoid accessing invalid dic pointer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: corrección para evitar el use after free en dic. Rastreo de llamadas: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_ ilimitado +0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8 /0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 En f2fs_read_multi_pages(), una vez que se llamó a f2fs_decompress_cluster() si llegamos a la página almacenada en caché en el caché de compress_inode, es posible que se libere dic, es necesario romper el ciclo en lugar de continuarlo, para evitar acceder a un puntero dic no válido. • https://git.kernel.org/stable/c/6ce19aff0b8cd386860855185c6cd79337fc4d2b https://git.kernel.org/stable/c/a23706426da9b611be5beae0f3faa260fb453b4e https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5 https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401 https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2 https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52851 – IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF
https://notcve.org/view.php?id=CVE-2023-52851
In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF In the unlikely event that workqueue allocation fails and returns NULL in mlx5_mkey_cache_init(), delete the call to mlx5r_umr_resource_cleanup() (which frees the QP) in mlx5_ib_stage_post_ib_reg_umr_init(). This will avoid attempted double free of the same QP when __mlx5_ib_add() does its cleanup. Resolves a splat: Syzkaller reported a UAF in ib_destroy_qp_user workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642): failed to create work queue infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642): mr cache init failed -12 ================================================================== BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073) Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642 Call Trace: <TASK> kasan_report (mm/kasan/report.c:590) ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073) mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198) __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178) mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402) ... </TASK> Allocated by task 1642: __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026 mm/slab_common.c:1039) create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720 . • https://git.kernel.org/stable/c/04876c12c19e94bbbc94bb0446c7bc7cd75163de https://git.kernel.org/stable/c/437f033e30c897bb3723eac9e9003cd9f88d00a3 https://git.kernel.org/stable/c/4f4a7a7d1404297f2a92df0046f7e64dc5c52dd9 https://git.kernel.org/stable/c/6387f269d84e6e149499408c4d1fc805017729b2 https://git.kernel.org/stable/c/2ef422f063b74adcc4a4a9004b0a87bb55e0a836 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52850 – media: hantro: Check whether reset op is defined before use
https://notcve.org/view.php?id=CVE-2023-52850
In the Linux kernel, the following vulnerability has been resolved: media: hantro: Check whether reset op is defined before use The i.MX8MM/N/P does not define the .reset op since reset of the VPU is done by genpd. Check whether the .reset op is defined before calling it to avoid NULL pointer dereference. Note that the Fixes tag is set to the commit which removed the reset op from i.MX8M Hantro G2 implementation, this is because before this commit all the implementations did define the .reset op. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: hantro: compruebe si la operación de reinicio está definida antes de su uso. El i.MX8MM/N/P no define la operación .reset ya que genpd realiza el reinicio de la VPU. Compruebe si la operación .reset está definida antes de llamarla para evitar la desreferencia del puntero NULL. • https://git.kernel.org/stable/c/6971efb70ac3e43d19bf33ef5f83bea0271831ee https://git.kernel.org/stable/c/64f55cebb4339ae771e9e7f3f42bee2489e2fa00 https://git.kernel.org/stable/c/66b4c5f980d741f3a47e4b65eeaf2797f2d59294 https://git.kernel.org/stable/c/24c06295f28335ced3aad53dd4b0a0bae7b9b100 https://git.kernel.org/stable/c/88d4b23a629ebd34f682f770cb6c2116c851f7b8 •