Vulnerabilidades

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> drm/exynos: vidi: usar ctx-&amp;gt;lock para proteger las variables miembro de la estructura vidi_context relacionadas con la asignación/liberación de memoria<br /> <br /> El controlador de pantalla virtual de Exynos realiza operaciones de asignación/liberación de memoria sin protección de bloqueo, lo que fácilmente causa un problema de concurrencia.<br /> <br /> Por ejemplo, el uso después de liberación puede ocurrir en un escenario de carrera como este:<br /> ```<br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> vidi_connection_ioctl()<br /> if (vidi-&amp;gt;connection) // true<br /> drm_edid = drm_edid_alloc(); // alloc drm_edid<br /> ...<br /> ctx-&amp;gt;raw_edid = drm_edid;<br /> ...<br /> drm_mode_getconnector()<br /> drm_helper_probe_single_connector_modes()<br /> vidi_get_modes()<br /> if (ctx-&amp;gt;raw_edid) // true<br /> drm_edid_dup(ctx-&amp;gt;raw_edid);<br /> if (!drm_edid) // false<br /> ...<br /> vidi_connection_ioctl()<br /> if (vidi-&amp;gt;connection) // false<br /> drm_edid_free(ctx-&amp;gt;raw_edid); // free drm_edid<br /> ...<br /> drm_edid_alloc(drm_edid-&amp;gt;edid)<br /> kmemdup(edid); // UAF!!<br /> ...<br /> ```<br /> <br /> Para prevenir estas vulnerabilidades, al menos en vidi_context, las variables miembro relacionadas con la asignación/liberación de memoria deberían ser protegidas con ctx-&amp;gt;lock.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> ksmbd: corrige un bucle infinito causado por el reinicio de next_smb2_rcv_hdr_off en las rutas de error<br /> <br /> El problema ocurre cuando una solicitud firmada falla la verificación de firma smb2. En __process_request(), si check_sign_req() devuelve un error, se llama a set_smb2_rsp_status(work, STATUS_ACCESS_DENIED). set_smb2_rsp_status() establece work-&amp;gt;next_smb2_rcv_hdr_off a cero. Al reiniciar next_smb2_rcv_hdr_off a cero, el puntero al siguiente comando en la cadena se pierde. En consecuencia, is_chained_smb2_message() continúa apuntando a la misma cabecera de solicitud en lugar de avanzar. Si el campo NextCommand de la cabecera no es cero, la función devuelve verdadero, lo que hace que __handle_ksmbd_work() procese repetidamente la misma solicitud fallida en un bucle infinito. Esto resulta en el registro del kernel siendo inundado con mensajes de &amp;#39;firma smb2 incorrecta&amp;#39; y un alto uso de CPU.<br /> <br /> Este parche corrige el problema cambiando el valor de retorno de SERVER_HANDLER_CONTINUE a SERVER_HANDLER_ABORT. Esto asegura que el bucle de procesamiento termine inmediatamente en lugar de intentar continuar desde un desplazamiento invalidado.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> bus: fsl-mc: corrección de uso después de liberación en driver_override_show()<br /> <br /> La función driver_override_show() lee la cadena driver_override sin mantener el device_lock. Sin embargo, driver_override_store() utiliza driver_set_override(), que modifica y libera la cadena mientras mantiene el device_lock.<br /> <br /> Esto puede resultar en un uso después de liberación concurrente si la cadena es liberada por la función store mientras es leída por la función show.<br /> <br /> Solucionar esto manteniendo el device_lock alrededor de la operación de lectura.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: omap - Asignar correctamente las scatterlists OMAP_CRYPTO_FORCE_COPY<br /> <br /> La asignación existente de scatterlists en omap_crypto_copy_sg_lists() estaba asignando un array de punteros a scatterlist, no objetos scatterlist, lo que resultaba en una asignación 4 veces demasiado pequeña.<br /> <br /> Usar sizeof(*new_sg) para obtener el tamaño de objeto correcto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> PCI: endpoint: Evitar la creación asíncrona de subgrupos<br /> <br /> La creación asíncrona de subgrupos por un trabajo retrasado podría llevar a una desreferencia de puntero NULL cuando el directorio del controlador es eliminado antes de que el trabajo se complete.<br /> <br /> El fallo puede ser fácilmente reproducido con los siguientes comandos:<br /> <br /> # cd /sys/kernel/config/pci_ep/functions/pci_epf_test<br /> # for i in {1..20}; do mkdir test &amp;amp;&amp;amp; rmdir test; done<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000088<br /> ...<br /> Call Trace:<br /> configfs_register_group+0x3d/0x190<br /> pci_epf_cfs_work+0x41/0x110<br /> process_one_work+0x18f/0x350<br /> worker_thread+0x25a/0x3a0<br /> <br /> Soluciona este problema usando la API configfs_add_default_group() que no tiene el problema de interbloqueo como configfs_register_group() y no requiere el manejador de trabajo retrasado.<br /> <br /> [mani: se ha reformulado ligeramente la descripción y se ha añadido la lista estable]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: qla2xxx: Retrasar la descarga del módulo mientras el escaneo de la estructura está en progreso<br /> <br /> Fallo del sistema observado durante la prueba de carga/descarga en un bucle.<br /> <br /> [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086<br /> [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0<br /> [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000<br /> [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000<br /> [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0<br /> [105954.384928] PKRU: 55555554<br /> [105954.384929] Call Trace:<br /> [105954.384931] <br /> [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx]<br /> [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx]<br /> [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx]<br /> [105954.384999] ? __wake_up_common+0x80/0x190<br /> [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx]<br /> [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx]<br /> [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190<br /> [105954.385044] ? handle_irq_event+0x58/0xb0<br /> [105954.385046] ? handle_edge_irq+0x93/0x240<br /> [105954.385050] ? __common_interrupt+0x41/0xa0<br /> [105954.385055] ? common_interrupt+0x3e/0xa0<br /> [105954.385060] ? asm_common_interrupt+0x22/0x40<br /> <br /> La causa raíz de esto fue que hubo una liberación (dma_free_attrs) en el contexto de interrupción. Había un descubrimiento de dispositivo/escaneo de la estructura en progreso. Se emitió una descarga de módulo que estableció la bandera UNLOADING. Como parte del descubrimiento, después de recibir una interrupción, se programó una cola de trabajo (lo que implicó un trabajo a encolar). Dado que la bandera UNLOADING está establecida, el elemento de trabajo no fue asignado y la memoria mapeada tuvo que ser liberada. La liberación ocurrió en el contexto de interrupción, lo que llevó a un fallo del sistema. Retrasar la descarga del controlador hasta que el escaneo de la estructura esté completo para evitar el fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> scsi: qla2xxx: Validar sp antes de liberar la memoria asociada<br /> <br /> Fallo del sistema con la siguiente firma<br /> [154563.214890] nvme nvme2: NVME-FC{1}: conexión del controlador completada<br /> [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Establecer el umbral de intercambio ZIO en 3.<br /> [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: ESTABLECER el umbral de intercambio de actividad ZIO en 5.<br /> [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 0080 0000.<br /> [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 00a0 0000.<br /> [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos).<br /> [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos).<br /> [154565.553079] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000f8<br /> [154565.553080] #PF: acceso de lectura de supervisor en modo kernel<br /> [154565.553082] #PF: error_code(0x0000) - página no presente<br /> [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0<br /> [154565.553089] Oops: 0000 1 PREEMPT SMP PTI<br /> [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: cargado Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1<br /> [154565.553096] Nombre del hardware: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 30/09/2024<br /> [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553141] Código: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 &amp;lt;4c&amp;gt; 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b<br /> [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286<br /> [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002<br /> [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47<br /> [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a<br /> [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0<br /> [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000<br /> [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000<br /> [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0<br /> [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [154565.553159] PKRU: 55555554<br /> [154565.553160] Traza de llamadas:<br /> [154565.553162] <br /> [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553215] ? __die_body.cold+0x8/0xd<br /> [154565.553218] ? page_fault_oops+0x134/0x170<br /> [154565.553223] ? snprintf+0x49/0x70<br /> [154565.553229] ? exc_page_fault+0x62/0x150<br /> [154565.553238] ? asm_exc_page_fault+0x22/0x30<br /> <br /> Verificar que sp no sea NULL antes de liberar cualquier memoria asociada

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nilfs2: Corrige un posible desbordamiento de bloque que causa un cuelgue del sistema<br /> <br /> Cuando un usuario ejecuta el comando FITRIM, puede ocurrir un subdesbordamiento al calcular nblocks si end_block es demasiado pequeño. Dado que nblocks es de tipo sector_t, que es u64, un valor negativo de nblocks se convertirá en un entero positivo muy grande. Esto finalmente lleva a que la función de la capa de bloques __blkdev_issue_discard() tarde un tiempo excesivamente largo en procesar la cadena bio, y el bloqueo ns_segctor_sem permanezca retenido durante un largo período. Esto impide que otras tareas adquieran el bloqueo ns_segctor_sem, lo que resulta en el cuelgue reportado por syzbot en [1].<br /> <br /> Si el bloque final es demasiado pequeño, típicamente si es menor que el rango de 4KiB, dependiendo del uso del segmento 0, puede ser posible intentar una solicitud de descarte más allá del tamaño del dispositivo, causando el cuelgue.<br /> <br /> Saliendo con éxito y asignando el tamaño descartado (0 en este caso) a range-&amp;gt;len.<br /> <br /> Aunque los valores de inicio y longitud en el rango de entrada del usuario son demasiado pequeños, se adopta aquí una estrategia conservadora para ignorarlos de forma segura, lo cual es equivalente a una no-op; no realizará ningún recorte y no lanzará un error.<br /> <br /> [1]<br /> tarea:segctord estado:D pila:28968 pid:6093 tgid:6093 ppid:2 flags_de_tarea:0x200040 flags:0x00080000<br /> Traza de Llamada:<br /> rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272<br /> nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]<br /> nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684<br /> <br /> [ryusuke: corregida parte del mensaje de commit sobre las consecuencias]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: rtl8xxxu: corrección de slab-out-of-bounds en rtl8xxxu_sta_add<br /> <br /> El controlador no establece hw-&amp;gt;sta_data_size, lo que provoca que mac80211 asigne espacio insuficiente para los datos privados de estación del controlador en __sta_info_alloc(). Cuando rtl8xxxu_sta_add() accede a miembros de struct rtl8xxxu_sta_info a través de sta-&amp;gt;drv_priv, esto resulta en una escritura slab-out-of-bounds.<br /> <br /> Informe KASAN en RISC-V (VisionFive 2) con adaptador RTL8192EU:<br /> <br /> BUG: KASAN: slab-out-of-bounds en rtl8xxxu_sta_add+0x31c/0x346<br /> Escritura de tamaño 8 en la dirección ffffffd6d3e9ae88 por la tarea kworker/u16:0/12<br /> <br /> Establecer hw-&amp;gt;sta_data_size a sizeof(struct rtl8xxxu_sta_info) durante probe, de forma similar a cómo se configura hw-&amp;gt;vif_data_size. Esto asegura que mac80211 asigne espacio suficiente para los datos privados por estación del controlador.<br /> <br /> Probado en placa StarFive VisionFive 2 v1.2A.

