Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: octeontx2-pf: corrige la fuga de recursos del programador de transmisión. Para admitir la configuración y la programación, al crear la clase, el controlador Netdev asigna programadores de transmisión. El parche anterior que agregó soporte para la programación por turnos tiene un error debido a que el controlador no libera los programadores de transmisión después de la eliminación de la clase. Este parche soluciona lo mismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/chrome: cros_ec_uart: corrige correctamente la condición de ejecución. La función cros_ec_uart_probe() llama a devm_serdev_device_open() antes de llamar a serdev_device_set_client_ops(). Esto puede desencadenar una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000... Seguimiento de llamadas: ...? ttyport_receive_buf Una versión simplificada del código de bloqueo es la siguiente: static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev; if (!serdev || !serdev->ops->receive_buf) // ¡CRASH! devolver 0; devolver serdev->ops->receive_buf(serdev, datos, recuento); } Se supone que si SERPORT_ACTIVE está configurado y serdev existe, serdev->ops también existirá. Esto entra en conflicto con la lógica cros_ec_uart_probe() existente, ya que primero llama a devm_serdev_device_open() (que configura SERPORT_ACTIVE), y solo luego configura serdev->ops a través de serdev_device_set_client_ops(). La confirmación 01f95d42b8f4 ("plataforma/chrome: cros_ec_uart: arreglar condición de ejecución") intentó arreglar una condición de ejecución similar, pero al hacerlo, hizo que la ventana de error para que esta condición de ejecución ocurriera fuera mucho más amplia. Intente corregir la condición de ejecución nuevamente, asegurándose de realizar la configuración completa antes de llamar a devm_serdev_device_open().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: corrija la pérdida de memoria en hci_req_sync_complete() En 'hci_req_sync_complete()', libere siempre el estado de solicitud de sincronización anterior antes de asignar una referencia a una nueva.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: raid1: corrige el uso después de liberar la biografía original en raid1_write_request() r1_bio->bios[] se usa para registrar nuevas biografías que se emitirán a los discos subyacentes; sin embargo, en raid1_write_request(), r1_bio->bios[] se configurará temporalmente en la biografía original. Mientras tanto, si se establece rdev bloqueado, se llamará a free_r1bio() causando que todos los r1_bio->bios[] sean liberados: raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] es NULL para (i = 0; i < discos; i++) -> para cada rdev en conf // el primer rdev es normal r1_bio->bios[0] = bio; -> establecer en biografía original // el segundo rdev está bloqueado si (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> biografía original es Scripts de prueba liberados: mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs= 1 \ -io Depth=128 -name=test -direct=1 eco bloqueado > /sys/block/md0/md/rd2/state Resultado de la prueba: ERROR bio-264 (No contaminado): Objeto ya libre ------ -------------------------------------------------- --------------------- Asignado en mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e /0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Liberado en mempool_free_slab +0x1f/0x30 edad=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_ request+0xadf/0x1150 md_handle_request+ 0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 _write_iter+0x309/0x440 aio_write+0x139/0x2f0 Dado que las BIOS para los discos subyacentes son aún no asignado, solucione este problema usando mempool_free() directamente para liberar r1_bio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: tlb: corrige el operando TLBI RANGE KVM/arm64 se basa en la función TLBI RANGE para vaciar los TLB cuando VMM recopila las páginas sucias y las entradas de la tabla de páginas quedan protegidas contra escritura durante la migración en vivo. . Desafortunadamente, el operando pasado a la instrucción TLBI RANGE no está ordenado correctamente debido a la confirmación 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). Esto provoca un bloqueo en la máquina virtual de destino después de la migración en vivo porque los TLB no se vacían por completo y se omiten algunas de las páginas sucias. Por ejemplo, tengo una máquina virtual a la que se asignan 8 GB de memoria, a partir de 0x40000000 (1 GB). Tenga en cuenta que el host tiene 4 KB como tamaño de página base. En medio de la migración, se ejecuta kvm_tlb_flush_vmid_range() para vaciar los TLB. Pasa MAX_TLBI_RANGE_PAGES como argumento para __kvm_tlb_flush_vmid_range() y __flush_s2_tlb_range_op(). SCALE#3 y NUM#31, correspondientes a MAX_TLBI_RANGE_PAGES, no son compatibles con __TLBI_RANGE_NUM(). En este caso específico, -1 ha sido devuelto por __TLBI_RANGE_NUM() para SCALE#3/2/1/0 y rechazado por el bucle en __flush_tlb_range_op() hasta que la variable @scale se desborda por debajo y se convierte en -9, 0xffff708000040000 se establece como el operando. El operando es incorrecto ya que __TLBI_VADDR_RANGE() lo ordena según @scale y @num no válidos. Solucionelo extendiendo __TLBI_RANGE_NUM() para admitir la combinación de SCALE#3 y NUM#31. Con los cambios, [-1 31] en lugar de [-1 30] se puede devolver desde la macro, lo que significa que los TLB para páginas 0x200000 en el ejemplo anterior se pueden vaciar de una vez con ESCALA#3 y NUM#31. La macro TLBI_RANGE_MASK se elimina porque ya nadie la usa. Los comentarios también se adaptan en consecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: no enviar clave RSS si no es compatible. Hay un error al configurar las opciones de RSS en virtio_net que puede dañar toda la máquina, haciendo que el kernel entre en un bucle infinito. Ejecutar el siguiente comando en cualquier máquina virtual QEMU con virtionet reproducirá este problema: # ethtool -X eth0 hfunc toeplitz Así es como ocurre el problema: 1) ethtool_set_rxfh() llama a virtnet_set_rxfh() 2) virtnet_set_rxfh() llama a virtnet_commit_rss_command() 3) virtnet_commit_rss_command() completa 4 entradas para rss scatter-gather 4) Dado que el comando anterior no tiene una clave, la última entrada de scatter-gatter se pondrá a cero, ya que rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) Este búfer se pasa a qemu, pero qemu no está contento con un búfer con longitud cero, y haga lo siguiente en virtqueue_map_desc() (función QEMU): if (!sz) { virtio_error(vdev, "virtio: buffers de tamaño cero no están permitidos"); 6) virtio_error() (también función QEMU) configura el dispositivo como roto vdev->broken = true; 7) Qemu se retira y no responde a este kernel loco. 8) El kernel está esperando a que regrese la respuesta (función virtnet_send_command()) 9) El kernel está esperando haciendo lo siguiente: while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) Ninguna de las siguientes funciones anteriores es verdadera, por lo tanto, el núcleo se repite aquí para siempre. Teniendo en cuenta que virtqueue_is_broken() no mira el qemu `vdev->broken`, por lo tanto, nunca se da cuenta de que el vitio está roto en el lado de QEMU. Solucionelo no enviando comandos RSS si la función no está disponible en el dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: Evite el bucle infinito al intentar cambiar el tamaño del TT local. Si la MTU de una de las interfaces conectadas se vuelve demasiado pequeña para transmitir la tabla de traducción local, entonces se debe cambiar su tamaño para que quepa dentro. todos los fragmentos (cuando está habilitado) o un solo paquete. Pero si la MTU es demasiado baja para transmitir incluso el encabezado + la parte específica de la VLAN, entonces el cambio de tamaño del TT local nunca tendrá éxito. Esto puede suceder, por ejemplo, cuando el espacio utilizable es de 110 bytes y hay 11 VLAN encima de batman-adv. En este caso, se necesitarían al menos 116 bytes. Simplemente habrá un spam interminable de batman_adv: batadv0: Obligado a purgar las entradas tt locales para ajustar el nuevo fragmento máximo MTU (110) en el registro, pero la función nunca finalizará. El problema aquí es que el tiempo de espera se reducirá a la mitad todo el tiempo y luego se estancará en 0 y, por lo tanto, nunca podrá reducir la tabla aún más. Hay otros escenarios posibles con un resultado similar. El número de entradas BATADV_TT_CLIENT_NOPURGE en el TT local puede, por ejemplo, ser demasiado alto para caber dentro de un paquete. Por lo tanto, este escenario puede ocurrir también con una sola VLAN + 7 direcciones no purgables, lo que requiere al menos 120 bytes. Si bien esto debe manejarse de manera proactiva cuando: * se agrega una interfaz con una MTU demasiado baja * se agrega una VLAN * se agrega una mac local no purgable * se reduce la MTU de una interfaz conectada * la configuración de fragmentación se desactiva (lo que probablemente requiera eliminar las interfaces conectadas) No todos estos escenarios se pueden prevenir porque batman-adv solo consume eventos sin la posibilidad de evitar estas acciones (se agrega una dirección MAC no purgable, se reduce la MTU de una interfaz adjunta). Por lo tanto, también es necesario asegurarse de que el código sea capaz de manejar también las situaciones en las que ya había una configuración del sistema incompatible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: límites: utilice el número correcto de bits para potencia de dos CONFIG_NR_CPUS bits_per() redondea a la siguiente potencia de dos cuando se pasa una potencia de dos. Esto provoca fallos en algunas máquinas y configuraciones.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: smbus: corrige la desreferencia del puntero de función NULL. Baruch informó de un OOPS al usar el controlador de designware como destino únicamente. Los modos de solo objetivo rompen el supuesto de que siempre hay una función de transferencia disponible. Solucione este problema comprobando siempre el puntero en __i2c_transfer. [wsa: abandonó la simplificación en core-smbus para evitar regresiones teóricas]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/eevdf: evita que vlag se salga de los límites en reweight_eevdf(). Era posible que pick_eevdf() devolviera NULL, lo que luego causa un NULL-deref. Esto resultó ser debido a que entidad_eligible() devolvió un resultado falso negativo debido a un desbordamiento de multiplicación s64. Específicamente, reweight_eevdf() calcula el vlag sin considerar el límite impuesto a vlag como lo hace update_entity_lag(), y luego la multiplicación de escala (recuerde que el peso es un punto fijo de 20 bits) puede desbordarse. Esto luego lleva a que el nuevo vruntime sea extraño, lo que luego hace que la entidad_eligible() anterior se desvíe y afirme que nada es elegible. Por lo tanto, limite el rango de vlag en consecuencia. Todo esto fue bastante raro, pero fatal cuando sucede.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: ti: tusb1210: resolver el bloqueo del cargador-det si el cargador psy no está registrado. El marco power_supply no está realmente manipulado para que haya referencias duraderas en el kernel a los dispositivos power_supply. Específicamente, cancelar el registro de un power_supply mientras algún otro código tiene una referencia a él activa una ADVERTENCIA en power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Seguido por power_supply aún se elimina y los datos de respaldo se liberan de todos modos, dejando el código de detección del cargador tusb1210 con una referencia colgante, lo que resulta en un bloqueo la próxima vez que se llama a tusb1210_get_online(). Solucione este problema manteniendo únicamente la referencia en tusb1210_get_online() liberándola al final de la función. Tenga en cuenta que esto aún deja una ventana de ejecución teórica, pero evita el problema al modificar manualmente el controlador del chip del cargador durante el desarrollo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xsk: validar la entrada del usuario para XDP_{UMEM|COMPLETION}_FILL_RING syzbot informó una copia ilegal en xsk_setsockopt() [1] Asegúrese de validar el parámetro @optlen setsockopt(). [1] BUG: KASAN: losa fuera de límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] ERROR: KASAN: losa fuera de límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de límites en xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Lectura de tamaño 4 en la dirección ffff888028c6cde3 mediante la tarea syz-executor.0/7549 CPU: 0 PID: 7549 Comm: syz-executor.0 No contaminado 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack .c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/ 0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] copy_from_sockptr include/linux/sockptr.h:55 [en línea] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] x64_sys_setsockopt+0xb5/ 0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 0c8 EFLAGS: 00000246 ORIG_RAX : 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 000000000 0000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 000000000 0000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Asignado por tarea 7549: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 veneno_kmalloc_redzone mm/kasan/common.c:370 [en línea] __kasan_kmalloc+0x98/ 0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [en línea] __do_kmalloc_node mm/slub.c:3966 [en línea] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux /slab.h:632 [en línea] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 334 __do_sys_setsockopt net/ socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 El error la dirección pertenece al objeto en ffff888028c6cde0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 1 byte a la derecha de la región asignada de 2 bytes [ffff888028c6cde0, ffff888028c6cde2) La dirección con errores pertenece a la página física: página:ffffea0000a31b00 refcount:1 mapcount:0 Mapeo: 00000000000000000000 ÍNDICE: 0xffff888028c6c9c0 pfn: 0x28c6c Anon Flags: 0xffff00000000800 (Slab | Node = 0 | Zone = 1 | LastCpupid = 0x7ff) Page_Type: 0xffffffffffff () RAW: 00FFF000000800 0000000000000000 Dead000000000001 Raw: FFFFF888028C6C9C0 000000000080800057 00000001FFFFFFFFFFFFFFF 0000000000000000 Página arrojada porque: Kasan : mal acceso detectado page_owner rastrea la página como página asignada por última vez mediante orden 0, migrar tipo Inamovible, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set _page_owner incluye /linux/page_owner.h:31 [en línea] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncado---