CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52475 – Input: powermate - fix use-after-free in powermate_config_complete
https://notcve.org/view.php?id=CVE-2023-52475
In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: powermate - corrige el use-after-free en powermate_config_complete syzbot ha encontrado un error de use-after-free [1] en el controlador powermate. Esto sucede cuando el dispositivo está desconectado, lo que genera una memoria libre de la estructura powermate_device. • https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9 https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06 https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46 https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8 https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b1 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47049 – Drivers: hv: vmbus: Use after free in __vmbus_open()
https://notcve.org/view.php?id=CVE-2021-47049
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Usar después de liberar en __vmbus_open() La variable "open_info" se agrega a &vmbus_connection.chn_msg_list, pero el manejo de errores libera "open_info" sin eliminarlo de la lista. Esto resultará en un uso posterior gratuito. • https://git.kernel.org/stable/c/6f3d791f300618caf82a2be0c27456edd76d5164 https://git.kernel.org/stable/c/6b32d45bd59982751beb8220e442b40b2706647f https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f https://git.kernel.org/stable/c/f37dd5d1b5d38a79a4f7b8dd7bbb705505f05560 https://git.kernel.org/stable/c/2728f289b3270b0e273292b46c534421a33bbfd5 https://git.kernel.org/stable/c/3e9bf43f7f7a46f21ec071cb47be92d0874c48da •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47041 – nvmet-tcp: fix incorrect locking in state_change sk callback
https://notcve.org/view.php?id=CVE-2021-47041
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5 https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47034 – powerpc/64s: Fix pte update for kernel memory on radix
https://notcve.org/view.php?id=CVE-2021-47034
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. • https://git.kernel.org/stable/c/f1cb8f9beba8699dd1b4518418191499e53f7b17 https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7 https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301 https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47024 – vsock/virtio: free queued packets when closing socket
https://notcve.org/view.php?id=CVE-2021-47024
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vsock/virtio: paquetes libres en cola al cerrar el socket Según lo informado por syzbot [1], hay una pérdida de memoria al cerrar el socket. Resolvimos parcialmente este problema con el compromiso ac03046ece2b ("vsock/virtio: paquetes libres durante el lanzamiento del socket"), pero nos olvidamos de vaciar la cola RX cuando el trabajo programado cierra definitivamente el socket. Para evitar problemas futuros, usemos el nuevo virtio_transport_remove_sock() para drenar la cola RX antes de eliminar el socket de las listas af_vsock llamando a vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug? • https://git.kernel.org/stable/c/ac03046ece2b158ebd204dfc4896fd9f39f0e6c8 https://git.kernel.org/stable/c/4ea082cd3c400cd5bb36a7beb7e441bf3e29350d https://git.kernel.org/stable/c/4e539fa2dec4db3405e47002f2878aa4a99eb68b https://git.kernel.org/stable/c/4af8a327aeba102aaa9b78f3451f725bc590b237 https://git.kernel.org/stable/c/51adb8ebe8c1d80528fc2ea863cfea9d32d2c52b https://git.kernel.org/stable/c/7d29c9ad0ed525c1b10e29cfca4fb1eece1e93fb https://git.kernel.org/stable/c/b605673b523fe33abeafb2136759bcbc9c1e6ebf https://git.kernel.org/stable/c/27691665145e74a45034a9dccf1150cf1 •