Vulnerabilidades

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: 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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: samsung: exynos-chipid: Se ha añadido una comprobación de puntero nulo en exynos_chipid_probe(). soc_dev_attr->revision podría ser nulo, por lo que se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en el commit 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: Añadir comprobación de puntero nulo en i3c_master_queue_ibi(). El controlador maestro I3C puede recibir una IBI de un dispositivo de destino que aún no se ha sondeado. En tales casos, el maestro llama a `i3c_master_queue_ibi()` para poner en cola una tarea de trabajo IBI, lo que genera el error "No se puede manejar la lectura del kernel desde memoria ilegible" y provoca un pánico del kernel. Flujo típico de manejo de IBI: 1. El maestro I3C escanea los dispositivos de destino y sondea sus respectivos controladores. 2. El controlador del dispositivo de destino llama a `i3c_device_request_ibi()` para habilitar IBI y asigna `dev->ibi = ibi`. 3. El maestro I3C recibe una IBI del dispositivo de destino y llama a `i3c_master_queue_ibi()` para poner en cola la tarea de manejo de IBI del controlador del dispositivo de destino. Sin embargo, dado que los eventos del dispositivo de destino son asíncronos a la secuencia de sondeo I3C, el paso 3 puede ocurrir antes del paso 2, lo que provoca que `dev->ibi` sea `NULL` y provoque un pánico del kernel. Agregue una comprobación de puntero NULL en `i3c_master_queue_ibi()` para evitar el acceso a un `dev->ibi` sin inicializar, garantizando así la estabilidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: ene-kb3930: Se corrige una posible desreferencia de puntero nulo. El valor off_gpios podría ser nulo. Se añade la comprobación faltante en kb3930_probe(). Esto es similar al problema corregido en el commit b1ba8bcb2d1f ("backlight: hx8357: Se corrige una posible desreferencia de puntero nulo"). Esto fue detectado por nuestra herramienta de análisis estático.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: se corrige el puntero NULL en can_accept_new_subflow Al probar la herramienta de evaluación comparativa valkey con MPTCP, el kernel entra en pánico en 'mptcp_can_accept_new_subflow' porque subflow_req->msk es NULL. Rastreo de llamadas: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminador 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... Según el registro de depuración, la misma solicitud recibió dos SYN-ACK en muy poco tiempo, probablemente porque el cliente retransmite el SYN-ACK por varias razones. Incluso si los paquetes se transmiten con un intervalo de tiempo relevante, el servidor puede procesarlos en diferentes CPU simultáneamente. La propiedad de 'subflow_req->msk' se transfiere primero al subflujo, lo que conlleva el riesgo de una desreferencia de puntero nulo. Este parche corrige este problema moviendo 'subflow_req->msk' bajo la condición `own_req == true`. Tenga en cuenta que la comprobación !msk en subflow_hmac_valid() puede omitirse, ya que ya existe en la rama own_req de mpj, donde se ha movido el código.