Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vf: No intente activar un reinicio completo de GT si VF Los VF no tienen acceso al registro GDRST(0x941c) que el controlador usa para reiniciar un GT. Intento de activar un reinicio usando debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset o debido a una condición de bloqueo detectada por el controlador conduce a: [ ] xe 0000:00:02.1: [drm] GT0: intentando reiniciar desde force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reinicio en cola [ ] xe 0000:00:02.1: [drm] GT0: reinicio iniciado [ ] ------------[ cortar aquí ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF está intentando escribir 0x1 en un registro inaccesible 0x941c+0x0 [ ] ADVERTENCIA: CPU: 3 PID: 3069 en controladores/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Rastreo de llamadas: [ ] [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? Solucione esto enviando la acción H2G VF_RESET(0x5507) en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar la escritura OOB en la región sfr. sfr->buf_size se encuentra en memoria compartida y puede ser modificado por un usuario malintencionado. Es posible escribir OOB cuando el tamaño es mayor que el del búfer de datos sfr. En estos casos, limite el tamaño al tamaño asignado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar el tamaño incorrecto de queue size qsize representa el tamaño de la cola compartida entre el controlador y el firmware de vídeo. El firmware puede modificar este valor a un valor grande no válido. En tal situación, el espacio vacío será mayor que el espacio realmente disponible. Dado que new_wr_idx no se comprueba, el siguiente código resultará en una escritura fuera de banda (OOB). ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> Escritura fuera de banda (OOB). Se ha añadido una comprobación para garantizar que qsize se encuentre dentro del tamaño asignado al leer y escribir paquetes en la cola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: añadir comprobación para evitar accesos fuera de los límites. Existe la posibilidad de que init_codecs se invoque varias veces durante la manipulación de la carga útil del firmware de vídeo. En tal caso, si codecs_count se incrementa a un valor superior a MAX_CODEC_NUM, puede haber accesos fuera de los límites. Restablezca el contador para que siempre comience desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: refactorización de la lógica de análisis de paquetes HFI. words_count indica el número de palabras en el payload total, mientras que data apunta al payload de varias propiedades dentro de ella. Cuando words_count alcanza la última palabra, data puede acceder a memoria más allá de payload total. Esto puede provocar accesos fuera de banda (OOB). Con este parche, la API de utilidad para gestionar propiedades individuales ahora devuelve el tamaño de los datos consumidos. Por consiguiente, los bytes restantes se calculan antes de analizar el payload, eliminando así las posibilidades de accesos fuera de banda (OOB).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: Corrección de la competencia entre unprepare y queue_buf. Un controlador de cliente podría usar mhi_unprepare_from_transfer() para silenciar los datos entrantes durante su desconexión. El controlador de cliente también podría estar procesando datos simultáneamente, lo que resulta en una llamada a mhi_queue_buf(), que invocará mhi_gen_tre(). Si mhi_gen_tre() se ejecuta después de que mhi_unprepare_from_transfer() haya desconectado el canal, se producirá un pánico debido a una desreferencia no válida que provoca un fallo de página. Esto ocurre porque mhi_gen_tre() no verifica el estado del canal después de bloquearlo. Para solucionar esto, haga que mhi_gen_tre() confirme que el estado del canal es válido o devuelva un error para evitar acceder a los datos desinicializados. [mani: etiqueta estable añadida]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm/crc-t10dif: corrige el uso de una matriz fuera de alcance en crc_t10dif_arch() Corrige un error tonto en el que se usaba una matriz fuera de su alcance.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/net: corrección del abuso de io_req_post_cqe por parte del paquete de envío [ 114.987980][ T5313] ADVERTENCIA: CPU: 6 PID: 5313 en io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0 [ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0 [ 115.001880][ T5313] Rastreo de llamadas: [ 115.002222][ T5313] [ 115.007813][ T5313] io_send+0x4fe/0x10f0 [ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740 [ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0 [ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600 [ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0 Como se indica en el comentario, io_req_post_cqe() solo debe usarse en solicitudes multienvío, como REQ_F_APOLL_MULTISHOT, que no se usan en envíos agrupados. Agregue un indicador que indique si una solicitud desea publicar múltiples CQE. Finalmente, REQ_F_APOLL_MULTISHOT debería implicar la nueva bandera, pero esto se omite para simplificar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/crc-t10dif: se corrige el uso de una matriz fuera de alcance en crc_t10dif_arch() Se corrige un error tonto en el que se usaba una matriz fuera de su alcance.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: Se corrige el acceso a la IRQ liberada affinity_hint. La máscara cpu no debe ser una variable local, ya que su puntero se guarda en irq_desc y se puede acceder desde procfs. Para corregirla, utilice la máscara persistente cpumask_of(cpu#).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Se corrige una fuga de recursos relacionada con el dispositivo scp durante la inicialización del firmware. En dispositivos Mediatek con un procesador complementario del sistema (SCP), la estructura mtk_scp debe eliminarse explícitamente para evitar una fuga de recursos. Libere la estructura en caso de que la asignación de la estructura del firmware falle durante la inicialización.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el error de uno en uno en do_split Syzkaller detectó un problema de use-after-free en ext4_insert_dentry que fue causado por un acceso fuera de los límites debido a una división incorrecta en do_split. ERROR: KASAN: use-after-free en ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Escritura de tamaño 251 en la dirección ffff888074572f14 por la tarea syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 No contaminado 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 30/10/2024 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f El siguiente bucle se encuentra justo encima de la declaración 'if'. for (i = count-1; i >= 0; i--) { /* ¿hay más de la mitad de esta entrada en la 2da mitad del bloque? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } En este caso, la 'i' podría bajar a -1, en cuyo caso la suma de las entradas activas no superaría la mitad del tamaño del bloque. Sin embargo, el comportamiento anterior también se dividiría por la mitad si la suma superara el tamaño del último bloque. Esto, al tener demasiados archivos con nombres largos en un solo bloque, podría provocar un acceso fuera de los límites y el consiguiente uso después de la liberación. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.