CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50124 – Bluetooth: ISO: Fix UAF on iso_sock_timeout
https://notcve.org/view.php?id=CVE-2024-50124
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix UAF on iso_sock_timeout conn->sk maybe have been unlinked/freed while waiting for iso_conn_lock so this checks if the conn->sk is still valid by checking if it part of iso_sk_list. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: ISO: Se corrigió que UAF en iso_sock_timeout conn->sk pudiera haberse desvinculado/liberado mientras se esperaba a iso_conn_lock, por lo que esto verifica si conn->sk aún es válido verificando si es parte de iso_sk_list. • https://git.kernel.org/stable/c/ccf74f2390d60a2f9a75ef496d2564abb478f46a https://git.kernel.org/stable/c/876ac72d535fa94f4ac57bba651987c6f990f646 https://git.kernel.org/stable/c/14bcb721d241e62fdd18f6f434a2ed2ab6e71a9b https://git.kernel.org/stable/c/d75aad1d3143ca68cda52ff80ac392e1bbd84325 https://git.kernel.org/stable/c/246b435ad668596aa0e2bbb9d491b6413861211a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50121 – nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net
https://notcve.org/view.php?id=CVE-2024-50121
In the Linux kernel, the following vulnerability has been resolved: nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net In the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`, the function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will release all resources related to the hashed `nfs4_client`. If the `nfsd_client_shrinker` is running concurrently, the `expire_client` function will first unhash this client and then destroy it. This can lead to the following warning. Additionally, numerous use-after-free errors may occur as well. nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */ __destroy_client ==================================================================== BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================== BUG nfsd_file_mark (Tainted: G B W ): Objects remaining nfsd_file_mark on __kmem_cache_shutdown() -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e To resolve this issue, cancel `nfsd_shrinker_work` using synchronous mode in nfs4_state_shutdown_net. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: cancelar nfsd_shrinker_work usando el modo de sincronización en nfs4_state_shutdown_net. • https://git.kernel.org/stable/c/7c24fa225081f31bc6da6a355c1ba801889ab29a https://git.kernel.org/stable/c/2bbf10861d51dae76c6da7113516d0071c782653 https://git.kernel.org/stable/c/958294a3eb82026fcfff20b0287a90e9c854785e https://git.kernel.org/stable/c/f3ea5ec83d1a827f074b2b660749817e0bf2b23e https://git.kernel.org/stable/c/f965dc0f099a54fca100acf6909abe52d0c85328 https://git.kernel.org/stable/c/add1df5eba163a3a6ece11cb85890e2e410baaea https://git.kernel.org/stable/c/d5ff2fb2e7167e9483846e34148e60c0c016a1f6 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50120 – smb: client: Handle kstrdup failures for passwords
https://notcve.org/view.php?id=CVE-2024-50120
In the Linux kernel, the following vulnerability has been resolved: smb: client: Handle kstrdup failures for passwords In smb3_reconfigure(), after duplicating ctx->password and ctx->password2 with kstrdup(), we need to check for allocation failures. If ses->password allocation fails, return -ENOMEM. If ses->password2 allocation fails, free ses->password, set it to NULL, and return -ENOMEM. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Manejar errores de kstrdup para contraseñas. En smb3_reconfigure(), después de duplicar ctx->password y ctx->password2 con kstrdup(), debemos verificar si hay errores de asignación. Si la asignación de ses->password falla, devuelva -ENOMEM. Si la asignación de ses->password2 falla, libere ses->password, configúrelo en NULL y devuelva -ENOMEM. • https://git.kernel.org/stable/c/7e8cffa4f85e6839335d75e6b47f918d90c1d194 https://git.kernel.org/stable/c/c1eb537bf4560b3ad4df606c266c665624f3b502 https://git.kernel.org/stable/c/e78308a6dcab1e53b38b8dd952e69c515cd324d7 https://git.kernel.org/stable/c/2a0fc63f1f4fccfeb367d0c57b8a243cec60c26c https://git.kernel.org/stable/c/35dbac8c328d6afe937cd45ecd41d209d0b9f8b8 https://git.kernel.org/stable/c/35488799b0ab6e4327f82e1d9209a60805665b37 https://git.kernel.org/stable/c/9a5dd61151399ad5a5d69aad28ab164734c1e3bc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50118 – btrfs: reject ro->rw reconfiguration if there are hard ro requirements
https://notcve.org/view.php?id=CVE-2024-50118
In the Linux kernel, the following vulnerability has been resolved: btrfs: reject ro->rw reconfiguration if there are hard ro requirements [BUG] Syzbot reports the following crash: BTRFS info (device loop0 state MCS): disabling free space tree BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1) BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2) Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Call Trace: <TASK> btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [inline] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [inline] __do_sys_mount fs/namespace.c:4020 [inline] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] To support mounting different subvolume with different RO/RW flags for the new mount APIs, btrfs introduced two workaround to support this feature: - Skip mount option/feature checks if we are mounting a different subvolume - Reconfigure the fs to RW if the initial mount is RO Combining these two, we can have the following sequence: - Mount the fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all will mark the fs as hard read-only, so no v2 cache clearing will happen. - Mount a subvolume rw of the same fs. We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY because our new fc is RW, different from the original fs. Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag first so that we can grab the existing fs_info. Then we reconfigure the fs to RW. - During reconfiguration, option/features check is skipped This means we will restart the v2 cache clearing, and convert back to v1 cache. This will trigger fs writes, and since the original fs has "rescue=all" option, it skips the csum tree read. And eventually causing NULL pointer dereference in super block writeback. [FIX] For reconfiguration caused by different subvolume RO/RW flags, ensure we always run btrfs_check_options() to ensure we have proper hard RO requirements met. In fact the function btrfs_check_options() doesn't really do many complex checks, but hard RO requirement and some feature dependency checks, thus there is no special reason not to do the check for mount reconfiguration. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: rechazar la reconfiguración de ro->rw si hay requisitos de ro estrictos [ERROR]. Syzbot informa del siguiente fallo: Información de BTRFS (estado de loop0 del dispositivo MCS): deshabilitar el árbol de espacio libre Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE (0x1) Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE_VALID (0x2) Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000018-0x000000000000001f] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [en línea] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Seguimiento de llamadas: btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [en línea] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [en línea] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [en línea] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [en línea] __do_sys_mount fs/namespace.c:4020 [en línea] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Para admitir el montaje de diferentes subvolúmenes con diferentes indicadores RO/RW para las nuevas API de montaje, btrfs introdujo dos workarounds para admitir esta función: - Omitir las comprobaciones de opciones/funciones de montaje si estamos montando un subvolumen diferente - Reconfigurar el fs a RW si el montaje inicial es RO Combinando estos dos, podemos tener la siguiente secuencia: - Montar el fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all marcará el fs como de solo lectura, por lo que no se borrará la caché v2. - Montar un subvolumen rw del mismo fs. Entramos en btrfs_get_tree_subvol(), pero fc_mount() devuelve EBUSY porque nuestro nuevo fc es RW, diferente del fs original. Ahora ingresamos btrfs_reconfigure_for_mount(), que cambia el indicador RO primero para que podamos obtener el fs_info existente. • https://git.kernel.org/stable/c/f044b318675f0347ecfb88377542651ba4eb9e1f https://git.kernel.org/stable/c/23724398b55d9570f6ae79dd2ea026fff8896bf1 https://git.kernel.org/stable/c/3c36a72c1d27de6618c1c480c793d9924640f5bb •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50117 – drm/amd: Guard against bad data for ATIF ACPI method
https://notcve.org/view.php?id=CVE-2024-50117
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? • https://git.kernel.org/stable/c/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 https://git.kernel.org/stable/c/58556dcbd5606a5daccaee73b2130bc16b48e025 https://git.kernel.org/stable/c/43b4fa6e0e238c6e2662f4fb61d9f51c2785fb1d https://git.kernel.org/stable/c/234682910971732cd4da96fd95946e296e486b38 https://git.kernel.org/stable/c/6032287747f874b52dc8b9d7490e2799736e035f https://git.kernel.org/stable/c/cd67af3c1762de4c2483ae4dbdd98f9ea8fa56e3 https://git.kernel.org/stable/c/975ede2a7bec52b5da1428829b3439667c8a234b https://git.kernel.org/stable/c/1d7175f9c57b1abf9ecfbdfd53ea76076 •