CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47016 – m68k: mvme147,mvme16x: Don't wipe PCC timer config bits
https://notcve.org/view.php?id=CVE-2021-47016
In the Linux kernel, the following vulnerability has been resolved: m68k: mvme147,mvme16x: Don't wipe PCC timer config bits Don't clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, "This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated." On mvme16x, enable the timer after requesting the irq, consistent with mvme147. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: m68k: mvme147,mvme16x: No borre los bits de configuración del temporizador PCC. • https://git.kernel.org/stable/c/7529b90d051e4629884771ba2b1d3a87d2c6a9d7 https://git.kernel.org/stable/c/f6a90818a32058fca62cda3a2027a6a2364e1878 https://git.kernel.org/stable/c/1dfb26df15fc7036a74221d43de7427f74293dae https://git.kernel.org/stable/c/73fdeb612d25b5e105c219e05434285a45d23576 https://git.kernel.org/stable/c/5d34225169346cab5145978d153b9ce90e9ace21 https://git.kernel.org/stable/c/43262178c043032e7c42d00de44c818ba05f9967 •
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: 8EXPL: 0CVE-2024-26615 – net/smc: fix illegal rmb_desc access in SMC-D connection dump
https://notcve.org/view.php?id=CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? • https://git.kernel.org/stable/c/4b1b7d3b30a6d32ac1a1dcede284e76ef8a8542d https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22 https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9 https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3e • CWE-476: NULL Pointer Dereference •
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 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52498 – PM: sleep: Fix possible deadlocks in core system-wide PM code
https://notcve.org/view.php?id=CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: suspensión: soluciona posibles bloqueos en el código PM de todo el sistema central. Se informa que en situaciones de poca memoria, el código central de reanudación de todo el sistema se bloquea porque async_schedule_dev() ejecuta su el argumento funciona sincrónicamente si no puede asignar memoria (y no solo en ese caso) y esa función intenta adquirir un mutex que ya está retenido. La ejecución de la función de argumento sincrónicamente desde dpm_async_fn() también puede ser problemática por razones de pedido (puede causar que la devolución de llamada de currículum de un dispositivo consumidor se invoque antes que la de un dispositivo proveedor requerido, por ejemplo). • https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0 https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34 https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7 https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2023 • CWE-833: Deadlock •