Vulnerabilidades

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---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: no permite configurar anchos de canal AP especiales. La configuración del ancho del canal AP está manipulada para usarse con la progresión normal de ancho de canal de 20/40/... MHz y alternar entre No se admiten S1G ni canales estrechos. No permitir eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: evite BUG_ON() mientras continúa la remodelación después del reensamblaje. Actualmente, mdadm admite --revert-reshape para cancelar la remodelación mientras se reensambla, como muestra la prueba 07revert-grow. Sin embargo, la prueba puede activar el siguiente BUG_ON(): kernel ERROR en drivers/md/raid5.c:6278! código de operación no válido: 0000 [#1] PREEMPT SMP PTI sello de evento irq: 158985 CPU: 6 PID: 891 Comm: md0_reshape No contaminado 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Seguimiento de llamadas: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 La causa principal es que --revert-resha pe actualizar los raid_disks de 5 a 4, mientras la posición de remodelación aún está establecida, y después de volver a ensamblar la matriz, la posición de remodelación se leerá desde el superbloque, luego, durante la remodelación, fallará la verificación de 'writepos' calculada por la posición de remodelación anterior. Primero solucione este pánico de la manera más fácil, convirtiendo BUG_ON() en WARN_ON() y detenga la remodelación si las comprobaciones fallan. Se señaló que mdadm también debe corregir --revert-shape, y probablemente md/raid también debería mejorar la validación de metadatos; sin embargo, esto significa que el reensamblaje fallará y debe haber herramientas de usuario para corregir los metadatos incorrectos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: evita posibles fugas de especulación en gpio_device_get_desc() El espacio de usuario puede desencadenar una lectura especulativa de una dirección fuera de la matriz de descriptores de gpio. Los usuarios pueden hacerlo llamando a gpio_ioctl() con un desplazamiento fuera de rango. La compensación se copia del usuario y luego se usa como índice de matriz para obtener el descriptor de gpio sin desinfección en gpio_device_get_desc(). Este cambio garantiza que la compensación se desinfecte mediante el uso de array_index_nospec() para mitigar cualquier posibilidad de fugas de información especulativa. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mcast: espere los ciclos de gc anteriores al eliminar el puerto syzbot alcanzó un use-after-free [1] que se debe a que el puente no se asegura de que todos Se ha recogido basura anterior al eliminar un puerto. Lo que sucede es: CPU 1 CPU 2 iniciar el ciclo de gc eliminar el puerto adquirir el bloqueo de gc primero esperar la llamada de bloqueo br_multicasg_gc() adquirir directamente el bloqueo ahora pero liberar el puerto el puerto se puede liberar mientras los temporizadores de grp aún se ejecutan Asegúrese de que todos los ciclos de gc anteriores hayan finalizado usando flush_work antes de liberar el puerto. [1] ERROR: KASAN: slab-use-after-free en br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Lectura de tamaño 8 en la dirección ffff888071d6d000 por tarea syz.5.1232/9699 CPU: 1 PID: 9699 Comm : syz.5.1232 No contaminado 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c :88 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm /kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [en línea] __run_timers +0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [en línea] __run_timer_base kernel/time/timer.c:2421 [en línea] run_timer_base+0x111/0x190 kernel/time/timer. c:2437