CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48628 – ceph: drop messages from MDS when unmounting
https://notcve.org/view.php?id=CVE-2022-48628
In the Linux kernel, the following vulnerability has been resolved: ceph: drop messages from MDS when unmounting When unmounting all the dirty buffers will be flushed and after the last osd request is finished the last reference of the i_count will be released. Then it will flush the dirty cap/snap to MDSs, and the unmounting won't wait the possible acks, which will ihold the inodes when updating the metadata locally but makes no sense any more, of this. This will make the evict_inodes() to skip these inodes. If encrypt is enabled the kernel generate a warning when removing the encrypt keys when the skipped inodes still hold the keyring: WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1 Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000 R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Later the kernel will crash when iput() the inodes and dereferencing the "sb->s_master_keys", which has been released by the generic_shutdown_super(). • https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5 https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571 https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48627 – vt: fix memory overlapping when deleting chars in the buffer
https://notcve.org/view.php?id=CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: corrige la superposición de memoria al eliminar caracteres en el búfer. Se produce una copia de memoria superpuesta al eliminar una línea larga. • https://git.kernel.org/stable/c/81732c3b2fede049a692e58a7ceabb6d18ffb18c https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29 https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926 https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244 https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265 https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges •
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 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52486 – drm: Don't unref the same fb many times by mistake due to deadlock handling
https://notcve.org/view.php?id=CVE-2023-52486
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm: No desreferenciar el mismo fb muchas veces por error debido al manejo de interbloqueos Si obtenemos un punto muerto después de la búsqueda de fb en drm_mode_page_flip_ioctl() procedemos a desreferenciar el fb y luego Vuelva a intentarlo todo desde arriba. Pero nos olvidamos de restablecer el puntero fb a NULL, por lo que si obtenemos otro error durante el reintento, antes de la búsqueda de fb, procedemos a desref el mismo fb nuevamente sin haber obtenido otra referencia. • https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229 https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7 https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105 https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551 https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0 https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76f • CWE-833: Deadlock •