ZoneMinder v1.36.34 es vulnerable a inyección de comandos en web/views/image.PHP. La aplicación pasa entrada de usuario no saneada directamente a la función exec().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: qla2xxx: Liberar sp en la ruta de error para corregir el fallo del sistema<br /> <br /> Fallo del sistema observado durante la prueba de carga/descarga en un bucle,<br /> <br /> [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.<br /> [61110.467494] =============================================================================<br /> [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()<br /> [61110.467501] -----------------------------------------------------------------------------<br /> <br /> [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)<br /> [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1<br /> [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023<br /> [61110.467515] Call Trace:<br /> [61110.467516] <br /> [61110.467519] dump_stack_lvl+0x34/0x48<br /> [61110.467526] slab_err.cold+0x53/0x67<br /> [61110.467534] __kmem_cache_shutdown+0x16e/0x320<br /> [61110.467540] kmem_cache_destroy+0x51/0x160<br /> [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx]<br /> [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280<br /> [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0<br /> [61110.467616] ? do_syscall_64+0x5c/0x90<br /> [61110.467619] ? exc_page_fault+0x62/0x150<br /> [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [61110.467626] <br /> [61110.467627] Disabling lock debugging due to kernel taint<br /> [61110.467635] Object 0x0000000026f7e6e6 @offset=16000<br /> [61110.467639] ------------[ cut here ]------------<br /> [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx]<br /> [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160<br /> [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1<br /> [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023<br /> [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160<br /> [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 &amp;lt;0f&amp;gt; 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89<br /> [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282<br /> [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027<br /> [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0<br /> [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7<br /> [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000<br /> [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000<br /> [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0<br /> [61110.467736] PKRU: 55555554<br /> [61110.467737] Call Trace:<br /> [61110.467738] <br /> [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx]<br /> [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280<br /> <br /> Liberar sp en la ruta de error para corregir el fallo.

Se descubrió que el firmware v1.5.0-140603 del router UTT HiPER 810 / nv810v4 contenía credenciales predeterminadas inseguras para el servicio telnet, lo que posiblemente permitía a un atacante remoto obtener acceso de root mediante un script manipulado.