Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrección del puntero de lectura después de la liberación en ath12k_mac_assign_vif_to_vdev() En ath12k_mac_assign_vif_to_vdev(), si se crea arvif en una radio diferente, se elimina de esa radio mediante una llamada a ath12k_mac_unassign_link_vif(). Esta acción libera el puntero arvif. Posteriormente, hay una comprobación que involucra arvif, lo que dará como resultado un escenario de lectura después de la liberación. Corrija esto moviendo esta comprobación después de que arvif se asigne nuevamente mediante una llamada a ath12k_mac_assign_link_vif(). Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hid-thrustmaster: Se corrige la advertencia en thrustmaster_probe agregando una comprobación de endpoint. syzbot ha encontrado una discrepancia de tipo entre una tubería USB y el endpoint de transferencia, que se activa mediante el controlador hid-thrustmaster[1]. Hay una serie de problemas similares que ya se han solucionado [2]. En este caso, como en otros, implementar la comprobación del tipo de endpoint soluciona el problema. [1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: sch_sfq: no permitir límite de 1 paquete La implementación actual no funciona correctamente con un límite de 1. iproute2 en realidad verifica esto y este parche también agrega la verificación en el kernel. Esto corrige el siguiente fallo informado por syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. En este punto, asumiendo que no hay más paquetes en cola, cuando sch_dequeue se ejecute nuevamente, disminuirá el qlen para la ranura vacía actual, lo que provocará un desbordamiento y el posterior acceso fuera de límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wcn36xx: se corrige el tamaño de asignación de memoria de la encuesta de canal KASAN informó un problema de asignación de memoria en wcn->chan_survey debido a un cálculo de tamaño incorrecto. Esta confirmación utiliza kcalloc para asignar memoria para wcn->chan_survey, lo que garantiza una inicialización adecuada y evita el uso de valores no inicializados cuando no hay marcos en el canal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: OPP: agregar comprobación de índice a assert para evitar el desbordamiento de búfer en _read_freq() Pasar el índice freq a la función assert para asegurarnos de que no leemos un freq de la tabla opp->rates[] cuando se llama desde las variantes indexadas: dev_pm_opp_find_freq_exact_indexed() o dev_pm_opp_find_freq_ceil/floor_indexed(). Agregar un parámetro secundario a la función assert, no utilizado para assert_single_clk() y luego agregar assert_clk_index() que verificará el índice del reloj cuando se llame desde las funciones de búsqueda _indexed().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple() Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage. syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1] As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH. Rename helpers to better reflect they are safe against BH only. - ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh() [1] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: verificación de NULL en btrtl_setup_realtek() Si se inserta un dispositivo USB cuyo chip no se mantiene en ic_id_table, se alcanzará el punto NULL al que se accedió. Agregue una verificación de punto nulo para evitar el error de kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btbcm: Se ha corregido la desreferencia NULL en btbcm_get_board_name(). devm_kstrdup() puede devolver un puntero NULL en caso de error, pero este valor devuelto en btbcm_get_board_name() no se comprueba. Se ha añadido la comprobación NULL en btbcm_get_board_name() para controlar el error de desreferencia de puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: se corrige la comprobación de deref NULL en mt7925_change_vif_links. En mt7925_change_vif_links(), devm_kzalloc() puede devolver NULL, pero este valor devuelto no se comprueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: core: Fix posture that Resolution Multipliers must be in Logical Collections Se descubrió que un informe de 2019 del fuzzer syzbot estaba relacionado con dos errores en el núcleo de HID asociados con Resolution Multipliers. Uno de los errores se solucionó con el commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multipler."), pero el otro no se solucionó. Este error surge porque hid_apply_multipler() asume que cada control Resolution Multiplier está contenido en una colección lógica, es decir, no hay forma de que la rutina pueda establecer multiplier_collection en NULL. Esto es a pesar del hecho de que la función comienza con un gran comentario que dice: * "El control Multiplicador de resolución debe estar contenido en la misma * Colección lógica que el control o los controles a los que se aplicará. ... * Si no se define ninguna Colección lógica, el Multiplicador de resolución se asocia con todos los * controles del informe". * Tabla de uso de HID, v1.12, Sección 4.3.1, p30 * * Por lo tanto, busque desde la colección actual hacia arriba hasta que encontremos una * colección lógica... El comentario y el código pasan por alto la posibilidad de que ninguna de las colecciones encontradas pueda ser una Colección lógica. La solución es establecer el puntero multiplier_collection en NULL si la colección encontrada no es una Colección lógica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: th1520: Se corrige la corrupción de memoria debido a un tamaño de matriz incorrecto Las funciones th1520_mbox_suspend_noirq y th1520_mbox_resume_noirq tienen como objetivo guardar y restaurar los registros de máscara de interrupción en MBOX ICU0. Sin embargo, la matriz utilizada para almacenar estos registros tenía un tamaño incorrecto, lo que provocaba una corrupción de memoria al acceder a los cuatro registros. Esta confirmación corrige el tamaño de la matriz para acomodar los cuatro registros de máscara de interrupción, lo que evita la corrupción de memoria durante las operaciones de suspensión y reanudación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: dw: Arregla el use after free en el controlador dw_i3c_master debido a una condición de ejecución En dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work. If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dw_i3c_hj_work dw_i3c_common_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Solucione el problema asegurándose de que el trabajo se cancele antes de continuar con la depuración en dw_i3c_common_remove.