CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47061 – KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU
https://notcve.org/view.php?id=CVE-2021-47061
In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Destruye los dispositivos del bus de E/S al cancelar el registro _después_ de sincronizar SRCU Si falla la asignación de una nueva instancia de un bus de E/S al cancelar el registro de un dispositivo, espere para destruir el dispositivo hasta que todos los lectores tengan la garantía de ver el nuevo bus nulo. Destruir dispositivos antes de que se anule el bus podría dar lugar a un uso posterior a la liberación, ya que los lectores esperan que los dispositivos en su referencia del bus sigan siendo válidos. • https://git.kernel.org/stable/c/f65886606c2d3b562716de030706dfe1bea4ed5e https://git.kernel.org/stable/c/f0dfffce3f4ffd5f822568a4a6fb34c010e939d1 https://git.kernel.org/stable/c/840e124f89a5127e7eb97ebf377f4b8ca745c070 https://git.kernel.org/stable/c/40a023f681befd9b2862a3c16fb306a38b359ae5 https://git.kernel.org/stable/c/19184bd06f488af62924ff1747614a8cb284ad63 https://git.kernel.org/stable/c/41b2ea7a6a11e2b1a7f2c29e1675a709a6b2b98d https://git.kernel.org/stable/c/68c125324b5e1d1d22805653735442923d896a1d https://git.kernel.org/stable/c/03c6cccedd3913006744faa252a4da514 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47060 – KVM: Stop looking for coalesced MMIO zones if the bus is destroyed
https://notcve.org/view.php?id=CVE-2021-47060
In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: deja de buscar zonas MMIO fusionadas si el bus se destruye. • https://git.kernel.org/stable/c/41b2ea7a6a11e2b1a7f2c29e1675a709a6b2b98d https://git.kernel.org/stable/c/f65886606c2d3b562716de030706dfe1bea4ed5e https://git.kernel.org/stable/c/f0dfffce3f4ffd5f822568a4a6fb34c010e939d1 https://git.kernel.org/stable/c/840e124f89a5127e7eb97ebf377f4b8ca745c070 https://git.kernel.org/stable/c/40a023f681befd9b2862a3c16fb306a38b359ae5 https://git.kernel.org/stable/c/19184bd06f488af62924ff1747614a8cb284ad63 https://git.kernel.org/stable/c/68c125324b5e1d1d22805653735442923d896a1d https://git.kernel.org/stable/c/7d1bc32d6477ff96a32695ea4be8144e4 •
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: 3.3EPSS: 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: -EPSS: 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 •