Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpftool: Se corrige la desreferencia de puntero nulo al anclar {PROG, MAP, LINK} sin archivo. Al usar bpftool para anclar {PROG, MAP, LINK} sin archivo, se produce un fallo de segmentación. La razón es que la falta de archivo provoca que strlen active la desreferencia de puntero nulo. El seguimiento de pila correspondiente se muestra a continuación: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- Desreferencia de puntero nulo. Se corrige añadiendo validación al proceso común.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit() Cuando el dispositivo está en ejecución y se cambia el estado de la interfaz, se activa el problema gpf. El proceso de activación del problema es el siguiente: Hilo A: Hilo B ieee80211_runtime_change_iftype() process_one_work() ... ... ieee80211_do_stop() ... ... ... sdata->bss = NULL ... ... ieee80211_subif_start_xmit() ieee80211_multicast_to_unicast //!sdata->bss->multicast_to_unicast cause gpf issue Cuando se cambia el estado de la interfaz, la cola de envío continúa enviando paquetes. Después de que bss se establece en NULL, se accede a bss. Como resultado, esto causa un problema de general-protection-fault. La siguiente es la información de la pila: falla de protección general, probablemente para la dirección no canónica 0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000178-0x000000000000017f] Cola de trabajo: mld mld_ifc_work RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310 Rastreo de llamadas: dev_hard_start_xmit+0x1be/0x990 __dev_queue_xmit+0x2c9a/0x3b60 ip6_finish_output2+0xf92/0x1520 ip6_finish_output+0x6af/0x11e0 ip6_output+0x1ed/0x540 mld_sendpack+0xa09/0xe70 mld_ifc_work+0x71c/0xdb0 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, verificador: Se corrige una fuga de memoria en la reasignación de matriz para el estado de la pila. Si krealloc() devuelve un error (NULL), los usuarios de realloc_array() establecían sus punteros de asignación en NULL, pero en caso de error, krealloc() no modifica la asignación original. Esto provocaría una fuga de recursos de memoria. En su lugar, se libera la asignación anterior en la ruta de gestión de errores. La información de fuga de memoria es la siguiente, tal como lo informó Zhengchao: objeto sin referencia 0xffff888019801800 (tamaño 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (edad 17.170s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de advertencia en 'ext4_da_release_space' Syzkaller informa del problema de la siguiente manera: EXT4-fs (loop0): Detalles del bloque libre/sucio EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Detalles de la reserva del bloque EXT4-fs (loop0): i_reserved_data_blocks=0 Advertencia de EXT4-fs (dispositivo loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 con solo 0 bloques de datos reservados ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 92 en fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Módulos vinculados: CPU: 0 PID: 92 Comm: kworker/u4:4 No contaminado 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Cola de trabajo: escritura diferida wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 El problema anterior puede ocurrir de la siguiente manera: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> hará que eh->eh_entries no sea cero y establecerá el indicador de extensión ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block si (!ext4_es_scan_clu(inodo, &ext4_es_is_delonly, lblk)) si (!ext4_es_scan_clu(inodo, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inodo, EXT4_B2C(sbi, lblk)); -> devolverá 1 asignado = verdadero; ext4_es_insert_delayed_block(inodo, lblk, asignado); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger WARNING Como se indica arriba, para resolver el problema anterior, prohíba migrar los inodes que tienen datos en línea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: corrección del pánico en frag_list con tipos de asignación de encabezado mixtos. Desde el commit 3dcbdb134f32 ("net: gso: corrección del error skb_segment al dividir gso_size de un skb alterado con frag_list de encabezado lineal"), se permite cambiar gso_size de un paquete GRO. Sin embargo, esta confirmación asume que basta con comprobar el primer miembro de list_skb; es decir, si alguno de los miembros de list_skb tiene un encabezado distinto de head_frag, el primero también lo tendrá. Resulta que esta suposición no se cumple. Hemos observado que se ha alcanzado BUG_ON en skb_segment cuando los skbs de frag_list tenían un head_frag distinto con el controlador vmxnet3. Esto se debe a que __netdev_alloc_skb y __napi_alloc_skb pueden devolver un skb con respaldo de página o asignado a km, según el tamaño solicitado. Como resultado, el último skb pequeño en el paquete GRO puede ser asignado a km. Hay tres ubicaciones diferentes donde esto puede ser corregido: (1) Podríamos revisar head_frag en GRO y no permitir que GROing skbs con diferente head_frag. Sin embargo, eso llevaría a una regresión del rendimiento en rutas de avance normales con gso_size sin modificar, donde !head_frag en el último paquete no es un problema. (2) Establecer un indicador en bpf_skb_net_grow y bpf_skb_net_shrink que indique que NETIF_F_SG no es deseable. Esto requeriría consumir un poco en sk_buff. Además, ese indicador puede ser desactivado cuando todos los skbs en la frag_list están en retroceso de página. Para mantener un buen rendimiento, bpf_skb_net_grow/shrink tendría que recorrer la frag_list. (3) Recorrer la frag_list en skb_segment al determinar si NETIF_F_SG debe ser borrado. Esto, por supuesto, ralentiza el proceso. Este parche implementa (3). Para limitar el impacto en el rendimiento de skb_segment, la lista solo se recorre para skb con SKB_GSO_DODGY configurado y gso_size modificado. Por lo tanto, las rutas normales no la alcanzarán. Podríamos revisar solo el último skb, pero como necesitamos recorrer la lista completa de todos modos, mejor optemos por lo seguro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: corrige la advertencia sk->sk_forward_alloc de sk_stream_kill_queues Al ejecutar las pruebas automáticas `test_sockmap`, aparece la siguiente advertencia: ADVERTENCIA: CPU: 2 PID: 197 en net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae El caso raíz está en el commit 84472b436e76 ("bpf, sockmap: Arreglar más archivos no cargados mientras msg tiene more_data"), donde utilicé msg->sg.size para reemplazar tosend, lo que causó fallas: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes;

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de BUG_ON() cuando la entrada de directorio tiene un rec_len no válido El campo rec_len en la entrada de directorio debe ser un múltiplo de 4. Una imagen de sistema de archivos dañada se puede usar para generar un BUG() en ext4_rec_len_to_disk(), llamado desde make_indexed_dir(). ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Rastreo de llamadas: ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 La solución simplemente agrega una llamada a ext4_check_dir_entry() para validar la entrada del directorio, devolviendo -EFSCORRUPTED si la entrada no es válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la comprobación de longitud del tlv msg->req en tipc_nl_compat_name_table_dump_header Este es un seguimiento del commit 974cb0e3e7c9 ("tipc: corrige uninit-value en tipc_nl_compat_name_table_dump") donde debería haber convertido el tipo sizeof(..) a int para que funcione cuando TLV_GET_DATA_LEN() devuelve un valor negativo. syzbot informó un seguimiento de llamadas debido a esto: ERROR: KMSAN: valor no inicializado en ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: af_can: corrige la desreferencia del puntero NULL en can_rx_register() Provoca la desreferencia del puntero NULL cuando se prueba lo siguiente: (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) para crear el socket netlink. (b) use syscall(__NR_sendmsg, ...) para crear el dispositivo de enlace de enlace y el dispositivo de enlace vxcan, y enlace el dispositivo vxcan al dispositivo de enlace (también puede usar el comando ifenslave para enlazar el dispositivo vxcan al dispositivo de enlace). (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) para crear el socket CAN. (d) use syscall(__NR_bind, ...) para enlazar el dispositivo de enlace al socket CAN. El dispositivo de enlace invoca la interfaz de registro del protocolo can-raw para recibir paquetes CAN. Sin embargo, ml_priv no está asignado a dev, y dev_rcv_lists está asignado a NULL en can_rx_register(). En este caso, se producirá el problema de desreferencia del puntero NULL. La siguiente es la información de la pila: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:can_rx_register+0x12d/0x1e0 Seguimiento de llamadas: raw_enable_filters+0x8d/0x120 raw_enable_allfilters+0x3b/0x130 raw_bind+0x118/0x4f0 __sys_bind+0x163/0x1a0 __x64_sys_bind+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Se corrige la desreferencia del puntero NULL en svm_migrate_to_ram() ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p es NULL pero está desreferenciado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: mhi: se corrige una fuga de memoria en mhi_mbim_dellink. El controlador MHI registra el dispositivo de red sin configurar el indicador needs_free_netdev y NO llama a free_netdev() al cancelar el registro del dispositivo de red, lo que provoca una fuga de memoria. Este parche establece needs_free_netdev como verdadero al registrar el dispositivo de red, lo que hace que el subsistema netdev llame automáticamente a free_netdev() después de unregister_netdevice().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: se corrige una fuga de memoria en ipc_wwan_dellink. El controlador IOSM registra el dispositivo de red sin configurar el indicador needs_free_netdev y NO llama a free_netdev() al cancelar el registro del dispositivo de red, lo que provoca una fuga de memoria. Este parche establece needs_free_netdev como verdadero al registrar el dispositivo de red, lo que hace que el subsistema netdev llame automáticamente a free_netdev() después de cancelar el registro de netdevice().