Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Corregir la desreferencia de puntero nulo en la cola KFD. A través de KFD IOCTL Fuzzing, encontramos una desreferencia de puntero nulo al llamar a kfd_queue_acquire_buffers. (seleccionado de el commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Agregar verificación para mgmt_alloc_skb() en mgmt_remote_name() Agregar verificación para el valor de retorno de mgmt_alloc_skb() en mgmt_remote_name() para evitar la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: agregar verificación para mgmt_alloc_skb() en mgmt_device_connected(). Agregar verificación para el valor de retorno de mgmt_alloc_skb() en mgmt_device_connected() para evitar la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rapidio: se corrige un error de API cuando rio_add_net() falla. rio_add_net() llama a device_register() y falla cuando device_register() falla. Por lo tanto, se debe usar put_device() en lugar de kfree(). Se agregó "mport->net = NULL;" para evitar un problema de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm: pgtable: corregir problema de desreferencia de puntero NULL Cuando update_mmu_cache_range() es llamado por update_mmu_cache(), el parámetro vmf es NULL, lo que causará un problema de desreferencia de puntero NULL en adjust_pte(): No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 00000030 cuando se lee Nombre del hardware: Atmel AT91SAM9 La PC está en update_mmu_cache_range+0x1e0/0x278 LR está en pte_offset_map_rw_nolock+0x18/0x2c Rastreo de llamadas: update_mmu_cache_range de remove_migration_pte+0x29c/0x2ec remove_migration_pte de rmap_walk_file+0xcc/0x130 rmap_walk_file de remove_migration_ptes+0x90/0xa4 remove_migration_ptes de migration_pages_batch+0x6d4/0x858 migration_pages_batch de migration_pages+0x188/0x488 migration_pages de compact_zone+0x56c/0x954 compact_zone de compact_node+0x90/0xf0 compact_node de kcompactd+0x1d4/0x204 kcompactd de kthread+0x120/0x12c kthread de ret_from_fork+0x14/0x38 Pila de excepciones (0xc0d8bfb0 a 0xc0d8bff8) Para solucionarlo, no confíe en si 'ptl' es igual para decidir si mantener el bloqueo pte, sino decídalo en función de si CONFIG_SPLIT_PTE_PTLOCKS está habilitado. Además, si dos máquinas virtuales asignan a la misma página PTE, no es necesario volver a bloquear la página PTE; de lo contrario, se producirá un bloqueo. Simplemente agregue el parámetro need_lock para que adjust_pte() conozca esta información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: Asegúrese de que el reloj ptp se anule y libere si hclge_ptp_get_cycle devuelve un error. Durante la inicialización de ptp, hclge_ptp_get_cycle podría devolver un error y regresar directamente sin anular el registro ni liberarlo. Para evitarlo, llame a hclge_ptp_destroy_clock para anular el registro y liberar el reloj si hclge_ptp_get_cycle falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: llc: no usar skb_get() antes de dev_queue_xmit(). syzbot puede bloquear hosts [1], usando llc y dispositivos que no admiten IFF_TX_SKB_SHARING. En este caso, el controlador e1000 llama a eth_skb_pad() mientras el skb está compartido. Simplemente reemplace skb_get() por skb_clone() en net/llc/llc_s_ac.c. Tenga en cuenta que el controlador e1000 podría tener un problema con pktgen, ya que no borra IFF_TX_SKB_SHARING; este es un cambio ortogonal. Necesitamos auditar otros usos de skb_get() en net/llc. [1] ¡ERROR del kernel en net/core/skbuff.c:2178! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 No contaminado 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178 Rastreo de llamadas: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [en línea] skb_put_padto include/linux/skbuff.h:3862 [en línea] eth_skb_pad include/linux/etherdevice.h:656 [en línea] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [en línea] netdev_start_xmit include/linux/netdevice.h:5160 [en línea] xmit_one net/core/dev.c:3806 [en línea] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [en línea] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [en línea] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: corrección de propiedad en __udp_gso_segment. En __udp_gso_segment, el destructor de skb se elimina antes de segmentar el skb, pero la referencia del socket se mantiene intacta. Esto supone un problema si el skb original queda huérfano posteriormente, ya que podemos encontrarnos con el siguiente error: ¡ERROR del kernel en ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Rastreo de llamadas: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50 Lo anterior puede suceder después de una secuencia de eventos al usar OpenVSwitch, cuando una acción OVS_ACTION_ATTR_USERSPACE precede a una acción OVS_ACTION_ATTR_OUTPUT: 1. Se maneja OVS_ACTION_ATTR_USERSPACE (en do_execute_actions): el skb pasa por queue_gso_packets y luego __udp_gso_segment, donde se elimina su destructor. 2. Los datos de los segmentos se copian y se envían al espacio de usuario. 3. Se gestiona OVS_ACTION_ATTR_OUTPUT (en do_execute_actions) y se envía el mismo skb original a su ruta. 4. Si posteriormente se encuentra con skb_orphan, se detecta el error. Para solucionarlo, elimine también la referencia al socket en __udp_gso_segment.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no intentes hablar con un firmware muerto Esto corrige: bad state = 0 ADVERTENCIA: CPU: 10 PID: 702 en drivers/net/wireless/inel/iwlwifi/iwl-trans.c:178 iwl_trans_send_cmd+0xba/0xe0 [iwlwifi] Seguimiento de llamadas: ? __warn+0xca/0x1c0 ? iwl_trans_send_cmd+0xba/0xe0 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4] iwl_fw_dbg_clear_monitor_buf+0xd7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4] _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea92d2c341766bcc10b18699290068a] Pregunte si el firmware está activo antes de enviar un comando.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hid-steam: Se corrige el error "use-after-free" al desconectar el dispositivo. Al desconectar un dispositivo hid-steam, este debe limpiar el archivo client_hdev utilizado para interceptar el acceso a hidraw. Esto puede provocar la programación de un trabajo diferido para volver a conectar el dispositivo de entrada. Aunque la limpieza cancela el trabajo diferido, esto se realizó antes de que se limpiara el archivo client_hdev, por lo que se reprograma. Este parche corrige el orden para garantizar que el trabajo diferido se cancele correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: intel-ish-hid: soluciona el problema de use-after-free en ishtp_hid_remove() El sistema puede experimentar un bloqueo aleatorio unos minutos después de eliminar el controlador. Este problema se produce debido a la gestión incorrecta de la liberación de memoria en la función ishtp_hid_remove(). La función actualmente libera `driver_data` directamente dentro del bucle que destruye los dispositivos HID, lo que puede llevar al acceso a la memoria liberada. Específicamente, `hid_destroy_device()` usa `driver_data` cuando llama a `hid_ishtp_set_feature()` para apagar el sensor, por lo que liberar `driver_data` de antemano puede resultar en el acceso a memoria no válida. Este parche resuelve el problema almacenando `driver_data` en una variable temporal antes de llamar a `hid_destroy_device()` y luego liberando `driver_data` después de que se destruye el dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: intel-ish-hid: Se solucionó el problema de use-after-free en hid_ishtp_cl_remove(). Durante la operación `rmmod` del controlador `intel_ishtp_hid`, puede producirse un problema de use-after-free en la función hid_ishtp_cl_remove(). La función hid_ishtp_cl_deinit() se llama antes que ishtp_hid_remove(), lo que puede provocar el acceso a memoria o recursos liberados durante el proceso de eliminación. Seguimiento de llamadas: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? Informe de salida oculta + 0xe3/0x150 [oculto] Función de configuración de ishtp oculta + 0xb5/0x120 [intel_ishtp_oculto] Solicitud de ishtp oculta + 0x7b/0xb0 [intel_ishtp_oculto] Solicitud de hardware oculta + 0x1f/0x40 [oculto] Función de configuración del concentrador de sensores + 0x11f/0x190 [concentrador de sensores oculta] Estado de alimentación del sensor oculta + 0x147/0x1e0 [activador del sensor oculta] Reanudación del tiempo de ejecución del sensor oculta + 0x22/0x30 [activador del sensor oculta] Eliminación del concentrador de sensores + 0xa8/0xe0 [concentrador de sensores oculta] Eliminación del dispositivo oculta + 0x49/0xb0 [oculto] hid_destroy_device+0x6f/0x90 [hid] ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid] hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Además, ishtp_hid_remove() es un apagado a nivel HID, que debería ocurrir antes de la desconexión a nivel ISHTP. Este parche resuelve el problema reordenando las llamadas en hid_ishtp_cl_remove(). La función ishtp_hid_remove() ahora se llama antes que hid_ishtp_cl_deinit().