Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se solucionó el problema de no limpiar el led cuando bt_init fallo bt_init() llama a bt_leds_init() para registrar el led, pero si falla más tarde, no se llama a bt_leds_cleanup() para anular su registro. Esto puede causar pánico si se libera el argumento "bluetooth-power" en el texto y luego otro led_trigger_register() intenta acceder a él: ERROR: no se puede manejar el error de página para la dirección: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Seguimiento de llamadas: led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: se corrige el INIT_LIST_HEAD faltante en ieee802154_if_add(). La prueba de inyección de errores del kernel informa null-ptr-deref de la siguiente manera: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Seguimiento de llamadas: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() asigna wpan_dev como datos privados de netdev, pero No inicializa la lista en la estructura wpan_dev. cfg802154_netdev_notifier_call() administra la lista cuando se registra o cancela el registro del dispositivo y puede generar una desreferencia de PTR nula. Use INIT_LIST_HEAD() para inicializarla correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: amd8111: Se solucionó la fuga de recuento de referencia del dispositivo PCI. for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencia para el pci_dev devuelto y también disminuirá el recuento de referencia para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencia. Agregue el pci_dev_put() faltante después de la etiqueta 'out'. Dado que pci_dev_put() puede manejar el parámetro de entrada NULL, no hay ningún problema para la rama 'Dispositivo no encontrado'. Para la ruta normal, agregue pci_dev_put() en amd_gpio_exit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: corrección al usar __this_cpu_add en preemptible Actualmente en nf_conntrack_hash_check_insert(), cuando fallo en nf_ct_ext_valid_pre/post(), se llamará a NF_CT_STAT_INC() en el contexto preemptible, se puede activar un seguimiento de llamada: ERROR: uso de __this_cpu_add() en preemptible [00000000] código: conntrack/1636 el llamador es nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack] Seguimiento de llamada: dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 Este parche es para solucionarlo cambiando para usar NF_CT_STAT_INC_ATOMIC() para la comprobación de nf_ct_ext_valid_pre/post() en nf_conntrack_hash_check_insert(), así como nf_ct_ext_valid_post() en __nf_conntrack_confirm(). Tenga en cuenta que la comprobación de nf_ct_ext_valid_pre() en __nf_conntrack_confirm() es segura para usar NF_CT_STAT_INC(), ya que se encuentra bajo local_bh_disable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: reparar pérdida de memoria en gpiochip_setup_dev() Aquí hay un informe de seguimiento sobre la pérdida de memoria detectada en gpiochip_setup_dev(): objeto sin referencia 0xffff88810b406400 (tamaño 512): comm "python3", pid 1682, jiffies 4295346908 (edad 24.090s) seguimiento: kmalloc_trace device_add device_private_init en drivers/base/core.c:3361 (en línea por) device_add en drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() y gcdev_unregister() llamarían device_add() y device_del() (sin importar si CONFIG_GPIO_CDEV está habilitado o no) para registrar/anular el registro del dispositivo. Sin embargo, si device_add() tiene éxito, algún recurso (como la estructura device_private asignada por device_private_init()) no es liberado por device_del(). Por lo tanto, después de que device_add() tenga éxito por gcdev_register(), necesita llamar a put_device() para liberar el recurso en la ruta del controlador de error. Aquí avanzamos el registro de la función de liberación y dejamos que libere cada pieza de recurso por put_device() en lugar de kfree(). Mientras lo hacemos, solucionamos otro problema sutil, es decir, cuando gc->ngpio es igual a 0, todavía llamamos a kcalloc() y, en caso de un error adicional, a kfree() en el puntero ZERO_PTR, que no es NULL. No es un error en sí, sino más bien un desperdicio de recursos y una expectativa potencialmente errónea sobre el contenido de la variable gdev->descs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable_offload: corrección al usar __this_cpu_add en preemptible flow_offload_queue_work() se puede llamar en workqueue sin bh deshabilitado, como el seguimiento de llamadas que mostró en mi prueba act_ct, llamar a NF_FLOW_TABLE_STAT_INC() allí causaría un seguimiento de llamadas: ERROR: usar __this_cpu_add() en preemptible [00000000] código: kworker/u4:0/138560 el llamador es flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct] Seguimiento de llamadas: dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 Este parche lo corrige al usar NF_FLOW_TABLE_STAT_INC_ATOMIC() en lugar de flow_offload_queue_work(). Tenga en cuenta que para la rama FLOW_CLS_REPLACE en flow_offload_queue_work(), es posible que no se la llame en una ruta preemptible, pero es bueno usar NF_FLOW_TABLE_STAT_INC_ATOMIC() para todos los casos en flow_offload_queue_work().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: af_can: fix NULL pointer dereference in can_rcv_filter De manera análoga a el commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()"), debemos comprobar si falta una inicialización de ml_priv en la ruta de recepción de los marcos CAN. Desde el commit 4e096a18867a ("net: introduzca el puntero específico de CAN en la estructura net_device"), la verificación de que dev->type sea ARPHRD_CAN ya no es suficiente ya que los dispositivos de red vinculados o sintonizados afirman ser dispositivos CAN pero no inicializan ml_priv en consecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: núcleo: se corrige un desplazamiento fuera de los límites en hid_report_raw_event Syzbot informó un desplazamiento fuera de los límites en hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() llamado con n (128) > 32! (swapper/0) ========================================================================== UBSAN: cambio fuera de los límites en drivers/hid/hid-core.c:1323:20 el exponente de cambio 127 es demasiado grande para el tipo de 32 bits 'int' CPU: 0 PID: 0 Comm: swapper/0 No contaminado 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [en línea] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [en línea] hid_input_fetch_field drivers/hid/hid-core.c:1572 [en línea] hid_process_report drivers/hid/hid-core.c:1665 [en línea] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [en línea] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ================================================================================== Si el tamaño del entero (n sin signo) es mayor que 32 en snto32(), el exponente de desplazamiento será demasiado grande para 32 bits. Tipo 'int', lo que genera un error de desplazamiento fuera de los límites. Solucione este problema agregando una verificación del tamaño del entero (n sin signo) en snto32(). Para agregar compatibilidad con n mayor que 32 bits, configure n en 32, si n es mayor que 32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se corrige el error de índice de matriz fuera de límite en DCN32 DML [Por qué y cómo] La matriz LinkCapacitySupport está indexada con la cantidad de estados de voltaje y no con la cantidad máxima de DPP. Corrija el error modificando la declaración de la matriz para utilizar el tamaño de matriz correcto (más grande) de la cantidad total de estados de voltaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hisilicon: Se corrige un posible use after free en hisi_femac_rx() El skb se envía a napi_gro_receive() que puede liberarlo; después de llamarlo, desreferenciar skb puede desencadenar un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: corrige pérdida de memoria en ipc_mux_init() Cuando no se puede asignar ipc_mux->ul_adb.pp_qlt en ipc_mux_init(), ipc_mux no se libera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ravb: Se corrige el posible use after free en ravb_rx_gbeth() El skb se entrega a napi_gro_receive() que puede liberarlo; después de llamarlo, desreferenciar skb puede desencadenar el use after free.