Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921s: corrige una posible pérdida de memoria en mt7921_load_patch. Siempre libera datos de firmware al final de la rutina mt7921_load_patch.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: asix: agregar manejo de errores adecuado para errores de lectura de USB Syzbot una vez más alcanzó un valor uninit en el controlador asix. El problema sigue siendo el mismo: asix_read_cmd() lee menos bytes de los que solicitó el llamador. Dado que todas las solicitudes de lectura se realizan a través de asix_read_cmd(), detectemos el error relacionado con USB allí y agreguemos la notación __must_check para asegurarnos de que todos los llamadores realmente verifiquen el valor de retorno. Entonces, este parche agrega una verificación de cordura dentro de asix_read_cmd(), que simplemente verifica si los bytes leídos no son menores que los solicitados y agrega la gestión de errores faltantes de asix_read_cmd() en todo el código del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: evitar advertencia del kernel al cambiar los parámetros del anillo RX Llamar a ethtool cambiando los parámetros del anillo RX de esta manera: $ ethtool -G eth0 rx 1024 en igc activa advertencias del kernel como esta: [ 225.198467] ------------[ cortar aquí ]------------ [ 225.198473] Falta anulación del registro, controlador manejado pero corregido [ 225.198485] ADVERTENCIA: CPU: 7 PID: 959 en net/core/xdp.c:168 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Seguimiento de llamada: [ 225.198604] [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc] [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc] [ 225.198626] ethnl_set_rings+0x18a/0x250 [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110 [ 225.198637] genl_rcv_msg+0xce/0x1c0 [ 225.198640] ? rings_prepare_data+0x60/0x60 [ 225.198644] ? genl_get_cmd+0xd0/0xd0 [ 225.198647] netlink_rcv_skb+0x4e/0xf0 [ 225.198652] genl_rcv+0x24/0x40 [ 225.198655] netlink_unicast+0x20e/0x330 [ 225.198659] netlink_sendmsg+0x23f/0x480 [ 225.198663] sock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? do_user_addr_fault+0x1eb/0x690 [ 225.198680] __x64_sys_sendto+0x20/0x30 [ 225.198683] do_syscall_64+0x38/0x90 [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 225.198693] RIP: 0033:0x7f7ae38ac3aa igc_ethtool_set_ringparam() copia la estructura igc_ring pero no restablece el miembro xdp_rxq_info antes de llamar a igc_setup_rx_resources(). Esto, a su vez, llama a xdp_rxq_info_reg() con un xdp_rxq_info ya registrado. Asegúrese de anular el registro de la estructura xdp_rxq_info primero en igc_setup_rx_resources.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige un error de btf decl_tag al etiquetar una función syzbot informó un error de btf decl_tag con el siguiente seguimiento de pila: error de protección general, probablemente para una dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 No contaminado 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [en línea] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Seguimiento de llamadas: btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [en línea] btf_parse_type_sec kernel/bpf/btf.c:4280 [en línea] btf_parse kernel/bpf/btf.c:4513 [en línea] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [en línea] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4736 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae El error kasan se activa con un BTF ilegal como el siguiente: tipo 0: void tipo 1: int tipo 2: decl_tag a func tipo 3 tipo 3: func a func_proto tipo 8 El número total de tipos es 4 y el tipo 3 es ilegal ya que su tipo func_proto está fuera de rango. Actualmente, el tipo de destino de decl_tag puede ser struct/union, var o func. Tanto struct/union como var implementaron sus propias funciones de devolución de llamada 'resolve' y, por lo tanto, se manejan correctamente en el kernel. Pero el tipo func no tiene la función de devolución de llamada 'resolve'. Cuando btf_decl_tag_resolve() intenta verificar el tipo func, intenta obtener vlen de su tipo func_proto, lo que activó el error kasan anterior. Para solucionar el problema, btf_decl_tag_resolve() debe ejecutar btf_func_check() antes de intentar acceder al tipo func_proto. En la implementación actual, el tipo func se verifica con btf_func_check() en la función de verificación principal btf_check_all_types(). Para solucionar el problema de kasan anterior, implementemos la devolución de llamada 'resolve' para el tipo func de manera adecuada. La devolución de llamada 'resolve' también se llamará en btf_check_all_types() para los tipos func.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: anular el registro de los relojes virtuales al anular el registro del reloj físico. Al anular el registro de un reloj físico que tiene algunos relojes virtuales, anule el registro de los relojes virtuales con él. Esto corrige los siguientes errores, que pueden desencadenarse al descargar un controlador que proporciona un reloj PTP cuando ha habilitado los relojes virtuales: ERROR: no se puede manejar el fallo de página para la dirección: ffffffffc04fc4d8 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ptp_vclock_read+0x31/0xb0 Seguimiento de llamadas: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la pérdida de memoria en tcp_bpf_sendmsg mientras sk msg está lleno Si tcp_bpf_sendmsg() se está ejecutando mientras sk msg está lleno. Cuando sk_msg_alloc() devuelve el error -ENOMEM, tcp_bpf_sendmsg() va a wait_for_memory. Si sk_msg_alloc() ha asignado memoria parcial, es decir, msg_tx->sg.size es mayor que osize después de sk_msg_alloc(), se produce una pérdida de memoria. Para solucionarlo, utilizamos sk_msg_trim() para liberar la memoria asignada y luego vamos a esperar memoria. Otras rutas de llamada de sk_msg_alloc() tienen un problema similar, como tls_sw_sendmsg(), así que maneje la lógica de sk_msg_trim dentro de sk_msg_alloc(), como sugirió Cong Wang. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 3 PID: 7950 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 3 PID: 2094 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: pgalloc: reparar pérdida de memoria causada por pgd_free() La página pgd es liberada por la implementación genérica pgd_free() desde el commit f9cb654cb550 ("asm-generic: pgalloc: proporcionar pgd_free() genérico"), sin embargo, hay escenarios en los que el sistema usa más de una página como la tabla pgd, en tales casos la implementación genérica pgd_free() ya no será aplicable. Por ejemplo, cuando PAGE_SIZE_4KB está habilitado y MIPS_VA_BITS_48 no está habilitado en un sistema de 64 bits, la macro "PGD_ORDER" se establecerá como "1", lo que provocará la asignación de dos páginas como la tabla pgd. Bueno, al mismo tiempo, la implementación genérica pgd_free() solo libera una página pgd, lo que provocará la pérdida de memoria. La pérdida de memoria se puede detectar fácilmente ejecutando el comando de shell: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mips: cdmm: Se corrige la pérdida de recuento de referencias en mips_cdmm_phys_base La función of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando termine. Agregue el of_node_put() faltante para liberar el recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: atmel: soluciona el problema de recuento de referencias en atmel_nand_controller_init El problema de recuento de referencias ocurre en varias rutas de manejo de errores en un objeto con recuento de referencias "nc->dmac". En estas rutas, la función simplemente devuelve el código de error, olvidando equilibrar el recuento de referencias de "nc->dmac", aumentado anteriormente por dma_request_channel(), lo que puede causar fugas de recuento de referencias. Arréglelo disminuyendo el recuento de referencias de un objeto específico en esas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: Se ha corregido la gestión de errores en ath10k_setup_msa_resources El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta normal. Y provocará una fuga de refcount en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s: No usar DSISR para fallas SLB Desde el commit 46ddcb3950a2 ("powerpc/mm: Mostrar si un fallo de página incorrecta en los datos es de lectura o escritura") usamos page_fault_is_write(regs->dsisr) en __bad_page_fault() para determinar si el fallo es de lectura o escritura y cambiar el mensaje impreso en consecuencia. Pero las fallas SLB, también conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupción de almacenamiento de datos) en un valor útil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupción de segmento de datos establece DSISR "en un valor indefinido". Hasta donde puedo ver, tampoco se menciona que los fallos SLB establezcan DSISR en ningún contenido de BookIV. Esto se manifiesta como accesos que deberían ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando "dump" de xmon: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0x5deadbeef0000000 [359526.415611][ C6] Dirección de instrucción con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucción de carga: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) También podemos ver en exceptions-64s.S que el bloque data_access_slb no establece IDSISR=1, lo que significa que no carga DSISR en pt_regs. Por lo tanto, el valor que estamos usando para determinar si el error es de lectura/escritura es algún valor obsoleto en pt_regs de un error de página anterior. Reelabore la lógica de impresión para separar el caso de error de SLB y solo imprima lectura/escritura en los casos en los que podamos determinarlo. El resultado se parece a, por ejemplo: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Dirección de instrucción con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucción con error dirección: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corregir ejecución en el desmontaje del socket Corrige una ejecución en el código de desmontaje del socket xsk que puede provocar un splat de desreferencia de puntero NULL. El código de desvinculación xsk actual en xsk_unbind_dev() comienza estableciendo xs->state en XSK_UNBOUND, establece xs->dev en NULL y luego espera a que finalice cualquier procesamiento NAPI utilizandosynchronous_net(). Después de eso, el código de lanzamiento comienza a desmantelar el estado del socket y a liberar la memoria asignada. ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Contaminado: GI 5.16.0+ #2 Nombre del hardware: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 09/03/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 00000000000000000 RBX: 00000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Seguimiento de llamadas: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Hay dos problemas con el código actual. Primero, establecer xs->dev en NULL antes de esperar a que todos los usuarios dejen de usar el socket no es correcto. La entrada a las funciones del plano de datos xsk_poll(), xsk_sendmsg() y xsk_recvmsg() están todas protegidas por una prueba de que xs->state está en el estado XSK_BOUND y, si no, regresa de inmediato. Pero un proceso podría haber pasado esta prueba pero aún no haber llegado al punto en el que usa xs->dev en el código. Mientras tanto, un segundo proceso que ejecuta xsk_unbind_dev() podría haber establecido xs->dev en NULL, lo que provocará un bloqueo para el primer proceso. La solución aquí es simplemente deshacerse de esta asignación NULL ya que ya no se usa. Antes de el commit 42fddcc7c64b ("xsk: usar miembro de estado para sincronización de socket"), xs->dev era el guardián para admitir procesos en las funciones del plano de datos, pero fue reemplazado por la variable de estado xs->state en el commit mencionada anteriormente. El segundo problema es quesynchronous_net() no espera a que se complete ningún proceso en xsk_poll(), xsk_sendmsg() o xsk_recvmsg(), lo que significa que el estado en el que se basan podría limpiarse prematuramente. Esto puede suceder cuando se llama al notificador (por ejemplo, al descargar el controlador) ya que utiliza xsk_unbind_dev(). Resuelva esto extendiendo la región crítica de RCU desde solo ndo_xsk_wakeup a todas las funciones mencionadas anteriormente, de modo que tanto la prueba de xs->state == XSK_BOUND como el último uso de cualquier miembro de xs estén cubiertos por la sección crítica de RCU. Esto garantizará que cuando se completesynchronous_net(), no habrá procesos restantes ejecutando xsk_poll(), xsk_sendmsg() o xsk_recvmsg() y el estado se puede limpiar de forma segura. Tenga en cuenta que debemos eliminar el bloqueo de RCU para la ruta de transmisión de skb, ya que utiliza funciones que podrían estar inactivas. Debido a esto, tenemos que volver a probar xs->state después de obtener el mutex que protege el código xmit de skb de, entre varias cosas, un xsk_unbind_dev() que se ejecuta desde el notificador al mismo tiempo.