Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: tc358743: registre el dispositivo asíncrono v4l2 solo después de una configuración exitosa Asegúrese de que el dispositivo se haya configurado correctamente antes de registrar el dispositivo asíncrono v4l2, permitiendo así el acceso al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corregida la liberación de páginas fijadas cuando falla __io_uaddr_map. Mirando la ruta de error de __io_uaddr_map, si fallamos después de fijar las páginas por cualquier motivo, ret se establecerá en -EINVAL y el El controlador de errores no libera correctamente las páginas fijadas. No logré activarlo sin forzar un fallo, pero puede suceder en la vida real cuando la memoria está muy fragmentada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcachefs: kvfree bch_fs::snapshots en bch2_fs_snapshots_exit bch_fs::snapshots es asignado por kvzalloc en __snapshot_t_mut. Debería ser liberado por kvfree, no por kfree. O desmontar activará: [406.829178] ERROR: no se puede manejar el error de página para la dirección: ffffe7b487148008 [406.830676] #PF: acceso de lectura del supervisor en modo kernel [406.831643] #PF: error_code(0x0000) - página no presente [406.832487] PGD 0 P4D 0 [ 406.832898 ] Vaya: 0000 [#1] PREEMPT SMP PTI [ 406.833512 ] CPU: 2 PID: 1754 Comunicaciones: desmontar Kdump: cargado Contaminado: G OE 6.7.0-rc7-custom+ #90 [ 406.834746 ] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 01/04/2014 [ 406.835796 ] RIP: 0010:kfree+0x62/0x140 [ 406.836197 ] Código: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 <48> 8b 50 08 48 89 c7 f6 01 0f 85b0 00 00 00 66 90 48 8b 07 f6 [ 406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286 [ 406.838213 ] RAX: ffffe7b487148000 RBX: 0000 RCX: ffffb9d641607dc4 [ 406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000 [ 406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 00000000000000001 [ 406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80 [ 406.8 40055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000 [ 406.840451 ] FS: 00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000 [ 406.840851 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0 [ 406.841 464 ] Seguimiento de llamadas: [ 406.841583 ] [ 406.841682 ] ? __die+0x1f/0x70 [ 406.841828 ] ? page_fault_oops+0x159/0x470 [406.842014]? fixup_exception+0x22/0x310 [406.842198]? exc_page_fault+0x1ed/0x200 [406.842382]? asm_exc_page_fault+0x22/0x30 [406.842574]? bch2_fs_release+0x54/0x280 [bcachefs] [406.842842]? kfree+0x62/0x140 [ 406.842988 ] ? kfree+0x104/0x140 [ 406.843138 ] bch2_fs_release+0x54/0x280 [bcachefs] [ 406.843390 ] kobject_put+0xb7/0x170 [ 406.843552 ] desactivar_locked_super+0x2f/0xa0 [ 406.843 756 ] cleanup_mnt+0xba/0x150 [ 406.843917 ] task_work_run+0x59/0xa0 [ 406.844083 ] exit_to_user_mode_prepare+0x197/0x1a0 [ 406.844302 ] syscall_exit_to_user_mode+0x16/0x40 [ 406.844510 ] do_syscall_64+0x4e/0xf0 [ 406.844675 entrada_SYSCALL_64_after_hwframe +0x6e/0x76 [ 406.844907 ] RIP: 0033:0x7f0a2664e4fb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: fsl-qdma: corregida una pérdida de memoria relacionada con el comando de cola DMA. Este dma_alloc_coherent() no se deshace ni en la función de eliminación ni en la ruta de manejo de errores de fsl_qdma_probe() . Cambie a la versión administrada para solucionar ambos problemas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: corregida una fuga de mem en lima_heap_alloc Cuando falla lima_vm_map_bo, es necesario desasignar los recursos o habrá fugas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: lis3lv02d_i2c: corrige que los reguladores se activen/desactiven dos veces al suspender/reanudar Cuando no está configurado para reactivación, lis3lv02d_i2c_suspend() llamará a lis3lv02d_poweroff() incluso si el dispositivo ya ha sido desactivado por el controlador de suspensión de tiempo de ejecución y si está configurado para reactivación y el dispositivo está suspendido en tiempo de ejecución en este punto, no se vuelve a activar para que sirva como fuente de activación. Antes de la confirmación b1b9f7a49440 ("misc: lis3lv02d_i2c: Agregar configuración faltante de la devolución de llamada reg_ctrl"), lis3lv02d_poweroff() fallaba al deshabilitar los reguladores, lo que como efecto secundario hizo que llamar a poweroff() dos veces fuera correcto. Ahora que poweroff() desactiva correctamente los reguladores, al hacer esto dos veces se activa una ADVERTENCIA() en el núcleo del regulador: desactivaciones desequilibradas para regulador ficticio ADVERTENCIA: CPU: 1 PID: 92 en drivers/regulator/core.c:2999 _regulator_disable .. Corrija lis3lv02d_i2c_suspend() para que no llame a poweroff() una segunda vez si ya está suspendido el tiempo de ejecución y agregue una llamada a poweron() cuando sea necesario para que la reactivación funcione. lis3lv02d_i2c_resume() tiene problemas similares, con el inconveniente adicional de que siempre enciende el dispositivo si el tiempo de ejecución está suspendido, después de lo cual la primera reanudación del tiempo de ejecución llamará a poweron() nuevamente, lo que provocará que el recuento habilitado para el regulador aumente en 1 cada suspender/reanudar. Estas llamadas desequilibradas regulator_enable() hacen que el regulador nunca se apague y activan la siguiente ADVERTENCIA() al desvincular el controlador: ADVERTENCIA: CPU: 1 PID: 1724 en drivers/regulator/core.c:2396 _regulator_put Solucione esto haciendo lis3lv02d_i2c_resume( ) refleja la nueva suspensión().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: ncm: corregido el manejo de paquetes de longitud de bloque cero Al conectarnos a un host Linux con CDC_NCM_NTB_DEF_SIZE_TX configurado en 65536, se ha observado que recibimos paquetes cortos, que vienen en intervalo de 5 a 10 segundos a veces y tiene una longitud de bloque cero, pero aún contiene 1 o 2 datagramas válidos presentes. Según la especificación NCM: "Si wBlockLength = 0x0000, el bloque finaliza con un paquete corto. En este caso, la transferencia USB aún debe ser más corta que dwNtbInMaxSize o dwNtbOutMaxSize. Si se envían exactamente bytes dwNtbInMaxSize o dwNtbOutMaxSize, y el tamaño es un múltiplo de wMaxPacketSize para la pipe dada, entonces no se enviará ningún ZLP. wBlockLength= 0x0000 debe usarse con extremo cuidado, debido a la posibilidad de que el host y el dispositivo no estén sincronizados y debido a problemas de prueba con wBlockLength = 0x0000. permite al remitente reducir la latencia comenzando a enviar un NTB muy grande y luego acortándolo cuando el remitente descubre que no hay datos suficientes para justificar el envío de un NTB grande". Sin embargo, existe un problema potencial con la implementación actual, ya que verifica para la aparición de múltiples NTB en una sola devolución verificando si los bytes sobrantes a procesar son cero o no. Si la longitud del bloque es cero, procesaríamos el mismo NTB infinitamente porque los bytes sobrantes nunca son cero y provocan un bloqueo. Solucione este problema rescatando si la longitud del bloque es cero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: corregidos recuentos de páginas para buffers no alineados en __bio_release_pages() Corrige un número incorrecto de páginas que se liberan para buffers que no comienzan al principio de una página.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: libertas: arreglados algunas memleaks en lbs_allocate_cmd_buffer() En la declaración for de lbs_allocate_cmd_buffer(), si falló la asignación de cmdarray[i].cmdbuf, tanto cmdarray como cmdarray[i] Es necesario liberar ].cmdbuf. De lo contrario, habrá fugas de memoria en lbs_allocate_cmd_buffer().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/net: corregida la comprobación de desbordamiento en io_recvmsg_mshot_prep() La variable "controllen" es de tipo size_t (largo sin firmar). Convertirlo a int podría provocar un desbordamiento de números enteros. La función check_add_overflow() considera el tipo de destino que es de tipo int. Si sumamos dos valores positivos y el resultado no cabe en un número entero, entonces se cuenta como un desbordamiento. Sin embargo, si convertimos "controllen" en un int y se vuelve negativo, entonces los valores negativos *pueden* caber en un tipo int para que no haya desbordamiento. Bueno: 100 + (unsigned long)-4 = 96 <-- overflow Malo: 100 + (int)-4 = 96 <-- no overflow También eliminé el cast de sizeof(). Eso no es un error, pero el cast es innecesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: establece la actualización de la página en el lugar correcto. Las lecturas de la caché de la página no tienen bloqueo, por lo que configurar la actualización de la página recién asignada antes de que la sobrescribamos con los datos que se supone que debe contener lo hará. permitir que un lector simultáneo vea datos antiguos. Mueva la llamada a SetPageUptodate a ubifs_write_end(), que es después de que copiamos los nuevos datos en la página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug().