Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: mediatek: clk-mt7629: Agregar verificación para mtk_alloc_clk_data. Agregue la verificación para el valor de retorno de mtk_alloc_clk_data() para evitar la desreferencia al puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: hisi: corrige el use after free cuando falla el registro de pmu. Cuando no logramos registrar el pmu sin núcleo, es posible que no se haya asignado el contexto de pmu. El manejo del error llamará a cpuhp_state_remove_instance() para llamar a la devolución de llamada fuera de línea de uncore pmu, que migra el contexto de pmu. Dado que eso puede conducir a algún tipo de use after free. Utilice cpuhp_state_remove_instance_nocalls() en lugar de cpuhp_state_remove_instance() para que los notificadores no se ejecuten después de que el dispositivo PMU no haya podido registrarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: soluciona el problema de cobertura con desbordamiento de enteros involuntario 1. En lugar de multiplicar 2 variables de diferentes tipos. Cambie para asignar un valor a una variable y luego multiplique la otra variable. 2. Agregue una variable int para el cálculo del multiplicador en lugar de calcular diferentes tipos de multiplicadores con la variable dma_addr_t directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: rescate anticipado si el área AUX de la solicitud está fuera de los límites. Cuando perf-record con un área AUX grande, por ejemplo, 4 GB, falla con: #perf record -C 0 -m, 4G -e arm_spe_0// -- el sueño 1 no pudo mapear con 12 (no se puede asignar memoria) y revela una ADVERTENCIA con __alloc_pages(): ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 44 PID: 17573 en mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Rastreo de llamadas: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/ 0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' asignado por kcalloc() es una matriz de punteros que se utiliza para mantener páginas de seguimiento AUX. La página asignada para esta matriz es físicamente contigua (y virtualmente contigua) con un orden de 0..MAX_ORDER. Si el tamaño de la matriz de punteros cruza la limitación establecida por MAX_ORDER, se revela una ADVERTENCIA. Por lo tanto, salve pronto con -ENOMEM si el área AUX de la solicitud está fuera de los límites, por ejemplo: #perf record -C 0 -m ,4G -e arm_spe_0// -- el sueño 1 no pudo asignar mm con 12 (no se puede asignar memoria)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/ww_mutex/test: soluciona una posible corrupción de la cola de trabajo. En algunos casos, al ejecutar el código test-ww_mutex, veía un comportamiento extraño en el que a veces parecía que flush_workqueue regresaba antes que todos los subprocesos de trabajo. hemos terminado. A menudo, esto causaría fallas extrañas ya que los mutex se liberarían mientras se estaban usando. Al observar el código, hay un problema de duración, ya que el subproceso de control que genera el trabajo asigna las estructuras de "estrés de estructura" que se pasan a los subprocesos de la cola de trabajo. Luego, cuando los subprocesos de la cola de trabajo finalizan, liberan la estructura de tensión que se les pasó. Desafortunadamente, el nodo work_struct de la cola de trabajo está en la estructura de estrés. Lo que significa que work_struct se libera antes de que regrese el hilo de trabajo y mientras descarga_workqueue está esperando. Parece una mejor idea que el subproceso de control asigne y libere las estructuras de tensión, de modo que podamos estar seguros de no corromper la cola de trabajo al liberar la estructura prematuramente. Entonces, este parche reelabora la prueba para hacerlo, y con este cambio ya no veo los primeros retornos de Flush_workqueue.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija uaf en nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk y blk_cleanup_disk") limpia el disco mediante blk_cleanup_disk() y no configurará disk->private_data como NULL como antes. UAF puede activarse en nbd_open() si alguien intenta abrir el dispositivo nbd justo después de nbd_put() ya que nbd ha estado libre en nbd_dev_remove(). Solucione este problema implementando ->free_disk y datos privados gratuitos en él.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fbdev: imsttfb: corrige una fuga de recursos en la sonda. He reescrito el manejo de errores, pero el error es que si init_imstt() falla, debemos llamar a iounmap(par-> cmap_regs).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: no transmitir a otras CPU al iniciar un contador. Este comando: $ perf record -e ciclos:k -e instrucciones:k -c 10000 -m 64M dd if =/dev/zero of=/dev/null count=1000 da lugar a esta advertencia del kernel: [444.364395] ADVERTENCIA: CPU: 0 PID: 104 en kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [444.364515] Módulos vinculados en: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec No contaminado 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [ 444.364771] Nombre de hardware: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [444.364998] s1: ff60000002c54d98 a0: ff60000002a73940 a1: 0000000000000000 [444.365013] a2: 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029 ] a5 : 000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2: 0000000000000000 s3: ffffffffffffffff s4: ff60000002c54d98 [ 444.365060] s5: ffffffff81539610 s6: ffffffff80c20c48 s7: 0000000000000000 [444.365075] s8: 0000000000000000 s9: 0000000000000001 s10: 0000000000000001 [444.365090] s11: ffffffff80099394 t3: 0000000000000003 t4: 00000000eac0c6e6 [444.365104] t5: 0000000400000000 t6: ff60000002e010d0 [444.365120] estado: 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000003 [444.365226] [] smp_call_function_many_cond+0x42c/0x436 [444.365295] [] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [< ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [] _task_tick+0x78/0x8c [ 444.365368] [] scheduler_tick+0xe6/0x25e [ 444.365383] [] update_process_times+0x80/0x96 [ 444.365398] [] tick_sched_handle+0x26/0x52 [ 444.365410] [] [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [] hrtimer_interrupt+0xce/0x1da [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [] cpu_devid_irq+0x80/0x114 [ 444.365470] [] generic_handle_domain_irq+0x1c/ 0x2a [ 444.365483] [] riscv_intc_irq+0x2e/0x46 [ 444.365497] [] handle_riscv_irq+0x4a/0x74 [ 444.365521 [] do_irq+0x7c/0x7e [ 444.365796] ---[ final de seguimiento 0000000000000000 ]--- Esto se debe a que la solución en la confirmación 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support") era incorrecta ya que no hay necesidad de transmitir a otras CPU al iniciar un contador, eso solo es necesario en mmap cuando el Es posible que los contadores ya se hayan iniciado en otras CPU, así que simplemente elimine esta transmisión.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: synaptics-rmi4 - corrige el use after free en rmi_unregister_function(). El put_device() llama a rmi_release_function() que libera "fn", por lo que se elimina la referencia en la siguiente línea "fn-> num_of_irqs" es un uso después de ser gratuito. Mueva put_device() hasta el final para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: mux: Add check and kfree for kstrdup. Agregue check para el valor de retorno de kstrdup() y devuelva el error si falla para evitar la desreferencia al puntero NULL. Además, utilice kfree() en el manejo de errores posterior para evitar pérdidas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: corrige el valor uninit en virtio_transport_recv_pkt(). KMSAN informó el siguiente problema de acceso al valor uninit: ================ ===================================== ERROR: KMSAN: valor uninit en virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 Process_one_work workqueue.c:2630 [en línea] process_scheduled_works+ 0xff6/0x1e60 kernel/workqueue.c:2703 worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit se almacenó en la memoria en: virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [en línea] virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virt io_transport_common.c:1415 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 Process_one_work kernel/workqueue.c:2630 [en línea] Process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 trabajador_thread+0xeca/0x14d0 kernel/workqueue.c:2784 hilo +0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit se creó en: slab_post_alloc_hook+ 0x105/0xad0 mm/slab.h: 767 slab_alloc_node mm/slub.c: 3478 [inline] kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c: 3523 kmalloc_reserve+0x13c/0x4a0 net/skbuff. fd /0x770 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [en línea] virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [en línea] virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c: 58 virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [en línea] virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/v sock_loopback.c:120 proceso_one_work kernel/workqueue.c:2630 [en línea] Process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 trabajador_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/ Process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 CPU: 1 PID: 10664 Comm: kworker/1:5 No contaminado 6.6.0-rc3-00146-g9f3ebbef746f #3 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 01/04/2014 Cola de trabajo: vsock-loopback vsock_loopback_work ===================== ================================= El siguiente reproductor simple puede causar el problema descrito anteriormente: int main(void) { calcetín interno; struct sockaddr_vm addr = { .svm_family = AF_VSOCK, .svm_cid = VMADDR_CID_ANY, .svm_port = 1234, }; sock = socket(AF_VSOCK, SOCK_STREAM, 0); connect(socket, (struct sockaddr *)&addr, sizeof(addr)); return 0; } Este problema ocurre porque los campos `buf_alloc` y `fwd_cnt` de `struct virtio_vsock_hdr` no se inicializan cuando se asigna un nuevo skb en `virtio_transport_init_hdr()`. Este parche resuelve el problema inicializando estos campos durante la asignación.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: llc: verificar mac len antes de leer el encabezado de mac. LLC lee el encabezado de mac con eth_hdr sin verificar que el skb tenga un encabezado de Ethernet. Syzbot pudo ingresar llc_rcv en un dispositivo tun. Tun puede insertar paquetes sin mac len y con el protocolo skb-> configurable por el usuario (pasando un encabezado tun_pi cuando no se configura IFF_NO_PI). ERROR: KMSAN: valor uninit en llc_station_ac_send_test_r net/llc/llc_station.c:81 [en línea] BUG: KMSAN: valor uninit en llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station. c:81 [en línea] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 __netif_receive_skb+ 0x1a6 /0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c :1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002 Agregue una prueba mac_len antes de las tres llamadas eth_hdr(skb) en net/llc. Hay más usos en include/net/llc_pdu.h. Todos estos están protegidos por un protocolo de prueba skb->== ETH_P_802_2. Lo cual no protege contra este escenario tun. Pero la prueba mac_len agregada en este parche en llc_fixup_skb también los protegerá indirectamente. Esto se llama desde llc_rcv antes que cualquier otro código LLC. Es tentador simplemente agregar una verificación general de mac_len en llc_rcv, pero no estoy seguro de si eso podría interrumpir las rutas LLC válidas que no asumen un encabezado Ethernet. En principio, 802.2 LLC se puede utilizar además de protocolos que no sean 802.3. La confirmación a la que se hace referencia a continuación muestra que solía hacerlo, además de Token Ring. Al menos uno de los tres usos de eth_hdr se remonta a antes del inicio del historial de git. Pero el que ejercita syzbot se introduce en este compromiso. Ese compromiso es lo suficientemente antiguo (2008), por lo que efectivamente todos los núcleos estables deberían recibirlo.