CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35788 – drm/amd/display: Fix bounds check for dcn35 DcfClocks
https://notcve.org/view.php?id=CVE-2024-35788
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix bounds check for dcn35 DcfClocks [Why] NumFclkLevelsEnabled is used for DcfClocks bounds check instead of designated NumDcfClkLevelsEnabled. That can cause array index out-of-bounds access. [How] Use designated variable for dcn35 DcfClocks bounds check. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Corrige la verificación de límites para dcn35 DcfClocks [Por qué] NumFclkLevelsEnabled se usa para la verificación de límites de DcfClocks en lugar del designado NumDcfClkLevelsEnabled. Eso puede provocar un acceso fuera de los límites al índice de matriz. [Cómo] Utilice la variable designada para comprobar los límites de dcn35 DcfClocks. • https://git.kernel.org/stable/c/a8edc9cc0b14e3769bbc9b82d00e5e5fc6b5ff0a https://git.kernel.org/stable/c/c373f233dab44a13752daec13788e2ad3bf86410 https://git.kernel.org/stable/c/f6e163e9c3d50cd167ab9d411ed01b7718177387 https://git.kernel.org/stable/c/2f10d4a51bbcd938f1f02f16c304ad1d54717b96 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35787 – md/md-bitmap: fix incorrect usage for sb_index
https://notcve.org/view.php?id=CVE-2024-35787
In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix incorrect usage for sb_index Commit d7038f951828 ("md-bitmap: don't use ->index for pages backing the bitmap file") removed page->index from bitmap code, but left wrong code logic for clustered-md. current code never set slot offset for cluster nodes, will sometimes cause crash in clustered env. Call trace (partly): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_mod] md_submit_bio+0x80/0xf8 [md_mod] __submit_bio+0x178/0x300 submit_bio_noacct_nocheck+0x11c/0x338 submit_bio_noacct+0x134/0x614 submit_bio+0x28/0xdc submit_bh_wbc+0x130/0x1cc submit_bh+0x1c/0x28 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/md-bitmap: corrige el uso incorrecto de sb_index Commit d7038f951828 ("md-bitmap: no usar ->índice para páginas que respaldan el archivo de mapa de bits") página eliminada-> índice del código de mapa de bits, pero dejó una lógica de código incorrecta para clustered-md. El código actual nunca establece el desplazamiento de ranura para los nodos del clúster, a veces causa fallos en el entorno del clúster. Rastreo de llamadas (parcialmente): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_submit_bio+0x8 0/0xf8 [md_mod] __submit_bio+0x178/ 0x300 enviar_bio_noacct_nocheck+0x11c/0x338 enviar_bio_noacct+0x134/0x614 enviar_bio+0x28/0xdc enviar_bh_wbc+0x130/0x1cc enviar_bh+0x1c/0x28 The following vulnerability has been resolved in the Linux kernel: md/md-bitmap: Fix - Incorrect usage for the sb_index. • https://git.kernel.org/stable/c/d7038f951828da19fa9aafddfa087b69032c9687 https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31 https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240 https://git.kernel.org/stable/c/ecbd8ebb51bf7e4939d83b9e6022a55cac44ef06 https://access.redhat.com/security/cve/CVE-2024-35787 https://bugzilla.redhat.com/show_bug.cgi?id=2281061 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35786 – drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf
https://notcve.org/view.php?id=CVE-2024-35786
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf If VM_BIND is enabled on the client the legacy submission ioctl can't be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveau_drm_postclose or any other nouveau ioctl call. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/nouveau: corrige el mutex bloqueado obsoleto en nouveau_gem_ioctl_pushbuf. Si VM_BIND está habilitado en el cliente, el ioctl de envío heredado no se puede usar; sin embargo, si un cliente intenta hacerlo independientemente, lo hará. devolver un error. En este caso, el mutex del cliente permaneció desbloqueado, lo que provocó un punto muerto dentro de nouveau_drm_postclose o cualquier otra llamada nouveau ioctl. • https://git.kernel.org/stable/c/b88baab828713ce0b49b185444b2ee83bed373a8 https://git.kernel.org/stable/c/c288a61a48ddb77ec097e11ab81b81027cd4e197 https://git.kernel.org/stable/c/b466416bdd6ecbde15ce987226ea633a0268fbb1 https://git.kernel.org/stable/c/daf8739c3322a762ce84f240f50e0c39181a41ab •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35785 – tee: optee: Fix kernel panic caused by incorrect error handling
https://notcve.org/view.php?id=CVE-2024-35785
In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix kernel panic caused by incorrect error handling The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows: [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tee: optee: corrige el pánico del kernel causado por un manejo incorrecto de errores. La ruta de error al no poder registrar dispositivos en el bus TEE tiene un error que provoca el pánico del kernel de la siguiente manera: [15.398930] No se puede para manejar la solicitud de paginación del kernel en la dirección virtual ffff07ed00626d7c [15.406913] Información de cancelación de memoria: [15.409722] ESR = 0x0000000096000005 [15.413490] EC = 0x25: DABT (EL actual), IL = 32 bits [15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: error de traducción de nivel 1 [ 15.429922] Información de cancelación de datos: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438 310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [15.448697] tabla de intercambio: páginas de 4k, VA de 48 bits, pgdp=00000000d9e3e000 [15.455413] 00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [15.464146] Error interno: Ups: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 ("tee opt: ee: Reparar la enumeración de dispositivos basada en solicitantes") conducen a la introducción de este error. Así que arréglalo apropiadamente. • https://git.kernel.org/stable/c/a953e45ebeae9a5ce342c012f7eb2a92cc8af89b https://git.kernel.org/stable/c/01c13d8a95e0909f0081d6e3e8a891761992371b https://git.kernel.org/stable/c/1c9561b438cbe61e78515fc7b16dc7fb8cf0b763 https://git.kernel.org/stable/c/d3c4786b01aad8c377718f92d6d9b15906ee0a2a https://git.kernel.org/stable/c/7269cba53d906cf257c139d3b3a53ad272176bca https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4 https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7 https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35784 – btrfs: fix deadlock with fiemap and extent locking
https://notcve.org/view.php?id=CVE-2024-35784
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. • https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd •