Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: sch_ets: no elimine las clases inactivas de la lista de turnos Shuang informó que el siguiente script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bandas 8 estricto 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a propio -b 00:c1:a0: c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 estricto 2 cuantos 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 falla sistemáticamente cuando la línea 2) se comenta: corrupción list_del, ffff8e028404bd30->el siguiente es LIST_POISON1 (dead000000000100) ------------[ cortar aquí ]------------ ERROR del kernel en lib/list_debug. c:47! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comunicaciones: tc Not tainted 5.16.0-rc4+ #478 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066 +0f1aadab 01/04/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 4 8 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 246 RAX: 000000000000004eRBX : 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 00000000000 00000 R09: c0000000ffff7fff R10: 00000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 000000000035 0ef0 Seguimiento de llamadas: ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/ 0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7efdc8031338 Código: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: de RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 00000000000000246 R12: 0000000000000001 R 13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 Módulos vinculados en: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common pcs pkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [última descarga: sch_ets] ---[ fin de seguimiento f35878d191 2655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX 000 0000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: FFFFFAE46807A36A8 R12: FFFFF8E028404B800 R13: FFFF8E028404BD30 R14: Dead000000000100 R15: FFFFF8E02FAFA2400 FUT: GS: FFFF8E02FB600000 (0000) KNLGS: 000000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 - --truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hns3: corrige el error de use-after-free en hclgevf_send_mbx_msg Actualmente, la función hns3_remove desinstala primero la instancia del cliente y luego desinstala el dispositivo del motor de aceleración. El dispositivo de red se libera en el proceso de desinstalación de la instancia del cliente, pero el proceso de desinstalación del dispositivo del motor de aceleración aún lo utiliza para rastrear la información del tiempo de ejecución. Esto provoca un problema de use-after-free. Entonces lo soluciona verificando el estado del registro de la instancia para evitar use after free.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet_diag: corrige la fuga de información del kernel para sockets UDP KMSAN informó una fuga de información del kernel [1], que puede ser explotada por usuarios sin privilegios. Después del análisis resultó que UDP no estaba inicializando r->idiag_expires. Otros usuarios de inet_sk_diag_fill() podrían cometer el mismo error en el futuro, así que solucione este problema en inet_sk_diag_fill(). [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:121 [en línea] ERROR: KMSAN: kernel-infoleak en copia lib/iov_iter.c:156 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [en línea] copia lib/iov_iter.c:156 [en línea] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [en línea] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram .c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [en línea] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [en línea] sock_recvmsg net/socket.c:962 [en línea] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [en línea] new_sync_read fs/read_write.c:400 [en línea] vfs_read+0x1631/0x1980 fs/read_write.c: 481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [en línea] __se_sys_read fs/read_write.c:627 [en línea] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 _arco x64/ x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit se creó en: slab_post_alloc_hook mm/slab.h:524 [en línea] slab_alloc_node mm/slub.c:3251 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en línea] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [en línea] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c: 1319 [en línea] netlink_unicast+0x1095/0x1360 netLink/af_netlink.c: 1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_etlink.c: 1916 sockm. C: 704 [ en línea] sock_sendmsg net/socket.c:724 [en línea] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:9 24 [en línea] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [en línea] __se_sys_writev fs/read_write.c:1037 [en línea] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 _syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Los bytes 68-71 de 312 no están inicializados El acceso a la memoria de tamaño 312 comienza en ffff88812ab54000 Datos copiados a la dirección de usuario 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_cake: no llamar a cake_destroy() desde cake_init() Se supone que las qdiscs no deben llamar a su propio método destroy() desde init(), porque la pila central ya lo hace. syzbot pudo activar el use-after-free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [en línea] ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Módulos vinculados en: CPU: 0 PID: 21902 Comm: syz-executor189 No contaminado 5.16 .0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [en línea] RIP: 0010:__mutex_lock+ 0x9ec/0x12f0 kernel/locking/mutex.c:740 Código: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 00000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 000055556abc400(0000) GS:ffff8880b9c0000 0(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Seguimiento de llamadas: tcf_chain0_head_change_cb_del+0x2e/0 x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [ en línea] tcf_block_put_ext net/sched/cls_api.c:1376 [en línea] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da /0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/ af_netlink. c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c :704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b 0 red/toma. c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1bb06badb9 Código: No se puede acceder al código de operación bytes en RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000000000003 RCX: 00007f1bb06badb9 RDX: 000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 00000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: utilice Latest_dev en btrfs_show_devname El caso de prueba btrfs/238 informa la siguiente advertencia: ADVERTENCIA: CPU: 3 PID: 481 en fs/btrfs/super.c:2509 btrfs_show_devname+0x104 /0x1e8 [btrfs] CPU: 2 PID: 1 Comunicación: systemd Contaminado: GWO 5.14.0-rc1-custom #72 Nombre de hardware: QEMU Máquina virtual QEMU, BIOS 0.0.0 06/02/2015 Rastreo de llamadas: btrfs_show_devname+0x108/ 0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler +0x84/0xe4 el0t_64_sync+0x198/0x19c Motivo: mientras btrfs_prepare_sprout() mueve fs_devices::devices a fs_devices::seed_list, btrfs_show_devname() busca los dispositivos y no encuentra ninguno, lo que genera la advertencia como se muestra arriba. Solución: last_dev se actualiza según los cambios en la lista de dispositivos. Eso significa que podríamos usar el último_dev->name para mostrar el nombre del dispositivo en /proc/self/mounts, el puntero siempre será válido tal como está asignado antes de que el dispositivo se elimine de la lista en eliminar o reemplazar. La protección de la RCU es suficiente, ya que la estructura del dispositivo se libera después de la sincronización.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm btree remove: corrige el use after free en rebalance_children() Mueve dm_tm_unlock() después de dm_tm_dec().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tee: amdtee: corrige un error IS_ERR() vs NULL La función __get_free_pages() no devuelve punteros de error, devuelve NULL, así que corrija esta condición para evitar una desreferencia a NULL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: rastrea solo frameworks de datos QoS para control de admisión. Para el control de admisión, obviamente todo eso solo funciona para frameworks de datos QoS; de lo contrario, ni siquiera podemos acceder al campo QoS en el encabezado. Syzbot informó (ver más abajo) un valor no inicializado aquí debido al estado de un paquete nullfunc sin QoS, que ni siquiera es lo suficientemente largo para contener el encabezado de QoS. Solucione este problema para hacer algo únicamente con los paquetes de datos QoS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: mejora la solidez del manejo de la cola de auditoría. Si el daemon de auditoría alguna vez se atascara en un estado detenido, kauditd_thread() del kernel podría bloquearse al intentar enviar registros de auditoría al espacio de usuario. daemon de auditoría. Con el subproceso del núcleo bloqueado, es posible que la cola de auditoría crezca sin límites, ya que ciertos eventos que generan registros de auditoría deben estar exentos de los límites de la cola, de lo contrario, el sistema entrará en un estado de bloqueo. Este parche resuelve este problema reduciendo el tiempo de espera de envío del socket del subproceso del núcleo de MAX_SCHEDULE_TIMEOUT a HZ/10 y modifica la función kauditd_send_queue() para gestionar mejor las distintas colas de auditoría cuando se producen problemas de conexión entre el núcleo y el daemon de auditoría. Con este parche, el trabajo pendiente puede crecer temporalmente más allá de los límites definidos cuando se detiene el daemon de auditoría y el sistema está bajo una fuerte presión de auditoría, pero kauditd_thread() continuará progresando y drenando las colas como lo haría con otros problemas de conexión. Por ejemplo, con el daemon de auditoría en estado detenido y el sistema configurado para auditar cada llamada al sistema, aún era posible apagar el sistema sin pánico en el kernel, interbloqueo, etc.; Por supuesto, el sistema tardó en cerrarse, pero eso es de esperarse dada la presión extrema de registrar cada llamada al sistema. El valor de tiempo de espera de HZ/10 se eligió principalmente a través de la experimentación y el "instinto" de este desarrollador. Probablemente no exista un valor perfecto, pero como este escenario tiene un alcance limitado (se necesitarían privilegios de root para enviar SIGSTOP al daemon de auditoría), probablemente no valga la pena exponerlo como un ajuste ajustable en este momento. Esto siempre se puede hacer en una fecha posterior si resulta necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vduse: verifique que el desplazamiento esté dentro de los límites en get_config() Esta condición verifica "len" pero no verifica "desplazamiento" y eso podría resultar en una lectura fuera de los límites si " desplazamiento > dev->config_size". El problema es que, dado que ambas variables no están firmadas, la resta "dev->config_size - offset" daría como resultado un valor sin firmar muy alto. Creo que estas comprobaciones podrían no ser necesarias porque se supone que "len" y "offset" ya se han validado mediante la función vhost_vdpa_config_validate(). Pero no conozco el código a la perfección y me gusta estar seguro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la pérdida de memoria en __add_inode_ref() La línea 1169 (#3) asigna un fragmento de memoria para victim_name mediante kmalloc(), pero cuando la función regresa en la línea 1184 (#4) victim_name asignado por la línea 1169 (#3) no se libera, lo que provocará una pérdida de memoria. Hay un fragmento de código similar en esta función para asignar un fragmento de memoria para victim_name en la línea 1104 (n.º 1), así como para liberar la memoria en la línea 1116 (n.º 2). Deberíamos kfree() victim_name cuando el valor de retorno de backref_in_log() sea menor que cero y antes de que la función regrese en la línea 1184 (#4). 1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans, 1058 struct btrfs_root *root, 1059 struct btrfs_path *path, 1060 struct btrfs_root *log_root, 1061 struct btrfs_inode *dir, 1062 struct btrfs_inode *inode, 63 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char *nombre, int nombrelen, 1065 int *search_done) 1066 { 1104 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #1: kmalloc (nombre_víctima-1) 1105 if (!nombre_víctima) 1106 return -ENOMEM; 1112 ret = backref_in_log(log_root, &search_key, 1113 parent_objectid, victim_name, 1114 victim_name_len); 1115 if (ret < 0) { 1116 kfree(nombre_víctima); // #2: kfree (nombre_víctima-1) 1117 return ret; 1118 } else if (!ret) { 1169 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #3: kmalloc (nombre_víctima-2) 1170 if (!nombre_víctima) 1171 return -ENOMEM; 1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 si (ret < 0) { 1184 retorno ret; // #4: falta kfree (nombre_víctima-2) 1185 } else if (!ret) { 1241 return 0; 1242 }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup KASAN informa una lectura fuera de los límites en rk_gmac_setup en la línea: while (ops->regs[i]) { Esto sucede en la mayoría de las plataformas, ya que el miembro de la matriz flexible regs está vacío, por lo que aquí se lee la memoria después de la estructura de operaciones. Parece que la mayor parte de esto contiene cero de todos modos, así que tenemos suerte y todo sigue funcionando. Para evitar agregar datos redundantes a casi todas las estructuras de operaciones, agregue un nuevo indicador para indicar si el campo regs es válido y evite este bucle cuando no lo sea.