Vulnerabilidades

Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro iptv.stb.port en la función setIptvInfo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: corrigió el desplazamiento fuera de los límites en dbDiscardAG Al buscar el siguiente bloque log2 más pequeño, BLKSTOL2() devolvió 0, lo que provocó que el exponente de desplazamiento -1 fuera negativo. Este parche soluciona el problema saliendo del bucle directamente cuando se encuentra un cambio negativo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: agrega check_func_arg_reg_off() faltante para evitar accesos a memoria fuera de los límites. Actualmente, es posible pasar un CONST_PTR_TO_DYNPTR modificado a una función global como argumento. Los efectos adversos de esto es que los asistentes de BPF pueden continuar haciendo uso de este CONST_PTR_TO_DYNPTR modificado desde dentro del contexto de la función global, lo que puede resultar involuntariamente en accesos a la memoria fuera de los límites y, por lo tanto, comprometer la estabilidad general del sistema, es decir, [244.157771] ERROR : KASAN: losa fuera de los límites en bpf_dynptr_data+0x137/0x140 [244.161345] Lectura de tamaño 8 en la dirección ffff88810914be68 por tarea test_progs/302 [244.167151] CPU: 0 PID: 302 Comm: test_progs Contaminado: GOE 6.10.0- rc3-00131-g66b586715063 #533 [244.174318] Seguimiento de llamadas: [244.175787] [244.177356] dump_stack_lvl+0x66/0xa0 [244.179531] print_report+0xce/0x670 [244. 182314] ? __virt_addr_valid+0x200/0x3e0 [ 244.184908] kasan_report+0xd7/0x110 [ 244.187408] ? bpf_dynptr_data+0x137/0x140 [244.189714]? bpf_dynptr_data+0x137/0x140 [ 244.192020] bpf_dynptr_data+0x137/0x140 [ 244.194264] bpf_prog_b02a02fdd2bdc5fa_global_call_bpf_dynptr_data+0x22/0x26 [ 244. 198044] bpf_prog_b0fe7b9d7dc3abde_callback_adjust_bpf_dynptr_reg_off+0x1f/0x23 [ 244.202136] bpf_user_ringbuf_drain+0x2c7/0x570 [ 244.204744] ? 0xffffffffc0009e58 [244.206593]? __pfx_bpf_user_ringbuf_drain+0x10/0x10 [ 244.209795] bpf_prog_33ab33f6a804ba2d_user_ringbuf_callback_const_ptr_to_dynptr_reg_off+0x47/0x4b [ 244.215922] 2502480+0x43/0xe3 [ 244.218691] __x64_sys_prlimit64+0x9/0xf0 [ 244.220912] do_syscall_64+0xc1/0x1d0 [ 244.223043] Entry_SYSCALL_64_after_hwframe+0x77/0x7f [244.226458] QEPD: 0033:0x7ffa3eb8f059 [ 244.228582] Código: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f 1d 0d 00 f7 d8 64 89 01 48 [ 244.241307] RSP: 002b:00007ffa3e9c6eb8 EFLAGS: 00000206 ORIG_RAX: 0000000012e [ 244.246474] RAX: ffffffffffffffda RBX: 00007ffa3e9c7cdc RCX: 00007ffa3eb8f059 [ 244.250478] RDX: 00007ffa3eb162b4 RSI: 0000000000000000 RDI: 00007ffa3e9c7fb0 [ 244.255396] RBP: 00007ffa3e9c6ed0 R08: 00007ffa3e9c76c0 R 09: 0000000000000000 [ 244.260195] R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffff80 [ 244.264201] R13: 000000000000001c R 14: 00007ffc5d6b4260 R15: 00007ffa3e1c7000 [ 244.268303 ] Agregue un check_func_arg_reg_off() a la ruta en la que el verificador BPF verifica los argumentos de las funciones globales, específicamente aquellos que toman un argumento de tipo ARG_PTR_TO_DYNPTR | MEM_RDONLY. Además, Process_dynptr_func() no parece realizar ninguna coincidencia de tipos explícita y estricta en el tipo de registro proporcionado, por lo que también hagamos cumplir que un registro del tipo PTR_TO_STACK o CONST_PTR_TO_DYNPTR esté a cargo de la persona que llama.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme: apple: corrige el recuento de referencias del dispositivo Los controladores deben llamar a nvme_uninit_ctrl después de un nvme_init_ctrl exitoso. Divida el lado de la asignación para que sea más fácil navegar por el límite de manejo de errores. El controlador de Apple había estado haciendo esto mal, perdiendo la memoria del dispositivo controlador debido a una falla en el conjunto de etiquetas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: idpf: corrige UAF al destruir las colas. La segunda confirmación etiquetada comenzaba a veces (muy raramente, pero posible) arrojando ADVERTENCIAS desde net/core/page_pool.c:page_pool_disable_direct_recycling(). Resultó que idpf libera los vectores de interrupción con NAPI incorporadas *antes* de liberar las colas, lo que hace que los punteros NAPI de page_pools conduzcan a la memoria liberada antes de que Libeth destruya estos grupos. No está claro si hay otros accesos a los vectores liberados al destruir las colas, pero de todos modos, generalmente liberamos vectores de cola/interrupción solo cuando las colas se destruyen y se garantiza que no se hará referencia a las NAPI en ninguna parte. Invierta la lógica de asignación y liberación haciendo que los vectores de cola/interrupción se asignen primero y se liberen al final. Los vectores no requieren la presencia de colas, por lo que esto es seguro. Además, este cambio permite eliminar esa cola inútil->limpieza del puntero q_vector, ya que los vectores siguen siendo válidos al liberar las colas (+ ambos se liberan dentro de una función, por lo que no está claro por qué anular los punteros).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la memoria fuera de los límites en bnxt_fill_hw_rss_tbl() Una confirmación reciente modificó el código en __bnxt_reserve_rings() para configurar la tabla de direccionamiento indirecto RSS predeterminada solo cuando el número de Los anillos RX están cambiando. Si bien esto funciona para firmware más nuevo que requiere reservas de anillo RX, provoca la regresión en firmware más antiguo que no requiere reservas de anillo RX (BNXT_NEW_RM() devuelve falso). Con firmware anterior, no se requieren reservas de anillo RX y, por lo tanto, hw_resc->resv_rx_rings no siempre está configurado en el valor adecuado. La comparación: if (old_rx_rings != bp->hw_resc.resv_rx_rings) en __bnxt_reserve_rings() puede ser falso incluso cuando los anillos RX están cambiando. Esto hará que __bnxt_reserve_rings() omita la configuración de la tabla de direccionamiento indirecto RSS predeterminada para que coincida con el número actual de anillos RX. Posteriormente, esto puede provocar que bnxt_fill_hw_rss_tbl() utilice un índice fuera de rango. Ya tenemos bnxt_check_rss_tbl_no_rmgr() para manejar exactamente este escenario. Solo necesitamos moverlo hacia arriba en bnxt_need_reserve_rings() para que se llame incondicionalmente cuando usemos firmware anterior. Sin la solución, si los anillos TX están cambiando, omitiremos la llamada a bnxt_check_rss_tbl_no_rmgr() y __bnxt_reserve_rings() también puede omitir la llamada a bnxt_set_dflt_rss_indir_tbl() por el motivo explicado en el último párrafo. Sin configurar la tabla de direccionamiento indirecto RSS predeterminada, se produce la regresión: ERROR: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40 Lectura de tamaño 2 en la dirección ffff8881c5809618 mediante la tarea ethtool/31525 Call Trace: __bnxt_hwrm_vnic_set_rss+0 xb79 /0xe40 bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460 __bnxt_setup_vnic_p5+0x12e/0x270 __bnxt_open_nic+0x2262/0x2f30 bnxt_open_nic+0x5d/0xf0 ethnl_set_channels+0x5d4/0 xb30 ethnl_default_set_doit+0x2f1/0x620

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: power: Supply: rt5033: traer de vuelta i2c_set_clientdata Commit 3a93da231c12 ("power: Supply: rt5033: Use devm_power_supply_register() helper") reelaboró el controlador para usar devm. Mientras lo hacía, i2c_set_clientdata se eliminó junto con la devolución de llamada de eliminación. Desafortunadamente, otras partes del controlador también dependen de los datos del cliente i2c, por lo que esto provoca fallos en el kernel. Devuelva la llamada para reparar el controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/x86: intel-vbtn: protege el controlador de notificación ACPI contra la recursividad desde el commit e2ffcda16290 ("ACPI: OSL: permitir que los controladores Notify () se ejecuten en todas las CPU") Controladores de notificación ACPI como intel-vbtn notify_handler() puede ejecutarse en múltiples núcleos de CPU que compiten entre sí. Esta ejecución se ve afectada en las tabletas Dell Venue 7140 al desacoplarlas del teclado, lo que hace que el controlador intente registrar priv->switches_dev dos veces, como se puede ver en el mensaje dev_info() que se registra dos veces: [83.861800] intel-vbtn INT33D6: 00: Registro de conmutadores virtuales Intel input-dev después de recibir un evento de conmutador [ 83.861858] entrada: Conmutadores virtuales Intel como /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17 [ 83.861865] intel-vbtn INT33D6:00: Registro de conmutadores virtuales Intel input-dev después de recibir un evento de cambio Después del cual las cosas van muy mal: [83.861872] sysfs: no se puede crear un nombre de archivo duplicado '/devices/pci0000:00/0000:00:1f .0/PNP0C09:00/INT33D6:00/input/input17' ... [83.861967] kobject: kobject_add_internal falló para input17 con -EEXIST, no intente registrar cosas con el mismo nombre en el mismo directorio. [83.877338] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000018... Proteja intel-vbtn notify_handler() para que no corra consigo mismo con un mutex para solucionar este problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu/pm: corrija la desreferencia del puntero nulo en apply_state_adjust_rules Verifique el valor del puntero para corregir una posible desreferencia del puntero nulo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la desreferencia del puntero nulo a ras_manager. Verifique ras_manager antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/pm: corrige la desreferencia del puntero nulo para smu7, optimiza el código para evitar pasar un puntero nulo (hwmgr->backend) para que funcione smu7_update_edc_leakage_table.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la desreferencia NULL al comprobar la banda al iniciar la sesión tx ba En la conexión MLD, link_data/link_conf se asignan dinámicamente. No apuntan a vif->bss_conf. Entonces, no habrá ningún chanreq asignado a vif->bss_conf y luego el chan será NULL. Modifique el código para verificar ht_supported/vht_supported/has_he/has_eht en sta deflink. Registro de fallos (con la versión rtw89 bajo desarrollo MLO): [9890.526087] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 [9890.526102] #PF: acceso de lectura del supervisor en modo kernel [9890.526105] #PF: error_code(0x0000) - no presente página [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Ups: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: cargado Contaminado: G OE 6.9.0 #1 [ 0010: ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminador 1)) mac80211 [ 9890.526279] Código: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 Todo el código ======== 0: f7 e8 imul %eax 2: d5 (malo) 3: 93 xchg %eax,%ebx 4: 3e ea ds (malo) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b : 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,( %rax) <-- instrucción de captura 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c : 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Código que comienza con la instrucción errónea ======================== ==================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 prueba %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP : 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 00000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] X: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 00000000000000000 R09: 0000000000000873 [ 9 890.526304] R10: ffff9308e0d64800 R11 : 000000000000000002 R12: FFFF9308E5FF6E70 [9890.526308] R13: FFFF930952500E20 R14: FFFF9309192A8C00 R15: 000000000000000000 [9890.526313] 4E700000 (0000) KNLGS: 000000000000000000 [9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 00000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Seguimiento de llamadas: [ 9890.526324] [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [9890.526335]? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [9890.526347]? search_module_extables (kernel/module/main.c:3256 (discriminador ---truncado---