CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26699 – drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr
https://notcve.org/view.php?id=CVE-2024-26699
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr [Why] There is a potential memory access violation while iterating through array of dcn35 clks. [How] Limit iteration per array size. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige el índice de matriz fuera de los límites en dcn35_clkmgr [Por qué] Existe una posible infracción de acceso a la memoria al iterar a través de una matriz de clks dcn35. [Cómo] Limitar la iteración por tamaño de matriz. • https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc •
CVSS: 4.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26698 – hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
https://notcve.org/view.php?id=CVE-2024-26698
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not. This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run. netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite. Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep. This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose. Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: corrige la condición de ejecución entre netvsc_probe y netvsc_remove En el commit ac5047671758 ("hv_netvsc: deshabilite NAPI antes de cerrar el canal VMBus"), se llamaba a napi_disable para todos los canales, incluidos todos los subcanales sin confirmando si están habilitados o no. Esto provocó que hv_netvsc se colgara en napi_disable, cuando netvsc_probe() terminó de ejecutarse pero nvdev->subchan_work aún no se inició. netvsc_subchan_work() -> rndis_set_subchannel() no ha creado los subcanales y por eso netvsc_sc_open() no se está ejecutando. netvsc_remove() llama a cancel_work_sync(&nvdev->subchan_work), para lo cual netvsc_subchan_work no se ejecutó. netif_napi_add() establece el bit NAPI_STATE_SCHED porque garantiza que NAPI no se pueda programar. • https://git.kernel.org/stable/c/ac5047671758ad4be9f93898247b3a8b6dfde4c7 https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518 https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26697 – nilfs2: fix data corruption in dsync block recovery for small block sizes
https://notcve.org/view.php?id=CVE-2024-26697
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página. • https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65 https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5 https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3 https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9 https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a61 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26696 – nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
https://notcve.org/view.php?id=CVE-2024-26696
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. • https://git.kernel.org/stable/c/1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46 https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6 https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32 https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28 https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca5447 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26695 – crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
https://notcve.org/view.php?id=CVE-2024-26695
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? • https://git.kernel.org/stable/c/87af9b0b45666ca3dd6b10c0ece691c740b0f750 https://git.kernel.org/stable/c/f831d2882c843d44100016aeb4332e9c4b560805 https://git.kernel.org/stable/c/1b05ece0c931536c0a38a9385e243a7962e933f6 https://git.kernel.org/stable/c/fcb04178c05b88a98921e262da9f7cb21cfff118 https://git.kernel.org/stable/c/d87bbd10fc01b52c814113643f2707d2d10b0319 https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4 https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304 •