CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47056 – crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init
https://notcve.org/view.php?id=CVE-2021-47056
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: qat - ADF_STATUS_PF_RUNNING debe configurarse después de adf_dev_init ADF_STATUS_PF_RUNNING es (solo) usado y verificado por adf_vf2pf_shutdown() antes de llamar a adf_iov_putmsg()->mutex_lock(vf2pf_lock), sin embargo, vf2pf_lock es inicializado en adf_dev_init(), que puede fallar y cuando falla, vf2pf_lock no se inicializa o se destruye, un uso posterior de vf2pf_lock causará problemas. Para solucionar este problema, establezca este indicador solo si adf_dev_init() devuelve 0. [7.178404] ERROR: KASAN: acceso a memoria de usuario en __mutex_lock.isra.0+0x1ac/0x7c0 [7.180345] Seguimiento de llamadas: [7.182576] mutex_lock+0xc9 /0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] • https://git.kernel.org/stable/c/25c6ffb249f612c56a48ce48a3887adf57b8f4bd https://git.kernel.org/stable/c/f4c4e07140687f42bfa40e091bb4a55d7960ce4d https://git.kernel.org/stable/c/446045cf682af12d9294765f6c46084b374b5654 https://git.kernel.org/stable/c/09d16cee6285d37cc76311c29add6d97a7e4acda https://git.kernel.org/stable/c/05ec8192ee4bfdf2a8894a68350dac9f1a155fa6 https://git.kernel.org/stable/c/1f50392650ae794a1aea41c213c6a3e1c824413c https://git.kernel.org/stable/c/20fd40fc6f2c2b41dc6f637f88d494b14e9c21f1 https://git.kernel.org/stable/c/1ea500ce6f7c9106e4a561d28e69215f3 •
CVSS: 3.3EPSS: 0%CPEs: 11EXPL: 0CVE-2021-47055 – mtd: require write permissions for locking and badblock ioctls
https://notcve.org/view.php?id=CVE-2021-47055
In the Linux kernel, the following vulnerability has been resolved: mtd: require write permissions for locking and badblock ioctls MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: mtd: requiere permisos de escritura para bloqueo y badblock ioctls MEMLOCK, MEMUNLOCK y OTPLOCK modifican los bits de protección. • https://git.kernel.org/stable/c/1c9f9125892a43901438bf704ada6b7019e2a884 https://git.kernel.org/stable/c/583d42400532fbd6228b0254d7c732b771e4750d https://git.kernel.org/stable/c/389c74c218d3b182e9cd767e98cee0e0fd0dabaa https://git.kernel.org/stable/c/ab1a602a9cea98aa37b2e6851b168d2a2633a58d https://git.kernel.org/stable/c/9a53e8bd59d9f070505e51d3fd19606a270e6b93 https://git.kernel.org/stable/c/f7e6b19bc76471ba03725fe58e0c218a3d6266c3 https://git.kernel.org/stable/c/36a8b2f49235e63ab3f901fe12e1b6732f075c2e https://git.kernel.org/stable/c/eb3d82abc335624a5e8ecfb75aba0b684 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47054 – bus: qcom: Put child node before return
https://notcve.org/view.php?id=CVE-2021-47054
In the Linux kernel, the following vulnerability has been resolved: bus: qcom: Put child node before return Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bus: qcom: Colocar el nodo secundario antes del retorno. Colocar el nodo secundario antes del retorno para corregir una posible pérdida del recuento de referencias. Generalmente, el recuento de referencia del niño se incrementa y disminuye automáticamente en la macro for_each_available_child_of_node() y debe disminuirse manualmente si el bucle se rompe en el cuerpo del bucle. • https://git.kernel.org/stable/c/335a127548081322bd2b294d715418648912f20c https://git.kernel.org/stable/c/a6191e91c10e50bd51db65a00e03d02b6b0cf8c4 https://git.kernel.org/stable/c/94810fc52925eb122a922df7f9966cf3f4ba7391 https://git.kernel.org/stable/c/a399dd80e697a02cfb23e2fc09b87849994043d9 https://git.kernel.org/stable/c/3a76ec28824c01b57aa1f0927841d75e4f167cb8 https://git.kernel.org/stable/c/00f6abd3509b1d70d0ab0fbe65ce5685cebed8be https://git.kernel.org/stable/c/6b68c03dfc79cd95a58dfd03f91f6e82829a1b0c https://git.kernel.org/stable/c/c6f8e0dc8da1cd78d640dee392071cc23 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-46959 – spi: Fix use-after-free with devm_spi_alloc_*
https://notcve.org/view.php?id=CVE-2021-46959
In the Linux kernel, the following vulnerability has been resolved: spi: Fix use-after-free with devm_spi_alloc_* We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [<b0396f04>] (refcount_warn_saturate) from [<b03c56a4>] (kobject_put+0x90/0x98) [<b03c5614>] (kobject_put) from [<b0447b4c>] (put_device+0x20/0x24) r4:b6700140 [<b0447b2c>] (put_device) from [<b07515e8>] (devm_spi_release_controller+0x3c/0x40) [<b07515ac>] (devm_spi_release_controller) from [<b045343c>] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [<b04533b8>] (release_nodes) from [<b0454160>] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [<b0454104>] (devres_release_all) from [<b044e41c>] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [<b044e2d8>] (__device_release_driver) from [<b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [<b044f688>] (device_driver_detach) from [<b044d274>] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: corrige el Use-After-Free con devm_spi_alloc_* No podemos confiar en el contenido de la lista devres durante spi_unregister_controller(), ya que la lista ya está eliminada en ese momento. Realizamos devres_find() para devm_spi_release_controller. Esto hace que los dispositivos registrados con devm_spi_alloc_{master,slave}() se identifiquen erróneamente como dispositivos heredados, no administrados por devm y sus contadores de referencia disminuyan por debajo de 0. ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 1 PID: 660 en lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) de [] (kobject_put+ 0x90/0x98) [] (kobject_put) de [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) de [] (devm_spi_release_controller+0x3c/0x40 ) [ ] (devm_spi_release_controller) de [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) de [] (devres_release_all+0x5c/0x6 0) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) de [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) de [< b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) de [ ] (unbind_store+0xe4/0xf8) en su lugar , determine el estado de asignación devm como un indicador en el controlador que se garantiza que será estable durante la limpieza. • https://git.kernel.org/stable/c/a4add022c1552b0d51a0b89a4781919d6ebac4f9 https://git.kernel.org/stable/c/0870525cf94bc27907e94ce99afb6d7239ffd2f5 https://git.kernel.org/stable/c/8c45a1c6c951bbe7f95db78fcab46f7337364468 https://git.kernel.org/stable/c/234b432c7b6184b2d6c5ba2c55f0dd5023c0edf0 https://git.kernel.org/stable/c/3e04a4976addbedcad326f47b0dd4efc570a1fac https://git.kernel.org/stable/c/5e844cc37a5cbaa460e68f9a989d321d63088a89 https://git.kernel.org/stable/c/bd1a5b2307279029faaddbecf2f2ac25eaef8dc6 https://git.kernel.org/stable/c/62bb2c7f2411a0045c24831f11ecacfc3 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26614 – tcp: make sure init the accept_queue's spinlocks once
https://notcve.org/view.php?id=CVE-2024-26614
In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's spinlocks once When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (. • https://git.kernel.org/stable/c/168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882 https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3 https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855 https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02 https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-413: Improper Resource Locking •