Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Comprobación de sb_bsize_shift tras leer el superbloque. A los fuzzers les gusta manipular sb_bsize_shift, pero en realidad es muy improbable que este campo se corrompa por sí solo. Sin embargo, conviene comprobarlo para evitar errores de montaje problemáticos debido a cálculos erróneos. Siempre es un valor fijo basado en el tamaño del bloque, por lo que podemos comprobar que sea el valor esperado. Probado con: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; Antes de este parche obtenemos una retirada después de [ 76.413681] gfs2: fsid=loop0.0: fatal: bloque de metadatos no válido [ 76.413681] bh = 19 (tipo: exp=5, encontrado=4) [ 76.413681] función = gfs2_meta_buffer, archivo = fs/gfs2/meta_io.c, línea = 492 y con UBSAN configurado también obtenemos quejas como [ 76.373395] UBSAN: cambio fuera de los límites en fs/gfs2/ops_fstype.c:295:19 [ 76.373815] cambio El exponente 4294967287 es demasiado grande para el tipo de 64 bits 'long unsigned int'. Después del parche, estas quejas no aparecen, el montaje falla inmediatamente y obtenemos una explicación en dmesg.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p: trans_fd/p9_conn_cancel: eliminar el bloqueo del cliente anteriormente. syzbot informó un bloqueo doble aquí y ya no necesitamos este bloqueo después de que las solicitudes se hayan movido a la lista local: simplemente elimine el bloqueo anteriormente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/trans_fd: syzbot reporta que la tarea se bloquea en p9_fd_close() [1], ya que p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close() no interrumpe las solicitudes kernel_read() de p9_fd_read() de p9_read_work() o kernel_write() de p9_fd_write() de p9_write_work() ya iniciadas. Dado que p9_socket_open() establece el indicador O_NONBLOCK, p9_mux_poll_stop() no necesita interrumpir kernel_read()/kernel_write(). Sin embargo, dado que p9_fd_open() no establece el indicador O_NONBLOCK, sino que bloquea la tubería a menos que la señal esté pendiente, p9_mux_poll_stop() necesita interrumpir kernel_read()/kernel_write() cuando el descriptor de archivo hace referencia a una tubería. En otras palabras, el descriptor de archivo de la tubería debe manejarse como si fuera un descriptor de archivo de socket. De alguna manera, necesitamos interrumpir kernel_read()/kernel_write() en las tuberías. Un cambio mínimo, que este parche está realizando, es establecer el indicador O_NONBLOCK de p9_fd_open(), ya que el indicador O_NONBLOCK no afecta la lectura/escritura de archivos normales. Pero este enfoque cambia el indicador O_NONBLOCK en los descriptores de archivo proporcionados por el espacio de usuario (lo que podría romper los programas del espacio de usuario), y el indicador O_NONBLOCK podría ser cambiado por el espacio de usuario. Sería posible establecer el indicador O_NONBLOCK cada vez que se invoca p9_fd_read()/p9_fd_write(), pero aún queda una pequeña ventana de tiempo para borrar el indicador O_NONBLOCK. Si no queremos manipular el indicador O_NONBLOCK, podríamos rodear kernel_read()/kernel_write() con set_thread_flag(TIF_SIGPENDING) y recalc_sigpending(). Dado que los trabajos de p9_read_work()/p9_write_work() son procesados por hilos del núcleo que procesan la cola de trabajo global system_wq, no se pudieron enviar señales desde hilos remotos al llamar a p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close(). Por lo tanto, sería necesario llamar a set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() cada vez si dependemos de señales para que kernel_read()/kernel_write() sea no bloqueante. [Dominique: añadir comentario a la sugerencia de Christian]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: Creación de la estructura nlmsgerr con comprobación de los límites. En preparación para que FORTIFY_SOURCE realice la comprobación de los límites en memcpy(), cambie de __nlmsg_put a nlmsg_put() y explique la comprobación de los límites para procesar memcpy() en una estructura de matriz flexible compuesta. Esto evita esta futura advertencia en tiempo de ejecución: memcpy: se detectó una escritura que abarca campos (tamaño 32) en un solo campo "&errmsg->msg" en net/netlink/af_netlink.c:2447 (tamaño 16).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/9p: uso de un spinlock dedicado para trans_fd. Copiando descaradamente la explicación del parche sugerido por Tetsuo Handa[1] (ligeramente reformulada): syzbot reporta un estado de bloqueo inconsistente en p9_req_put()[2], para p9_tag_remove() desde p9_req_put() desde el contexto IRQ, se usa spin_lock_irqsave() en "struct p9_client"->lock, pero trans_fd (no desde el contexto IRQ) usa spin_lock(). Dado que los bloqueos protegen elementos diferentes en client.c y en trans_fd.c, simplemente reemplace el bloqueo de trans_fd.c por uno nuevo específico para el transporte (el de client.c protege el IDR para las asignaciones de FID/etiqueta, mientras que el de trans_fd.c protege su propia lista de solicitudes y el campo de estado de la solicitud, que actúa como la máquina de estados del transporte).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: desbordamiento de comprobación al iterar ATTR_RECORDs El kernel itera sobre los ATTR_RECORD en el registro mft en ntfs_attr_find(). Debido a que los ATTR_RECORD están uno al lado del otro, el kernel puede obtener el siguiente ATTR_RECORD desde la dirección final del ATTR_RECORD actual, a través del campo de longitud del ATTR_RECORD actual. El problema es que durante la iteración, cuando el kernel calcula la dirección final del ATTR_RECORD actual, el kernel puede desencadenar un error de desbordamiento de enteros al ejecutar `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Esto puede envolverse, lo que lleva a una iteración eterna en sistemas de 32 bits. Este parche lo resuelve añadiendo algunas comprobaciones en el cálculo de la dirección final del ATTR_RECORD actual durante la iteración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una pérdida de memoria Olvidamos liberar new_model_number

Se descubrió que D-Link DIR-816 A2V1.1.0B05 contenía una inyección de comando en iptablesWebsFilterRun, que permite a atacantes remotos ejecutar comandos arbitrarios a través del shell.

Se descubrió que TOTOLINK CP900 V6.3c.1144_B20190715 contenía una vulnerabilidad de inyección de comandos en la función setUpgradeUboot mediante el parámetro FileName. Esta vulnerabilidad permite a los atacantes ejecutar comandos arbitrarios mediante una solicitud manipulada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Actualizar la clave del bloque de control de skb en ieee80211_tx_dequeue() La clave del bloque de control de skb ieee80211 (establecida cuando skb se puso en cola) podría haberse eliminado antes de la llamada a ieee80211_tx_dequeue(). ieee80211_tx_dequeue() ya llamó a ieee80211_tx_h_select_key() para obtener la clave actual, pero este último no actualiza la clave en el bloque de control de skb en caso de que sea NULL. Debido a que algunos controladores realmente usan esta clave en sus devoluciones de llamada TX (por ejemplo, ath1{1,2}k_mac_op_tx()), esto podría llevar a use after free a continuación: ERROR: KASAN: slab-use-after-free en ath11k_mac_op_tx+0x590/0x61c Lectura de tamaño 4 en la dirección ffffff803083c248 por la tarea kworker/u16:4/1440 CPU: 3 UID: 0 PID: 1440 Comm: kworker/u16:4 No contaminado 6.13.0-ge128f627f404 #2 Nombre del hardware: HW (DT) Cola de trabajo: bat_events batadv_send_outstanding_bcast_packet Rastreo de llamadas: show_stack+0x14/0x1c (C) dump_stack_lvl+0x58/0x74 print_report+0x164/0x4c0 kasan_report+0xac/0xe8 __asan_report_load4_noabort+0x1c/0x24 ath11k_mac_op_tx+0x590/0x61c ieee80211_handle_wake_tx_queue+0x12c/0x1c8 ieee80211_queue_skb+0xdcc/0x1b4c ieee80211_tx+0x1ec/0x2bc ieee80211_xmit+0x224/0x324 __ieee80211_subif_start_xmit+0x85c/0xcf8 ieee80211_subif_start_xmit+0xc0/0xec4 dev_hard_start_xmit+0xf4/0x28c __dev_queue_xmit+0x6ac/0x318c batadv_send_skb_packet+0x38c/0x4b0 batadv_send_outstanding_bcast_packet+0x110/0x328 process_one_work+0x578/0xc10 worker_thread+0x4bc/0xc7c kthread+0x2f8/0x380 ret_from_fork+0x10/0x20 Allocated by task 1906: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_alloc_info+0x3c/0x4c __kasan_kmalloc+0xac/0xb0 __kmalloc_noprof+0x1b4/0x380 ieee80211_key_alloc+0x3c/0xb64 ieee80211_add_key+0x1b4/0x71c nl80211_new_key+0x2b4/0x5d8 genl_family_rcv_msg_doit+0x198/0x240 <...> Freed by task 1494: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_free_info+0x48/0x94 __kasan_slab_free+0x48/0x60 kfree+0xc8/0x31c kfree_sensitive+0x70/0x80 ieee80211_key_free_common+0x10c/0x174 ieee80211_free_keys+0x188/0x46c ieee80211_stop_mesh+0x70/0x2cc ieee80211_leave_mesh+0x1c/0x60 cfg80211_leave_mesh+0xe0/0x280 cfg80211_leave+0x1e0/0x244 <...> Restablezca la clave del bloque de control SKB antes de llamar a ieee80211_tx_h_select_key() para evitar eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: at76c50x: se corrige el use after free en at76_disconnect. La memoria a la que apunta priv se libera al final de la función at76_delete_device (mediante ieee80211_free_hw). Sin embargo, el código accede al campo udev del objeto liberado para colocar el dispositivo USB. Esto también puede provocar una fuga de memoria del dispositivo USB. Se soluciona usando udev desde la interfaz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Se corrige la desreferencia de puntero null en avs_component_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, avs_component_probe() no verifica este caso, lo que resulta en una desreferencia de puntero NULL.