Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: inicializar mensaje de buzón para restablecer VF Cuando no se asigna una dirección MAC a la VF, esa parte del mensaje enviado a la VF no se configura. Sin embargo, la memoria se asigna desde la pila, lo que significa que la información puede filtrarse a la VM. Inicialice el búfer de mensajes a 0 para que no se pase información a la VM en este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Fix perf_pending_task() UaF Por syzbot es posible que perf_pending_task() se ejecute después de que el evento sea free(). Hay dos casos relacionados pero distintos: - el task_work ya estaba en cola antes de destruir el evento; - destruir el evento en sí mismo pone en cola el task_work. El primero no se puede resolver usando task_work_cancel() ya que perf_release() en sí mismo podría ser llamado desde un task_work (____fput), lo que significa que la lista current->task_works ya está vacía y task_work_cancel() no podrá encontrar la entrada perf_pending_task(). La alternativa más simple es extender la duración de perf_event para cubrir el task_work. El segundo es simplemente una tontería, poner en cola una tarea_trabajo mientras sabes que el evento va a desaparecer no tiene sentido y se evita fácilmente reorganizando cómo se marca el evento como STATE_DEAD y asegurándose de que pase por STATE_OFF en el camino hacia abajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Verificar límites para el segundo canal en snd_soc_put_volsw_sx() Las comprobaciones de los límites en snd_soc_put_volsw_sx() solo se aplican al primer canal, lo que significa que es posible escribir valores fuera de los límites en el segundo canal en controles estéreo. Agregue las comprobaciones adecuadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: mt7621: Agregar centinela a la tabla de peculiaridades Al controlador actual le falta un centinela en la matriz struct soc_device_attribute, lo que provoca un error cuando se evalúa mediante la llamada soc_device_match(mt7621_pcie_quirks_match). Esto solo se expuso una vez que se arregló CONFIG_SOC_MT7621 mt7621 soc_dev_attr para registrar el SOC como un dispositivo, en: commit 7c18b64bba3b ("mips: ralink: mt7621: no use kzalloc demasiado pronto") Arréglelo agregando el centinela requerido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: cmos: Fix event handler registration ordering issue Debido a que acpi_install_fixed_event_handler() habilita el evento automáticamente en caso de éxito, es incorrecto llamarlo antes de que la rutina del controlador que se le pasa esté lista para manejar eventos. Desafortunadamente, el controlador rtc-cmos hace exactamente lo incorrecto al llamar a cmos_wake_setup(), que pasa rtc_handler() a acpi_install_fixed_event_handler(), antes de cmos_do_probe(), porque rtc_handler() usa dev_get_drvdata() para llegar al puntero del objeto cmos y el puntero de datos del controlador solo se completa en cmos_do_probe(). Esto conduce a una desreferencia de puntero NULL en rtc_handler() en el arranque si el evento RTC fixed está activo en el momento de inicialización. Para solucionar este problema, cambie el orden de inicialización del controlador de modo que cmos_wake_setup() siempre se llame después de una llamada a cmos_do_probe() exitosa. Mientras tanto, cambie cmos_pnp_probe() para llamar a cmos_do_probe() después de la declaración if () inicial utilizada para calcular el argumento IRQ que se pasará a cmos_do_probe(), lo que es más limpio que llamarlo en cada rama de ese if () (la variable local "irq" puede ser de tipo int, porque se pasa a esa función como un argumento de tipo int). Tenga en cuenta que el commit 6492fed7d8c9 ("rtc: rtc-cmos: No marque ACPI_FADT_LOW_POWER_S0") provocó que este problema afectara a una mayor cantidad de sistemas, porque anteriormente solo afectaba a los sistemas con ACPI_FADT_LOW_POWER_S0 configurado, pero está presente independientemente de esa confirmación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: se corrige el use after free en hsci KASAN descubrió que addr fue desreferenciado después de que se liberó br2dev_event_work. ===================================================================== ERROR: KASAN: use after free en qeth_l2_br2dev_worker+0x5ba/0x6b0 Lectura de tamaño 1 en la dirección 00000000fdcea440 por la tarea kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Contaminado: GE 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Nombre del hardware: IBM 8561 T01 703 (LPAR) Cola de trabajo: 0.0.8000_evento qeth_l2_br2dev_worker Seguimiento de llamadas: [<000000016944d4ce>] nivel_pila_volcado+0xc6/0xf8 [<000000016942cd9c>] descripción_dirección_impresión.constprop.0+0x34/0x2a0 [<000000016942d118>] informe_impresión+0x110/0x1f8 [<0000000167a7bd04>] informe_kasan+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] proceso_uno_trabajo+0x76e/0x1128 [<00000001673ee85c>] subproceso_trabajador+0x184/0x1098 [<000000016740718a>] subproceso_k+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Asignado por la tarea 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 cadena_de_llamadas_de_notificador_atómico+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 llamada_sistema+0x82/0xb0 Liberado por la tarea 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Última creación de trabajo potencialmente relacionada: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 cadena de llamada de notificador atómico+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Penúltima creación de trabajo potencialmente relacionado: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 La dirección con errores pertenece al objeto en 00000000fdcea400 que pertenece a la caché kmalloc-96 de tamaño 96 La dirección con errores se encuentra 64 bytes dentro de la región de 96 bytes [00000000fdcea400, 00000000fdcea460) La dirección con errores pertenece a la página física: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: 00000000fdcea300: fb ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: thunderbolt: se corrige la pérdida de memoria en tbnet_open() Cuando tb_ring_alloc_rx() fallo en tbnet_open(), no se libera el ida asignado en tb_xdomain_alloc_out_hopid(). Agregue tb_xdomain_release_out_hopid() a la ruta de error para liberar el ida.

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.