Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: soluciona problemas de pérdida de recuento de referencias de ax25_dev. Ax25_addr_ax25dev() y ax25_dev_device_down() existen un problema de pérdida de recuento de referencias del objeto "ax25_dev". Problema de pérdida de memoria en ax25_addr_ax25dev(): el recuento de referencias del objeto "ax25_dev" se puede aumentar varias veces en ax25_addr_ax25dev(). Esto provocará una pérdida de memoria. Problemas de pérdida de memoria en ax25_dev_device_down(): el recuento de referencias de ax25_dev se establece en 1 en ax25_dev_device_up() y luego aumenta el recuento de referencias cuando se agrega ax25_dev a ax25_dev_list. Como resultado, el recuento de referencia de ax25_dev es 2. Pero cuando el dispositivo se está apagando. El ax25_dev_device_down() reduce el recuento de referencias una o dos veces dependiendo de si vamos a unlock_put o no, lo que provocará una pérdida de memoria. En cuanto al problema de ax25_addr_ax25dev(), es imposible que un puntero esté en una lista dos veces. Entonces agregue una interrupción en ax25_addr_ax25dev(). En cuanto al problema de ax25_dev_device_down(), aumente el recuento de referencias de ax25_dev una vez en ax25_dev_device_up() y disminuya el recuento de referencias de ax25_dev después de que se elimine de ax25_dev_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/perf: hisi: hns3: en realidad usa devm_add_action_or_reset() pci_alloc_irq_vectors() asigna un vector irq. Cuando devm_add_action() falla, el vector irq no se libera, lo que provoca una pérdida de memoria. Reemplace devm_add_action con devm_add_action_or_reset para garantizar que el vector irq pueda destruirse cuando falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: refina la comprobación de EOF en blkdev_iomap_begin blkdev_iomap_begin redondea hacia abajo el desplazamiento al tamaño del bloque lógico antes de guardarlo en iomap->offset y comprobar que todavía está dentro del tamaño del inodo. Verifique la verificación i_size en el valor pos sin formato para que no intentemos una escritura de tamaño cero si iter->pos no está alineado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: núcleo: corrige la asignación del puntero del módulo NULL en el inicio de la tarjeta el commit 81033c6b584b ("ALSA: núcleo: Advertencia sobre módulo vacío") introdujo un WARN_ON() para un puntero de módulo NULL pasado en la creación del objeto snd_card, y también envuelve el código a su alrededor con '#ifdef MODULE'. Esto funciona en la mayoría de los casos, pero los problemas siempre están en los detalles. "MÓDULO" se define cuando el código objetivo (es decir, el núcleo de sonido) se construye como un módulo; pero esto no significa que la persona que llama también esté integrada o no. Es decir, cuando solo el núcleo de sonido está integrado (CONFIG_SND=y) mientras el controlador es un módulo (CONFIG_SND_USB_AUDIO=m), el puntero del módulo pasado se ignora incluso si no es NULL, y tarjeta->módulo permanece como NULL. Esto daría como resultado que la referencia del módulo faltante suba o baje en la apertura o cierre del dispositivo, lo que provocaría una ejecución con la ejecución del código después de la eliminación del módulo. Para solucionar el error, mueva la asignación de tarjeta->módulo nuevamente fuera de ifdef. WARN_ON() todavía está incluido en ifdef porque el módulo puede ser realmente NULL cuando todos los controladores de sonido están integrados. Tenga en cuenta que mantenemos 'ifdef MODULE' para WARN_ON(); de lo contrario, se produciría una verificación de módulo NULL falsamente positiva. Es cierto que no se detectará perfectamente, es decir, no se realiza ninguna verificación cuando CONFIG_SND=y. Pero no es un problema real ya que es solo para depurar y la condición es bastante rara.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat: valida el recuento de segmentos devueltos por el FW. La función adf_send_admin_tl_start() habilita la función de telemetría (TL) en un dispositivo QAT enviando el mensaje ICP_QAT_FW_TL_START al firmware. Esto hace que el FW comience a escribir datos TL en un búfer DMA en la memoria y devuelve una matriz que contiene la cantidad de aceleradores de cada tipo (porciones) admitidos por este HW. El puntero a esta matriz se almacena en la estructura de datos adf_tl_hw_data llamada slice_cnt. La matriz slice_cnt luego se usa en la función tl_print_dev_data() para informar en debugfs solo estadísticas sobre los aceleradores admitidos. Un valor incorrecto de los elementos en slice_cnt podría provocar una lectura de memoria fuera de los límites. Por el momento, no existe una implementación de FW que devuelva un valor incorrecto, pero para mayor solidez, valide la matriz de recuento de sectores devuelta por FW.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: macintosh/via-macii: Corrección "ERROR: función de suspensión llamada desde un contexto no válido" El controlador ADB via-macii llama a request_irq() después de deshabilitar las interrupciones bruscas. Pero aquí no es necesario deshabilitar las interrupciones porque la interrupción del registro de desplazamiento de VIA se enmascaró durante la inicialización de VIA1.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrige el manejo del estado de netif. mlx5e_suspend limpia los recursos solo si netif_device_present() devuelve verdadero. Sin embargo, mlx5e_resume cambia el estado de netif, a través de mlx5e_nic_enable, solo si reg_state == NETREG_REGISTERED. En el siguiente caso, lo anterior conduce a NULL-ptr Ups[1] y pérdidas de memoria: mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev no se registra, no llama a netif_device_attach() Register_netdev <-- falló por algún motivo. ERROR_FLOW: _mlx5e_suspend <-- netif_device_present devuelve falso, los recursos no se liberan :( Por lo tanto, limpie los recursos en este caso también. [1] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 PGD 0 P4D 0 Ups: 0010 [#1 ] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuild .qemu.org 01/04/2014 RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación at0xffffffffffffffd6 RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Seguimiento de llamadas: __die+0x20/0x60 +0x14c/0x3c0? exc_page_fault+0x75/0x140 ? _replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliar_match_id+0x6a/0x90 sonda_bus_auxiliar+0x38/0x80 ? driver_sysfs_add+0x51/0x80 realmente_probe+0xc9/0x3e0? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x8 6/0xa0 dispositivo_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] _uno+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+ 0xbf/0x210 ? kernfs_create_link+0x5d/0xa0? sysfs_do_create_link_sd+0x60/0xc0 realmente_probe+0xc9/0x3e0? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+ 0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 Entry_SYSCALL_64_after_hwframe+0x4 6/0xb0 CR2: 0000000000000000 ---[ final de seguimiento 0000000000000000 ]---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: mt76: connac: comprobar nulo antes de desreferenciar El wcid puede ser NULL. Se debe verificar su validez antes de eliminar la referencia para evitar fallas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/virt/acrn: corrige las comprobaciones de PFNMAP PTE en acrn_vm_ram_map() Serie de parches "mm: mejoras en follow_pte() y correcciones en acrn follow_pte()". El parche n.º 1 soluciona varios problemas que detecté en el controlador acrn. Se compila, eso es todo lo que sé. Apreciaré algunas revisiones y pruebas por parte de la gente de acrn. El parche #2+#3 mejora follow_pte(), pasa un VMA en lugar del MM, agrega más controles de cordura y mejora la documentación. Lo probé rápidamente en x86-64 usando VM_PAT y terminó usando follow_pte(). Este parche (de 3): Actualmente no manejamos varios casos, lo que resulta en un uso peligroso de follow_pte() (anteriormente follow_pfn()). (1) No estamos verificando los permisos de escritura de PTE. ¿Quizás simplemente deberíamos requerir siempre pte_write() como lo hacemos para pin_user_pages_fast(FOLL_WRITE)? Es difícil saberlo, así que busquemos ACRN_MEM_ACCESS_WRITE por ahora. (2) No rechazamos páginas recontadas. Como no utilizamos notificadores MMU, jugar con páginas descontadas es peligroso y puede resultar en use-after-free. Asegurémonos de rechazarlos. (3) Sólo estamos ante el primer PTE de una gama mayor. Solo buscamos una PTE, pero memmap->len puede abarcar un área más grande. Recorramos todos los PTE involucrados y asegurémonos de que el rango de PFN sea realmente contiguo. Rechace todo lo demás: no podría haber funcionado de ninguna manera, y más bien utilizó PFN de acceso a los que no deberíamos acceder.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: i2c: et8ek8: No eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_VIDEO_ET8EK8=y. Cuando un dispositivo de este tipo se desvincula (por ejemplo, usando sysfs o hotplug), el controlador simplemente se elimina sin que se realice la limpieza. Esto da como resultado fugas de recursos. Solucionarlo compilando la devolución de llamada de eliminación incondicionalmente. Esto también corrige una advertencia de modpost W=1: ADVERTENCIA: modpost: drivers/media/i2c/et8ek8/et8ek8: sección no coincide en referencia: et8ek8_i2c_driver+0x10 (sección: .data) -> et8ek8_remove (sección: .exit.text)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: corrige una ejecución entre lectores y cambia el tamaño de las comprobaciones. El código del lector en rb_get_reader_page() intercambia una nueva página del lector en el búfer circular haciendo cmpxchg en old->list.prev ->siguiente para apuntar a la nueva página. Después de eso, si la operación es exitosa, old->list.next->prev también se actualiza. Esto significa que la lista doblemente enlazada subyacente es temporalmente inconsistente, página->anterior->siguiente o página->siguiente->anterior podría no ser igual a la página para alguna página en el búfer circular. La operación de cambio de tamaño en ring_buffer_resize() se puede invocar en paralelo. Llama a rb_check_pages(), que puede detectar la inconsistencia descrita y detener el seguimiento: [190.271762] ------------[ cortar aquí ]------------ [ 190.271771] ADVERTENCIA: CPU: 1 PID: 6186 en kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [190.271789] Módulos vinculados en: [...] [190.271991] Módulos contaminados descargados: intel_uncore_frequency(E) :1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: cargado Contaminado: GE 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 01/04/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Código: [.. .] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 00000000000000007 RCX: ffff8eba01f13d80 [ 19 0.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 00000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:000000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 [ 190 .272077] Seguimiento de llamadas: [190.272098 ] [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] _entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248 ] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] Entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d26 3 [ 190.272381] Código: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000 000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12 : 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 00000000000000002 [ 190.272412] [ 4] ---[ end trace 0000000000000000 ]--- Tenga en cuenta que ring_buffer_resize() llama a rb_check_pages() solo si el trace_buffer principal tiene grabación desactivada. El reciente commit d78ab792705c ("rastreo: detener el rastreador actual al cambiar el tamaño del búfer") hace que ahora sea siempre el caso, lo que hace que sea más probable experimentar este problema. No obstante, la ventana para llegar a esta ejecución es muy pequeña. Para ayudar a reproducirlo, se puede agregar un bucle de retardo en rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) ir a girar; for (unsigned i = 0; i < 1U << 26; i++) /* bucle de retardo insertado ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: mover el bloqueo EST a la estructura stmmac_priv Reinicializar toda la estructura EST también restablecería el bloqueo mutex que está incrustado en la estructura EST y luego activaría la siguiente advertencia. Para solucionar esto, mueva el candado a la estructura stmmac_priv. También necesitamos volver a adquirir el bloqueo mutex al realizar esta inicialización. DEBUG_LOCKS_WARN_ON(lock->magic != lock) ADVERTENCIA: CPU: 3 PID: 505 en kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Módulos vinculados en: CPU: 3 PID: 505 Comm: tc No contaminado 6.9. 0-rc6-00053-g0106679839f7-dirty #29 Nombre del hardware: NXP i.MX8MPlus Placa EVK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: __mutex_lock+0xd84/ 0x1068 lr: __mutex_lock+0xd84/0x1068 sp: ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 : ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 00000000000000000 x20: 0000000000000000 x19: c083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: 2bb2640 x9: ffffffc082bb2698 x8: 0000000000017fe8 x7: c0000000fffffff x6: 0000000000000001 x5: ffffff8178fe0d48 x4: 0000000000000000 x3: 00000000 00000027 x2: ffffff8178fe0d50 x1: 0000000000000000 x0: 0000000000000000 Rastreo de llamadas: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c