Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar el use after free en ip6_fragment(). el commit culpable afirmaba que rcu_read_lock() estaba retenido por los llamadores de ip6_fragment(). Parece que no siempre es cierto, al menos para la pila UDP. syzbot informó: ERROR: KASAN: use after free en ip6_dst_idev include/net/ip6_fib.h:245 [en línea] ERROR: KASAN: use after free en ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Lectura de tamaño 8 en la dirección ffff88801d403e80 por la tarea syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 No contaminado 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 imprimir_descripción_de_dirección mm/kasan/report.c:284 [en línea] imprimir_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [en línea] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [en línea] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND incluir/linux/netfilter.h:291 [en línea] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output incluir/net/dst.h:445 [en línea] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 Asignado por la tarea 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [en línea] gancho_alloc_poste_losa mm/slab.h:737 [en línea] nodo_alloc_losa mm/slub.c:3398 [en línea] losa_alloc mm/slub.c:3406 [en línea] __kmem_cache_alloc_lru mm/slub.c:3413 [en línea] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [en línea] rt6_make_pcpu_route net/ipv6/route.c:1417 [en línea] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [en línea] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 banderas de salida de ruta ip6+0x76/0x320 red/ipv6/route.c:2638 salida de ruta ip6 incluir/red/ip6_route.h:98 [en línea] cola de búsqueda de dst ip6+0x5ab/0x1620 red/ipv6/ip6_output.c:1092 flujo de búsqueda de dst ip6+0x90/0x1d0 red/ipv6/ip6_output.c:1222 flujo de búsqueda de dst ip6_sk+0x553/0x980 red/ipv6/ip6_output.c:1260 envío de mensajes de envío udpv6+0x151d/0x2c80 red/ipv6/udp.c:1554 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm/ident_map: Utilizar gbpages solo cuando se deba mapear una página GB completa. Cuando ident_pud_init() utiliza solo páginas GB para crear mapas de identidad, se pueden incluir en la tabla resultante grandes rangos de direcciones que no se solicitaron realmente; una solicitud de 4K mapeará un GB completo. Esto puede incluir una gran cantidad de espacio de direcciones adicional más allá del solicitado, incluidas las áreas marcadas como reservadas por el BIOS. Eso permite la especulación del procesador en regiones reservadas, que en sistemas UV puede causar paradas del sistema. Utilice solo páginas GB cuando las solicitudes de creación de mapas incluyan la página GB completa de espacio. Vuelva a utilizar páginas más pequeñas de 2M cuando solo se incluyan partes de una página GB en la solicitud. No se intenta fusionar las solicitudes de mapeo. Si una solicitud requiere una entrada de mapa en el nivel 2M (pmd), las solicitudes de mapeo posteriores dentro de la misma región 1G también estarán en el nivel pmd, incluso si dichas solicitudes adyacentes o superpuestas podrían haberse combinado para mapear una página GB completa. El uso actual comienza con regiones más grandes y luego agrega regiones más pequeñas, por lo que esto no debería tener grandes consecuencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: napi: Prevenir el desbordamiento de napi_defer_hard_irqs En el commit 6f8b12d661d0 ("net: napi: agregar característica de aplazamiento de irqs duras") se agregó napi_defer_irqs a net_device y napi_defer_irqs_count a napi_struct, ambos como tipo int. Este valor nunca baja de cero, por lo que no hay razón para que sea un int con signo. Cambie el tipo para ambos de int a u32 y agregue una comprobación de desbordamiento a sysfs para limitar el valor a S32_MAX. El límite de S32_MAX se eligió porque el límite práctico antes de este parche era S32_MAX (cualquier valor mayor era un desbordamiento) y, por lo tanto, no se introdujeron cambios de comportamiento. Si se necesita el bit adicional en el futuro, se puede aumentar el límite. Antes de este parche: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' $ cat /sys/class/net/eth4/napi_defer_hard_irqs -2147483647 Después de este parche: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' bash: línea 0: echo: error de escritura: resultado numérico fuera de rango De manera similar, /sys/class/net/XXXXX/tx_queue_len se define como unsigned: include/linux/netdevice.h: unsigned int tx_queue_len; Y tiene una comprobación de desbordamiento: dev_change_tx_queue_len(..., unsigned long new_len): if (new_len != (unsigned int)new_len) return -ERANGE;

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: actualización de la política DML2 EnhancedPrefetchScheduleAccelerationFinal DCN35 [POR QUÉ Y CÓMO] La falta de coincidencia en DCN35 DML2 hace que la validación de bw no pueda adquirir una tubería DPP inesperada, lo que provoca una pantalla gris y un bloqueo del sistema. Eliminar la anulación del valor EnhancedPrefetchScheduleAccelerationFinal para que coincida con la especificación de hardware. (seleccionado de el commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: Se soluciona un posible problema de desreferencia de RCU en mac802154_scan_worker En la función `mac802154_scan_worker`, se accedió al campo `scan_req->type` después de que se desbloqueara la sección crítica del lado de lectura de RCU. Según las reglas de uso de RCU, esto es ilegal y puede provocar un comportamiento impredecible, como acceder a la memoria que se ha actualizado o causar problemas de use after free. Este posible error se identificó utilizando una herramienta de análisis estático desarrollada por mí, diseñada específicamente para detectar problemas relacionados con RCU. Para solucionar esto, el valor `scan_req->type` ahora se almacena en una variable local `scan_req_type` mientras aún está dentro de la sección crítica del lado de lectura de RCU. Luego, `scan_req_type` se usa después de que se libera el bloqueo de RCU, lo que garantiza que se acceda al valor de tipo de manera segura sin violar las reglas de RCU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: amd-pstate: agregar comprobación para el valor de retorno de cpufreq_cpu_get. cpufreq_cpu_get puede devolver NULL. Para evitar la desreferencia a NULL, compruébelo y devuélvalo en caso de error. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: soc-acpi-intel-rpl-match: agregar elemento vacío faltante No hay links_num en struct snd_soc_acpi_mach {}, y probamos !link->num_adr como condición para finalizar el bucle en hda_sdw_machine_select(). Por lo tanto, se requiere un elemento vacío en la matriz struct snd_soc_acpi_link_adr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evitar asignación de desbordamiento en link_dp_cts sampling_rate es un uint8_t pero se le asigna un int sin signo y, por lo tanto, puede desbordarse. Como resultado, sampling_rate se cambia a uint32_t. De manera similar, LINK_QUAL_PATTERN_SET tiene un tamaño de 2 bits y solo se debe asignar a un valor menor o igual a 4. Esto soluciona 2 problemas de INTEGER_OVERFLOW informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se soluciona el bloqueo del sistema durante la reanudación con el monitor TBT [Por qué] Conectado con un monitor Thunderbolt y realizando la suspensión, el sistema puede bloquearse durante la reanudación. El HPD del monitor TBT se activará durante el procedimiento de reanudación y llamará a drm_client_modeset_probe() mientras struct drm_connector connector->dev->master sea NULL. Esto arruinará la topología de la tubería después de la reanudación. [Cómo] Omitir el HPD del monitor TBT durante el procedimiento de reanudación porque actualmente sondearemos los conectores después de la reanudación de forma predeterminada. (seleccionado de el commit 453f86a26945207a16b8f66aaed5962dc2b95b85)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el orden de desbloqueo de i_data_sem en ext4_ind_migrate() Fuzzing informa un posible bloqueo en jbd2_log_wait_commit. Este problema se activa cuando se configura un ioctl EXT4_IOC_MIGRATE para requerir actualizaciones sincrónicas porque el descriptor de archivo se abre con O_SYNC. Esto puede provocar que la función jbd2_journal_stop() llame a jbd2_might_wait_for_commit(), lo que puede provocar un bloqueo si la llamada a EXT4_IOC_MIGRATE compite con una llamada del sistema write(2). Este problema solo surge cuando CONFIG_PROVE_LOCKING está habilitado. En este caso, la macro jbd2_might_wait_for_commit bloquea jbd2_handle en la función jbd2_journal_stop mientras i_data_sem está bloqueado. Esto activa lockdep porque la función jbd2_journal_start también podría bloquear el mismo jbd2_handle simultáneamente. Encontrado por Linux Verification Center (linuxtesting.org) con syzkaller. Regla: add

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: asihpi: Se corrige el posible acceso a la matriz OOB. El controlador ASIHPI almacena algunos valores en la matriz estática tras una respuesta del controlador, y su índice depende del firmware. No deberíamos confiar ciegamente en él. Este parche agrega una comprobación de la integridad del índice de la matriz para que se ajuste al tamaño de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: Se corrige la advertencia de escritura que abarca el campo memcpy() en mwifiex_cmd_802_11_scan_ext() Reemplazar la matriz de un elemento con un miembro de matriz flexible en `struct host_cmd_ds_802_11_scan_ext`. Con esto, se soluciona la siguiente advertencia: elo 16 17:51:58 kernel de surfacebook: ------------[ cortar aquí ]------------ elo 16 17:51:58 kernel de surfacebook: memcpy: se detectó escritura que abarca el campo (tamaño 243) de un solo campo "ext_scan->tlv_buffer" en drivers/net/wireless/marvell/mwifiex/scan.c:2239 (tamaño 1) elo 16 17:51:58 kernel de surfacebook: ADVERTENCIA: CPU: 0 PID: 498 en drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]