Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error fuera de los límites en parse_sec_desc(). Si osidoffset, gsidoffset y dacloffset pueden ser mayores que el tamaño de la estructura smb_ntsd, si es menor, podría causar un error fuera de los límites de slab. Al validar sid, es necesario comprobar si incluye el tamaño del array subauth.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: gregator: protege los controladores attr del controlador contra la descarga del módulo Tanto new_device_store como delete_device_store tocan los recursos globales del módulo (por ejemplo, gpio_aggregator_lock). Para evitar condiciones de ejecución con la descarga del módulo, se debe mantener una referencia. Agregue try_module_get() en estos controladores. Para new_device_store, esto elimina lo que parece ser el escenario más peligroso: si se asigna un id desde gpio_aggregator_idr pero platform_device_register aún no se ha llamado o completado, una descarga de módulo concurrente podría fallar al anular el registro/eliminar el dispositivo, dejando atrás un reenvío de dispositivo de plataforma/GPIO colgante. Esto puede resultar en varios problemas. El siguiente reproductor simple demuestra estos problemas: #!/bin/bash while :; do # nota: no importa si 'gpiochip0 0' existe o no. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait A partir de la siguiente advertencia, aparecerán varios tipos de advertencias y el sistema puede volverse inestable: ------------[ cortar aquí ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ fin de seguimiento 000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error en la trampa de smb2_lock. Si el número de bloqueos es mayor que 1, las banderas podrían tener un valor anterior. Debe comprobarse con las banderas de smb_lock, no con las banderas. Esto provocará un error en la trampa de locks_free_lock en la rutina de gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el use-after-free en smb2_lock. Si smb_lock->zero_len tiene valor, ->llist de smb_lock no se elimina y Flock es antiguo. Esto provocará el use-after-free en la rutina de gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: appleir: Se corrige una posible desreferencia de puntero NULL en el identificador de evento sin procesar Syzkaller informa un problema de desreferencia de puntero NULL en input_event(). ERROR: KASAN: null-ptr-deref en instrument_atomic_read include/linux/instrumented.h:68 [en línea] ERROR: KASAN: null-ptr-deref en _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [en línea] ERROR: KASAN: null-ptr-deref en is_event_supported drivers/input/input.c:67 [en línea] ERROR: KASAN: null-ptr-deref en input_event+0x42/0xa0 drivers/input/input.c:395 Lectura de tamaño 8 en la dirección 0000000000000028 por la tarea syz-executor199/2949 CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 No contaminado 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [en línea] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [en línea] es_evento_compatible drivers/input/input.c:67 [en línea] evento_entrada+0x42/0xa0 drivers/input/input.c:395 clave_informe_entrada include/linux/input.h:439 [en línea] tecla_abajo drivers/hid/hid-appleir.c:159 [en línea] evento_sin_usar_appleir+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 controladores/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 controladores/usb/core/hcd.c:1734 temporizador ficticio+0x17f7/0x3960 controladores/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [en línea] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [en línea] invocar_softirq kernel/softirq.c:435 [en línea] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [en línea] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [en línea] Esto sucede debido a los elementos de informe mal formados enviados por el dispositivo emulado, lo que da como resultado que se agregue a la lista de informes un informe que no tiene campos. Debido a que appleir_input_configured() nunca se llama, hidinput_connect() falla, lo que provoca que no se configure el indicador HID_CLAIMED_INPUT. Sin embargo, esto no provoca el fallo de appleir_probe() y permite que la devolución de llamada del evento se llame sin el dispositivo de entrada asociado. Por lo tanto, se debe añadir una comprobación para el indicador HID_CLAIMED_INPUT y abandonar el gancho de evento antes de tiempo si el controlador no solicitó ningún input_dev por alguna razón. Además, otros controladores HID que acceden a input_dev en sus devoluciones de llamada de evento también tienen comprobaciones similares. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la confusión de tipos mediante una condición de ejecución cuando se usa ipc_msg_send_request. req->handle se asigna usando ksmbd_acquire_id(&ipc_ida), según ida_alloc. req->handle de ksmbd_ipc_login_request y FSCTL_PIPE_TRANSCEIVE ioctl puede ser el mismo y podría generar una confusión de tipos entre mensajes, lo que resulta en el acceso a partes inesperadas de la memoria después de una entrega incorrecta. ksmbd verifica el tipo de respuesta de ipc pero falta agregar continuar para verificar la siguiente respuesta de ipc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/hmm: No desreferenciar punteros de página de estructura sin bloqueo de notificador Los pnfs que obtenemos de hmm_range_fault() apuntan a páginas en las que no tenemos una referencia, y la garantía de que aún están en las tablas de páginas de la CPU es que el bloqueo del notificador debe mantenerse y el seqno del notificador aún es válido. Entonces, mientras construimos la tabla sg y marcamos las páginas como accedidas/sucias, necesitamos mantener este bloqueo con un seqno validado. Sin embargo, el bloqueo está contaminado por recuperación, lo que hace que sg_alloc_table_from_pages_segment() sea inutilizable, ya que asigna memoria internamente. En su lugar, construya la tabla sg manualmente. Para el caso que no es iommu, esto podría llevar a menos coalescencias, pero si eso es un problema, se puede arreglar más adelante en el código del cursor de recursos. En el caso de iommu, toda la tabla sg puede fusionarse en una única región va de dispositivo contiguo. Esto evita marcar páginas que no son de nuestra propiedad como sucias y accedidas, y también evita desreferenciar páginas de estructura que no son de nuestra propiedad. v2: - Usar assert para comprobar si las funciones de función de enlace de hmm son válidas (Matthew Auld). - Tener en cuenta que las páginas grandes pueden cruzar los límites de rango (Matthew Auld). v3: - No comprobar innecesariamente si hay una tabla sg no liberada (Matthew Auld). - Añadir una función up_read() faltante en una ruta de error (Matthew Auld). (Seleccionado de el commit ea3e66d280ce2576664a862693d1da8fd324c317).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: abortar vma_modify() en caso de fallo de memoria insuficiente en la fusión. El resto de vma_modify() depende de que el estado de vmg permanezca intacto tras un intento de fusión. Normalmente, este es el caso; sin embargo, en el caso extremo de que un intento de fusión falle no porque el rango especificado no se pueda fusionar, sino debido a un error de memoria insuficiente al intentar confirmar la fusión, esta suposición se vuelve falsa. Esto da como resultado que vmg->start, end se modifique y, por lo tanto, los intentos posteriores de dividir el VMA se realizarán con valores de inicio/fin no válidos. Afortunadamente, es prácticamente imposible que logremos esto en la realidad, ya que requeriría un fallo de preasignación de nodos del árbol de maple que probablemente nunca ocurriría por ser "demasiado pequeño para fallar", es decir, el kernel simplemente seguiría reintentando la recuperación hasta que tuviera éxito. Sin embargo, este escenario sigue siendo teóricamente posible, y lo que estamos haciendo aquí es incorrecto, por lo que debemos corregirlo. La opción más segura, cuando ocurre este escenario, es simplemente abandonar la operación. Si no podemos asignar memoria para la fusión, tampoco podemos asignar memoria para la división (¡quizás incluso más!). Cualquier escenario donde esto ocurra estaría bajo una presión de memoria muy extrema (probablemente fatal), por lo que es mejor abandonar pronto. Por lo tanto, no hay duda de que es apropiado simplemente abandonar en este escenario. Sin embargo, en general, si es posible, nunca debemos asumir que el estado de VMG es estable después de un intento de fusión, ya que las operaciones de fusión actualizan los campos de VMG. Como resultado, también debemos aclarar esto almacenando inicio y fin en variables locales. El problema fue reportado originalmente por syzkaller y por Brad Spengler (a través de una discusión fuera de la lista), y en ambos casos se manifestó como una activación de la aserción: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). Parece que al menos un escenario en el que esto ocurre es uno en el que la fusión que se intenta se debe a una función madvise() en múltiples VMA, con este aspecto: inicio fin |<------>| |----------|------| | vma | siguiente | |----------|------| Cuando se invoca madvise_walk_vmas(), primero encontramos vma en lo anterior (determinando que prev sea igual a vma, ya que estamos desplazados hacia vma) y luego entramos en el bucle. Determinamos el final de vma que forma parte del rango que estamos ejecutando con madvise() estableciendo 'tmp' en este valor: /* Aquí vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; Luego invocamos la operación madvise() a través de visit(), permitiendo que prev se actualice para apuntar a vma como parte de la operación: /* Aquí vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Donde el puntero de la función visit() en esta instancia es madvise_vma_behavior(). Como se observa en los informes de syzkaller, en última instancia es madvise_update_vma() el que se invoca, llamando a vma_modify_flags_name() y vma_modify() a su vez. Luego, en vma_modify(), intentamos la fusión: merged = vma_merge_existing_range(vmg); if (merged) return merged; Invocamos esto con vmg->start, end establecido en start, tmp como tal: start tmp |<--->| |----------|------| | vma | next | |----------|------| Nos encontramos en el escenario correcto de fusión, pero en el que no podemos eliminar la parte central (estamos desplazados hacia vma). Aquí tenemos un caso especial donde vmg->start, end se establecen en valores quizás poco intuitivos: pretendíamos reducir la VMA central y expandir la siguiente. Esto significa que vmg->start, end se establecen en... vma->vm_start, start. Ahora, commit_merge() falla y vmg->start, end se mantienen así. Esto significa que volvemos al resto de vma_modify() ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm: pgtable: corregir problema de desreferencia de puntero NULL Cuando update_mmu_cache_range() es llamado por update_mmu_cache(), el parámetro vmf es NULL, lo que causará un problema de desreferencia de puntero NULL en adjust_pte(): No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 00000030 cuando se lee Nombre del hardware: Atmel AT91SAM9 La PC está en update_mmu_cache_range+0x1e0/0x278 LR está en pte_offset_map_rw_nolock+0x18/0x2c Rastreo de llamadas: update_mmu_cache_range de remove_migration_pte+0x29c/0x2ec remove_migration_pte de rmap_walk_file+0xcc/0x130 rmap_walk_file de remove_migration_ptes+0x90/0xa4 remove_migration_ptes de migration_pages_batch+0x6d4/0x858 migration_pages_batch de migration_pages+0x188/0x488 migration_pages de compact_zone+0x56c/0x954 compact_zone de compact_node+0x90/0xf0 compact_node de kcompactd+0x1d4/0x204 kcompactd de kthread+0x120/0x12c kthread de ret_from_fork+0x14/0x38 Pila de excepciones (0xc0d8bfb0 a 0xc0d8bff8) Para solucionarlo, no confíe en si 'ptl' es igual para decidir si mantener el bloqueo pte, sino decídalo en función de si CONFIG_SPLIT_PTE_PTLOCKS está habilitado. Además, si dos máquinas virtuales asignan a la misma página PTE, no es necesario volver a bloquear la página PTE; de lo contrario, se producirá un bloqueo. Simplemente agregue el parámetro need_lock para que adjust_pte() conozca esta información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Corregir la desreferencia de puntero nulo en la cola KFD. A través de KFD IOCTL Fuzzing, encontramos una desreferencia de puntero nulo al llamar a kfd_queue_acquire_buffers. (seleccionado de el commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rapidio: se corrige un error de API cuando rio_add_net() falla. rio_add_net() llama a device_register() y falla cuando device_register() falla. Por lo tanto, se debe usar put_device() en lugar de kfree(). Se agregó "mport->net = NULL;" para evitar un problema de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rapidio: añadir comprobación de rio_add_net() en rio_scan_alloc_net(). Se debe comprobar el valor de retorno de rio_add_net(). Si falla, se debe ejecutar put_device() para liberar memoria y ceder la referencia inicializada en rio_add_net().