CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53131 – nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
https://notcve.org/view.php?id=CVE-2024-53131
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Serie de parches "nilfs2: fix null-ptr-deref bugs on block tracepoints". Esta serie corrige errores de desreferencia de puntero nulo que ocurren al usar nilfs2 y dos puntos de seguimiento relacionados con bloques. Este parche (de 2): Se ha informado que al usar el punto de seguimiento "block:block_touch_buffer", touch_buffer() llamado desde __nilfs_get_folio_block() causa una desreferencia de puntero NULL o un error de protección general cuando KASAN está habilitado. • https://git.kernel.org/stable/c/5305cb830834549b9203ad4d009ad5483c5e293f https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9 https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636 https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423 https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9 https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665 https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53130 – nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint
https://notcve.org/view.php?id=CVE-2024-53130
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrección de null-ptr-deref en el punto de seguimiento block_dirty_buffer Al utilizar el punto de seguimiento "block:block_dirty_buffer", mark_buffer_dirty() puede provocar una desreferencia de puntero NULL o un fallo de protección general cuando KASAN está habilitado. Esto sucede porque, dado que el punto de seguimiento se agregó en mark_buffer_dirty(), hace referencia al miembro dev_t bh->b_bdev->bd_dev independientemente de si el cabezal del búfer tiene un puntero a una estructura block_device. En la implementación actual, nilfs_grab_buffer(), que toma un búfer para leer (o crear) un bloque de metadatos, incluidos los bloques de nodos de árbol b, no establece el dispositivo de bloque, sino que lo hace solo si el búfer no está en el estado "uptodate" para cada una de sus funciones de lectura de bloque de llamada. • https://git.kernel.org/stable/c/5305cb830834549b9203ad4d009ad5483c5e293f https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957 https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020 https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8 https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95 https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e99 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53128 – sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
https://notcve.org/view.php?id=CVE-2024-53128
In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/task_stack: corrección de object_is_on_stack() para punteros etiquetados de KASAN Cuando CONFIG_KASAN_SW_TAGS y CONFIG_KASAN_STACK están habilitados, la función object_is_on_stack() puede producir resultados incorrectos debido a la presencia de etiquetas en el puntero obj, mientras que el puntero de pila no tiene etiquetas. Esta discrepancia puede provocar una detección incorrecta de objetos de pila y, posteriormente, activar advertencias si CONFIG_DEBUG_OBJECTS también está habilitado. Ejemplo de la advertencia: ODEBUG: el objeto 3eff800082ea7bb0 NO está en la pila ffff800082ea0000, pero está anotado. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 1 en lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Módulos vinculados: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.0-rc5 #4 Nombre del hardware: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 00000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9: 34d77febe173e800 x8: 34d77febe173e800 x7: 0000000000000001 x6: 00000000000000001 x5: feff800082ea74b8 x4: ffff800082870a90 x3: ffff80008018d3c4 x2: 0000000000000001 x1: ffff800082858810 x0: 0000000000000050 Seguimiento de llamadas: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ fin del seguimiento 000000000000000 ]--- ODEBUG: el objeto 3eff800082ea7bb0 NO está en la pila ffff800082ea0000, pero está anotado. ------------[ cortar aquí ]------------ • https://git.kernel.org/stable/c/fbfe23012cec509dfbe09852019c4e4bb84999d0 https://git.kernel.org/stable/c/fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53127 – Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K"
https://notcve.org/view.php?id=CVE-2024-53127
In the Linux kernel, the following vulnerability has been resolved: Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K" The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "mmc: dw_mmc: Fix IDMAC operación con páginas mayores a 4K" el commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operación con páginas mayores a 4K") aumentó el max_req_size, incluso para páginas de 4K, causando varios problemas: - Arranque de pánico del kernel/rootfs desde una tarjeta SD en Rockchip RK3566 - Arranque de pánico del kernel/rootfs desde una tarjeta SD en StarFive JH7100 - "El búfer swiotlb está lleno" y corrupción de datos en StarFive JH7110 En esta etapa no se ha encontrado ninguna solución, por lo que probablemente sea mejor simplemente revertir el cambio. Esto revierte el commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890. • https://git.kernel.org/stable/c/32bd402f6760d57127d58a9888553b2db574bba6 https://git.kernel.org/stable/c/b9ee16a20d9976686185d7e59cd006c328b6a1e0 https://git.kernel.org/stable/c/2793f423893579b35dc1fc24dd7c1ce58fa0345a https://git.kernel.org/stable/c/9d715a234dd8f01af970b78ae2144a2fd3ead21c https://git.kernel.org/stable/c/373f8f5b087f010dddae3306a79c6fdd5c2f8953 https://git.kernel.org/stable/c/5b4bf3948875064a9adcda4b52b59e0520a8c576 https://git.kernel.org/stable/c/8396c793ffdf28bb8aee7cfe0891080f8cab7890 https://git.kernel.org/stable/c/5b1ef10f7d49f3320b0faa894204259e5 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-53125 – bpf: sync_linked_regs() must preserve subreg_def
https://notcve.org/view.php?id=CVE-2024-53125
In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: sync_linked_regs() debe preservar subreg_def La propagación del rango no debe afectar a las marcas subreg_def, de lo contrario el siguiente ejemplo es reescrito incorrectamente por el verificador cuando el indicador BPF_F_TEST_RND_HI32 está establecido: 0: llamar a bpf_ktime_get_ns llamar a bpf_ktime_get_ns 1: r0 &= 0x7fffffff después del verificador r0 &= 0x7fffffff 2: w1 = w0 reescribe w1 = w0 3: si w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: salir; si w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 salir (o falta la extensión cero de w1 en (2) para arquitecturas que requieren extensión cero para la mitad superior del registro). Lo siguiente ocurre sin este parche: - r0 está marcado como no un subreg en (0); - w1 está marcado como subreg en (2); - el subreg_def de w1 es anulado en (3) por copy_register_state(); - w1 se lee en (5) pero mark_insn_zext() no marca (2) para extensión cero, porque el subreg_def de w1 no está configurado; - debido al indicador BPF_F_TEST_RND_HI32, el verificador inserta un valor aleatorio para los bits hi32 de (2) (marcado (r)); - este valor aleatorio se lee en (5). • https://git.kernel.org/stable/c/75748837b7e56919679e02163f45d5818c644d03 https://git.kernel.org/stable/c/dadf82c1b2608727bcc306843b540cd7414055a7 https://git.kernel.org/stable/c/b57ac2d92c1f565743f6890a5b9cf317ed856b09 https://git.kernel.org/stable/c/60fd3538d2a8fd44c41d25088c0ece3e1fd30659 https://git.kernel.org/stable/c/bfe9446ea1d95f6cb7848da19dfd58d2eec6fd84 https://git.kernel.org/stable/c/e2ef0f317a52e678fe8fa84b94d6a15b466d6ff0 https://git.kernel.org/stable/c/e9bd9c498cb0f5843996dbe5cbce7a1836a83c70 •