Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dev/parport: corrige el riesgo de que la matriz esté fuera de los límites. Se corrigieron los problemas de matriz fuera de los límites causados por sprintf reemplazándolo con snprintf para una copia de datos más segura, garantizando el búfer de destino no está desbordado. A continuación se muestra el seguimiento de la pila que encontré durante el problema real: [66.575408s] [pid:5118,cpu4,QThread,4]Pánico en el kernel: no se sincroniza: stack-protector: la pila del kernel está dañada en: do_hardware_base_addr+0xcc/0xd0 [parport ] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comunicación: QThread contaminado: GSWO 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4, QThread,6]TGID: 5087 Comm: EFileApp [66.575439s] [pid:5118,cpu4,QThread,7]Nombre del hardware: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 29/04/2024 [66.575439 s] [pid:5118,cpu4,QThread,8]Rastreo de llamadas: [66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [66.575469s] [pid:5118,cpu4,QThread,0 ] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] pánico+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/DPC: corrige el use-after-free en DPC simultáneos y la eliminación en caliente. Keith informa un use-after-free cuando ocurre un evento de DPC simultáneamente con la eliminación en caliente del mismo. parte de la jerarquía: dpc_handler() espera que el bus secundario esté listo debajo del puerto descendente donde ocurrió el evento DPC. Para hacerlo, sondea el espacio de configuración del primer dispositivo secundario en el bus secundario. Si ese dispositivo secundario se elimina simultáneamente, los accesos a su estructura pci_dev hacen que el kernel falle. Esto se debe a que pci_bridge_wait_for_secondary_bus() no mantiene una referencia en el dispositivo secundario. Antes de v6.3, la función solo se llamaba al reanudar desde la suspensión del sistema o al reanudar el tiempo de ejecución. Mantener una referencia no era necesario en aquel entonces porque el subproceso pciehp IRQ nunca podía ejecutarse al mismo tiempo. (Al reanudar desde la suspensión del sistema, las IRQ no se habilitan hasta después de la fase resume_noirq. Y la reanudación del tiempo de ejecución siempre se espera antes de que se elimine un dispositivo PCI). Sin embargo, a partir de v6.3, pci_bridge_wait_for_secondary_bus() también se llama en un evento DPC. El commit 53b54ad074de ("PCI/DPC: Esperar la preparación del bus secundario después del reinicio"), que introdujo eso, no pudo apreciar que pci_bridge_wait_for_secundary_bus() ahora necesita mantener una referencia en el dispositivo secundario porque dpc_handler() y pciehp pueden ejecutarse simultáneamente. El commit fue respaldada a núcleos estables v5.10+, por lo que ese es el más antiguo afectado. Agregue la adquisición de referencia que falta. Seguimiento de pila abreviado: ERROR: no se puede manejar el error de página para la dirección: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() _hacer_recuperación () dpc_handler()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: asegúrese de que el primer bloque de directorio no sea un agujero. El syzbot construye un directorio que no tiene bloque de directorios pero que no está en línea, es decir, el primer bloque de directorio es un agujero. Y no se informan errores al crear archivos en este directorio en el siguiente flujo. ext4_mknod ... ext4_add_entry // Leer bloque 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // El primer bloque de directorio es un agujero // Pero escriba == DIRENT, por lo que no se informa ningún error. Después de eso, obtenemos un bloque de directorio sin '.' y '..' pero con un dentry válido. Esto puede provocar que algún código que depende de punto o punto punto (como make_indexed_dir()) falle. Por lo tanto, cuando ext4_read_dirblock() encuentra que el primer bloque de directorio es un agujero, informa que el sistema de archivos está dañado y devuelve un error para evitar cargar datos corruptos desde el disco y causar algo malo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: verifique el punto y el punto de dx_root antes de indexar el directorio Syzbot informa un problema de la siguiente manera: =================== ========================= ERROR: no se puede manejar el error de página para la dirección: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Ups: Ups: 0000 [#1 ] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 No contaminado 6.10.0-rc5-g55027e689933 #0 Seguimiento de llamada: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222 un /0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [en línea] text4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ======= ====================================== La causa inmediata de este problema es que sólo hay una válida dentry para que el bloque se divida durante do_split, por lo que split==0 da como resultado accesos fuera de los límites al mapa que desencadenan el problema. do_split división sin signo dx_make_map recuento = 1 división = recuento/2 = 0; continúa = hash2 == mapa[dividido - 1].hash; ---> map[4294967295] La longitud máxima de un nombre de archivo es 255 y el tamaño mínimo de bloque es 1024, por lo que siempre se garantiza que el número de entradas sea mayor o igual a 2 cuando se llama a do_split(). Pero la imagen manipulada por syzbot no tiene punto ni puntopunto en el directorio, y la distribución de dentry en dirblock es la siguiente: bus dentry1 agujero dentry2 gratis |xx--|xx-------------|... ............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 Entonces, cuando se cambia el nombre de dentry1 se aumenta la longitud de name_len en 1, ni el agujero ni el espacio libre son suficientes para contener el nuevo dentry, y make_indexed_dir() es llamado. En make_indexed_dir() se supone que las dos primeras entradas del bloque de directorios deben ser punto y puntopunto, por lo que bus y dentry1 se dejan en dx_root porque se tratan como punto y puntodot, y solo dentry2 se mueve al nuevo bloque de hoja. Es por eso que el recuento es igual a 1. Por lo tanto, agregue la función auxiliar ext4_check_dx_root() para agregar más controles de cordura a los puntos y puntos antes de comenzar la conversión para evitar el problema anterior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: udf: evite el uso del búfer de mapa de bits de bloque dañado Cuando el mapa de bits de bloque del sistema de archivos está dañado, detectamos la corrupción mientras cargamos el mapa de bits y fallamos la asignación con error. Sin embargo, la siguiente asignación del mismo mapa de bits notará que el búfer de mapa de bits ya está cargado e intentará realizar la asignación desde el mapa de bits con resultados mixtos (dependiendo de la naturaleza exacta de la corrupción del mapa de bits). Solucione el problema utilizando el bit BH_verified para indicar si el mapa de bits es válido o no.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cifs: corrige el posible uso de puntero nulo en destroy_workqueue en la ruta de error init_cifs Dan Carpenter informó una advertencia del verificador estático de Smack: fs/smb/client/cifsfs.c:1981 error init_cifs(): Anteriormente asumimos que 'serverclose_wq' podría ser nulo (ver línea 1895). El parche que introdujo la cola de trabajo serverclose utilizó un orden incorrecto en las rutas de error en init_cifs() para liberarlo de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/gma500: corrige la desreferencia del puntero nulo en psb_intel_lvds_get_modes En psb_intel_lvds_get_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mediatek: corrige la posible desreferencia del puntero NULL en el manejo del net_device ficticio. Mueva la liberación del net_device ficticio de mtk_free_dev() a mtk_remove(). Anteriormente, si alloc_netdev_dummy() fallaba en mtk_probe(), eth->dummy_dev sería NULL. La ruta de error luego llamaría a mtk_free_dev(), que a su vez llamaría a free_netdev() suponiendo que dummy_dev estuviera asignado (pero no lo estaba), causando potencialmente una desreferencia del puntero NULL. Al mover free_netdev() a mtk_remove(), nos aseguramos de que solo se llame cuando mtk_probe() haya tenido éxito y dummy_dev esté completamente asignado. Esto soluciona una posible desreferencia de puntero NULL detectada por Smatch[1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: mm: corrige recorridos sin bloqueo con plegado de tablas de páginas estáticas y dinámicas. Lina informa oopsen aleatorios que se originan en el código GUP rápido cuando se utilizan páginas de 16 KB con tablas de páginas de 4 niveles. el cuarto nivel se pliega en tiempo de ejecución debido a la falta de LPA2. En esta configuración, la implementación genérica de p4d_offset_lockless() devolverá un 'p4d_t *' correspondiente al 'pgd_t' asignado en la pila de la persona que llama, gup_fast_pgd_range(). Esto normalmente está bien, pero cuando el cuarto nivel de la tabla de páginas se pliega en tiempo de ejecución, pud_offset_lockless() se desplazará de la dirección de 'p4d_t' para calcular la dirección del PUD en la misma página de la tabla de páginas. Esto da como resultado una lectura de pila perdida cuando el 'p4d_t' se ha asignado en la pila y puede enviar al caminante hacia la maleza. Solucione el problema proporcionando nuestra propia definición de p4d_offset_lockless() cuando CONFIG_PGTABLE_LEVELS <= 4, que devuelve el puntero de la tabla de páginas real en lugar de la dirección de la variable de pila local.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: soluciona el punto muerto entre sd_remove y sd_release Nuestra prueba informa la siguiente tarea colgada: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI no configura GD_OWNS_QUEUE, por lo que QUEUE_FLAG_DYING no está configurado en este escenario. Este es un clásico punto muerto de ABBA. Para solucionar el punto muerto, asegúrese de no intentar adquirir disco->open_mutex después de congelar la cola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: soluciona un problema de segmento al degradar gso_size Lineariza el skb al degradar gso_size porque puede desencadenar un BUG_ON() más adelante cuando el skb se segmenta como se describe en [1,2].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: nexthop: inicializa todos los campos en la estructura nexthops volcada. nexthop_grp contiene dos campos reservados que no son inicializados por nla_put_nh_group() y transporta basura. Esto se puede observar, por ejemplo, con strace (editado para mayor claridad): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len =12, nla_type=NHA_GROUP}, [{id=1, peso=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 Los campos están reservados y, por lo tanto, no se utilizan actualmente. Pero tal como están, pierden memoria del núcleo, y el hecho de que no sean simplemente cero complica la reutilización de los campos para nuevos fines. Inicialice la estructura completa.