Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: corregir posible use after free en memcg_write_event_control() memcg_write_event_control() accede a dentry->d_name del fd de control especificado para enrutar la llamada de escritura. Como no se puede cambiar el nombre de un archivo de interfaz de cgroup, es seguro acceder a d_name siempre que el archivo especificado sea un archivo cgroup normal. Además, como estos archivos de interfaz de cgroup no se pueden eliminar antes del directorio, también es seguro acceder al padre. Antes de 347c4a874710 ("memcg: eliminar cgroup_event->cft"), había una llamada a __file_cft() que verificaba que el archivo especificado es un archivo cgroupfs normal antes de futuros accesos. El puntero cftype devuelto desde __file_cft() ya no era necesario y el commit eliminó inadvertidamente la verificación del tipo de archivo, lo que permitió que cualquier archivo se deslizara. Con las invariantes rotas, los accesos a d_name y a los padres ahora pueden competir contra los cambios de nombre y las eliminaciones de archivos arbitrarios y causar use-after-free. Corrija el error resucitando la comprobación del tipo de archivo en __file_cft(). Ahora que cgroupfs está implementado a través de kernfs, la comprobación de las operaciones de archivo debe pasar por una capa de indirección. En su lugar, verifiquemos el tipo de superbloque y dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: Corregir oops debido a ejecución con cookie_lru y use_cookie Si una cookie caduca desde la LRU y el indicador LRU_DISCARD está configurado, pero la máquina de estado aún no se ha ejecutado, es posible que otro hilo pueda llamar a fscache_use_cookie y comenzar a usarlo. Cuando finalmente se ejecuta cookie_worker, verá el indicador LRU_DISCARD configurado, hará la transición de cookie->state a LRU_DISCARDING, que luego retirará la cookie. Una vez que se retira la cookie, se elimina el objeto, se producirán los siguientes oops porque el objeto asociado con la cookie ahora es NULL. Corrija los oops borrando el bit LRU_DISCARD si otro hilo usa la cookie antes de que se ejecute cookie_worker. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Contaminado: GE 6.0.0-5.dneg.x86_64 #1 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/08/2022 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Seguimiento de llamadas: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 hilo+0xd6/0x100

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corregir el use after free durante la recuperación de la GPU [Por qué] [ 754.862560] refcount_t: desbordamiento; use after free. [ 754.862898] Seguimiento de llamadas: [ 754.862903] [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [Cómo] Es posible que fw_fence no se inicialice, verifique si dma_fence_init se realiza antes de la liberación del trabajo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: Reparar sring NULL después de la migración en vivo Se configura un NAPI para cada sring de red para sondear los datos al kernel El sring con el host de origen se destruye antes de la migración en vivo y se configura el nuevo sring con el host de destino después de la migración en vivo. El NAPI para el sring antiguo no se elimina hasta que se configura el nuevo sring con el host de destino después de la migración. Con busy_poll/busy_read habilitado, el NAPI se puede sondear antes de que se elimine cuando se reanuda la VM. ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] Seguimiento de llamadas PTI de SMP: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 evento_hist_trigger+0x14a/0x260 finalizar_cambio_tarea+0x71/0x230 __schedule+0x256/0x890 recalc_sigping+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 reserva_bloqueo_buffer_anillo+0x123/0x3d0 llamada_activadores_evento+0x87/0xb0 confirmación_buffer_evento_trace+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ fin del seguimiento f8601785b354351c ]--- la interfaz de xen debe eliminar las NAPI de los antiguos srings antes de la migración en vivo, ya que los srings de enlace se destruyen. Hay una pequeña ventana entre los srings que se establecen en NULL y los NAPI que se deshabilitan. Es seguro ya que los subprocesos NAPI todavía están congelados en ese momento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Obtener user_ns de in_skb en unix_diag_get_exact(). Wei Chen informó una desreferencia NULL en sk_user_ns() [0][1], y Paolo diagnosticó la causa raíz: en unix_diag_get_exact(), el skb recién asignado no tiene sk. [2] Debemos obtener el user_ns de NETLINK_CB(in_skb).sk y pasarlo a sk_diag_fill(). [0]: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000270 #PF: acceso de lectura del supervisor en modo núcleo #PF: error_code(0x0000) - página no presente PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 No contaminado 6.1.0-rc5-next-20221118 #2 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_user_ns include/net/sock.h:920 [en línea] RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [en línea] RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170 Código: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: unix_diag_get_exact net/unix/diag.c:285 [en línea] unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317 __sock_diag_cmd net/core/sock_diag.c:235 [en línea] sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [en línea] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0x38f/0x500 net/socket.c:2476 ___sys_sendmsg net/socket.c:2530 [en línea] __sys_sendmsg+0x197/0x230 net/socket.c:2559 __do_sys_sendmsg net/socket.c:2568 [en línea] __se_sys_sendmsg net/socket.c:2566 [en línea] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4697f9 Código: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 000000000000000 RSI: 00000000200001c0 RDI: 000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 Módulos vinculados en: CR2: 0000000000000270 [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/

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.