Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hidraw: corrige pérdida de memoria en hidraw_release() Libera los informes almacenados en búfer antes de eliminar la entrada de la lista. ERROR: Fuga de memoria, objeto no referenciado 0xffff88810e72f180 (tamaño 32): comm "softirq", pid 0, jiffies 4294945143 (edad 16.080s) volcado hexadecimal (primeros 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Corrección de lectura de Use-After-Free en usb_udc_uevent() El analizador de vulnerabilidades syzbot encontró una ejecución entre las devoluciones de llamadas de uevent y la anulación del registro del controlador del gadget que puede causar un error de Use-After-Free: --------------------------------------------------------------- ERROR: KASAN: Use-After-Free en usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Lectura de tamaño 8 en la dirección ffff888078ce2050 por la tarea udevd/2968 CPU: 1 PID: 2968 Comm: udevd No contaminado 5.19.0-rc4-next-20220628-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/06/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424 --------------------------------------------------------------- El error ocurre porque usb_udc_uevent() desreferencia udc->driver pero lo hace sin adquirir el Mutex udc_lock, que protege este campo. Si el controlador del gadget se desvincula del udc simultáneamente con el procesamiento de uevent, se puede acceder a la estructura del controlador después de su desasignación. Para evitar la competencia, nos aseguramos de que la rutina mantenga el mutex en los accesos de competencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: fb_pm2fb: Evitar posible error de división por cero En `do_fb_ioctl()` de fbmem.c, si cmd es FBIOPUT_VSCREENINFO, var se copiará del usuario, luego pasará por `fb_set_var()` e `info->fbops->fb_check_var()` que podrían ser `pm2fb_check_var()`. A lo largo de la ruta, `var->pixclock` no se modificará. Esta función verifica si el recíproco de `var->pixclock` es demasiado alto. Si `var->pixclock` es cero, habrá un error de división por cero. Por lo tanto, es necesario verificar si el denominador es cero para evitar un bloqueo. Como Syzkaller encontró este error, los registros se enumeran a continuación. Error de división en el seguimiento de llamadas pm2fb_check_var: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige la desreferencia del puntero NULL en is_ftrace_trampoline cuando ftrace está inactivo ftrace_startup no elimina las operaciones de ftrace_ops_list cuando ftrace_startup_enable falla: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // si ftrace no se modificó, ftrace_disabled se establece en 1 ... return 0 // las operaciones están en ftrace_ops_list. Cuando ftrace_disabled = 1, unregister_ftrace_function simplemente regresa sin hacer nada: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // regresa aquí, __unregister_ftrace_function no se ejecuta, // como resultado, ops todavía está en ftrace_ops_list __unregister_ftrace_function ... Si ops se asigna dinámicamente, estará libre más tarde, en este caso, is_ftrace_trampoline accede al puntero NULL: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // ¡UPS! ¡op puede ser NULL! Syzkaller informa lo siguiente: [ 1203.506103] ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000010b [ 1203.508039] #PF: acceso de lectura del supervisor en modo kernel [ 1203.508798] #PF: error_code(0x0000) - página no presente [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Contaminado: GBW 5.10.0 #8 [1203.512324] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [1203.514644] Código: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 00000000000000000 RSI: 0000000000000008 RDI: 0000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 00000000000010b CR3: 0000000170e1e001 CR4: 000000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Por lo tanto, cuando ftrace_startup_enable falla, debemos revertir el proceso de registro y eliminar las operaciones de ftrace_ops_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige error de recuento de referencias en sk_psock_get (2) Syzkaller informa el siguiente error de recuento de referencias: ------------[ cortar aquí ]------------ refcount_t: saturado; pérdida de memoria. ADVERTENCIA: CPU: 1 PID: 3605 en lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Módulos vinculados: CPU: 1 PID: 3605 Comm: syz-executor208 No contaminado 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [en línea] __refcount_inc_not_zero include/linux/refcount.h:227 [en línea] refcount_inc_not_zero include/linux/refcount.h:245 [en línea] sk_psock_get+0x3bc/0x410 incluir/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv incluir/net/sock.h:1061 [en línea] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [en línea] __sys_shutdown_sock net/socket.c:2325 [en línea] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [en línea] __se_sys_shutdown net/socket.c:2349 [en línea] Durante el proceso de respaldo de SMC en la llamada al sistema de conexión, el kernel reemplaza TCP con SMC. Para reenviar la cola de espera del socket SMC de activación después del respaldo, el kernel establece clcsk->sk_user_data en el socket SMC de origen en smc_fback_replace_callbacks(). Posteriormente, en la llamada al sistema de apagado, el kernel llamará a sk_psock_get(), que trata clcsk->sk_user_data como de tipo psock, lo que activa la advertencia refcnt. Por lo tanto, la causa principal es que tanto smc como psock utilizan el campo sk_user_data, por lo que es fácil que no coincidan con este campo. Este parche soluciona este problema utilizando otro bit (definido como SK_USER_DATA_PSOCK) en PTRMASK para indicar si sk_user_data apunta a un objeto psock. Este parche depende de una PTRMASK introducida en el commit f1ff5ce2cd5e ("net, sk_msg: Borrar el puntero sk_user_data al clonar si está etiquetado"). Dado que posiblemente haya más indicadores en el campo sk_user_data, este parche también refactoriza el código de indicadores sk_user_data para que sea más genérico y mejore su mantenimiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ieee802154/adf7242: aplazar la llamada a destroy_workqueue Existe una posible condición de ejecución (use-after-free) como la siguiente (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | La causa raíz de esta ejecución es que la capa superior (ieee802154) desconoce este evento de desconexión y la función adf7242_channel se puede llamar sin ninguna comprobación. Para solucionar esto, podemos añadir una escritura de bandera al principio de adf7242_remove y añadir la comprobación de bandera en adf7242_channel. O podemos simplemente aplazar la operación destructiva como en el commit 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev"), que permite que ieee802154_unregister_hw() gestione la sincronización. Este parche utiliza la segunda opción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: eliminar el subdesbordamiento de OPC antes de desactivar el reloj ODM [Por qué] Tras desactivar el reloj ODM, el bit de subdesbordamiento de OPC se mantendrá allí y la eliminación no funcionará. Necesitamos eliminarlo antes de desactivar el reloj. [Cómo] Eliminarlo si se produce al desactivar el reloj.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Se corrige una posible fuga de memoria en gpu_metrics_table. La memoria se asigna para gpu_metrics_table en smu_v13_0_4_init_smc_tables(), pero no se libera en smu_v13_0_4_fini_smc_tables(). Esto puede causar fugas de memoria; corríjalo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: corrige paquetes dañados para XDP_SHARED_UMEM Corrige un problema en el modo XDP_SHARED_UMEM junto con el modo alineado donde los paquetes se corrompen para el segundo socket y cualquier socket posterior vinculado al mismo umem. En otras palabras, esto no afecta al primer socket vinculado al umem. El culpable de este error es que la inicialización de las direcciones DMA para las entradas del grupo de búferes xsk pre-rellenadas no se realizó para ningún socket excepto el primero vinculado al umem. Solo se rellenó la matriz lineal de direcciones DMA. Corrige esto rellenando las direcciones DMA en el grupo de búferes xsk para cada socket vinculado al mismo umem.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skmsg: Corrige la última comprobación sg incorrecta en sk_msg_recvmsg() Corrige una desreferencia de puntero NULL del kernel como se muestra a continuación: [224.462334] Seguimiento de llamadas: [224.462394] __tcp_bpf_recvmsg+0xd3/0x380 [224.462441] ? syscall_trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462660] do_syscall_64+0x5d/0x1d0 [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca En el commit 9974d37ea75f ("skmsg: Corregir la última comprobación de sg no válida en sk_msg_recvmsg()"), cambiamos la última comprobación de sg a sg_is_last(), pero en el caso de redirección de sockmap (sin stream_parser/stream_verdict/skb_verdict), no marcamos el final de la lista de dispersión. Verifique las funciones sk_msg_alloc, sk_msg_page_add y bpf_msg_push_data; ninguna marca el final de sg. Se espera que usen sg.end para la determinación del final. Por lo tanto, se añade aquí la determinación de '(i != msg_rx->sg.end)'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Nintendo: corrección de la desreferencia del puntero nulo del trabajador de rumble. Podemos desreferenciar un puntero nulo que intenta poner en cola trabajo a una cola de trabajo destruida. Si el dispositivo se desconecta, se llama a nintendo_hid_remove, lo que destruye la cola de rumble. Evite usar esa cola para aplazar el trabajo de rumble una vez que el estado del mando se establezca en JOYCON_CTLR_STATE_REMOVED. Esto elimina la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No redirigir paquetes con pkt_len no válidos. Syzbot encontró un problema [1]: fq_codel_drop() intenta descartar un flujo sin skbs, es decir, el flujo->head es nulo. La causa principal, como se indica en [2], es que bpf_prog_test_run_skb() ejecuta un programa bpf que redirige skbs vacíos. Por lo tanto, debemos determinar si la longitud del paquete modificado por el programa bpf u otros como bpf_prog_test es válida antes de reenviarlo directamente.