Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: no cambie route.addr.src_addr fuera de las comprobaciones de estado. Si el estado no está inactivo, resolve_prepare_src() debería fallar inmediatamente y no debería ocurrir ningún cambio en el estado global. Sin embargo, sobrescribe incondicionalmente src_addr al intentar crear una dirección temporal. Por ejemplo, si el estado ya es RDMA_CM_LISTEN, esto dañará src_addr y provocará la prueba en cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) Lo que se manifestaría como este rastro de syzkaller: ERROR : KASAN: use-after-free en __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Lectura de tamaño 8 en addr ffff8881546491e0 por tarea syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 No contaminado 5.12.0-rc8-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack+0x141/0x1d7 lib /dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [en línea] kasan_report.cold+0x7c/0xd8 mm/kasan/ report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [en línea] list_add_tail include/linux/list.h:100 [en línea] cma_listen_on_all drivers/infiniband/core/ cma.c:2557 [en línea] rdma_listen+0x787/0xe00 controladores/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 controladores/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 controladores/infiniband/core /ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Entry_SYSCALL_64_after_hwframe+0x44/ 0xae Esto indica que un rdma_id_private fue destruido sin realizar cma_cancel_listens(). En lugar de intentar reutilizar la memoria src_addr para crear indirectamente cualquier dirección derivada del dst, cree una explícitamente en la pila y vincúlela como lo haría cualquier otro flujo normal. rdma_bind_addr() lo copiará sobre src_addr una vez que sepa que el estado es válido. Esto es similar al commit bc0bdc5afaa7 ("RDMA/cma: No cambiar route.addr.src_addr.ss_family")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: elimina la advertencia en el commit de transacción cuando se usa fluoncommit Cuando se usa la opción de montaje fluoncommit, durante casi cada commit de transacción activamos una advertencia de __writeback_inodes_sb_nr(): $ cat fs/fs -writeback.c: (...) vacío estático __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (... ) La traza producida en dmesg se parece a la siguiente: [947.473890] ADVERTENCIA: CPU: 5 PID: 930 en fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Módulos vinculados en: nfsd nls_cp437 cifs asn1_decoder s_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti No contaminado 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: __writeback_inodes_sb_nr +0x7e/0xb3 [947.502097] Código: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 X: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP : ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 00000000000000002 R11: 0000000000000001 R12: ffff88810096 3488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40 000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e 0 [947.571072] Seguimiento de llamadas: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? Schedule_timeout+0x8a/0xdd [947.582716] transacción_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]--- Esto se debe a que comenzamos a usar writeback_inodes_sb() para vaciar delalloc cuando cometer una transacción (cuando se usa -o fluoncommit), para evitar interbloqueos con las operaciones de congelación del sistema de archivos. Este cambio se realizó mediante el commit ce8ea7cc6eb313 ("btrfs: no llame a btrfs_start_delalloc_roots en flowoncommit"). Después de ese cambio, comenzamos a producir esa advertencia y, de vez en cuando, un usuario informa esto ya que la advertencia ocurre con demasiada frecuencia, envía spam a dmesg/syslog y el usuario no está seguro de si esto refleja algún problema que pueda comprometer la confiabilidad del sistema de archivos. No podemos simplemente bloquear el semáforo sb->s_umount antes de llamar a writeback_inodes_sb(), porque eso al menos bloquearía el sistema de archivos, ya que en fs/super.c:freeze_super() se llama a sync_filesystem() mientras mantenemos ese semáforo en modo de escritura, y eso puede desencadenar un commit de transacción, lo que resulta en un punto muerto. También desencadenaría el mismo tipo de punto muerto en la ruta de desmontaje. Posiblemente, también podría introducir algunas otras dependencias de bloqueo que lockdep informaría. Para solucionar este problema, llame a try_to_writeback_inodes_sb() en lugar de writeback_inodes_sb(), porque intentará leer el bloqueo sb->s_umount y luego solo llamará a writeback_inodes_sb() si pudo bloquearlo. Esto está bien porque los casos en los que no puede leer el bloqueo sb->s_umount son durante un desmontaje del sistema de archivos o durante una congelación del sistema de archivos; en esos casos, sb->s_umount está bloqueado contra escritura y se llama a sync_filesystem(), que llama a writeback_inodes_sb() . En otras palabras, en todos los casos en los que no podemos adoptar un bloqueo de lectura en sb->s_umount, la reescritura ya se está activando en otro lugar. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: elemento de trabajo de reinicio gratuito al vaciar Se corrige una pequeña pérdida de memoria al vaciar la cola de trabajo de reinicio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: establece correctamente el tiempo de espera de DATA_FIN cuando el número de retransmisiones es grande Syzkaller con UBSAN descubrió un escenario en el que una gran cantidad de retransmisiones de DATA_FIN provocaban un desplazamiento fuera de los límites en el tiempo de espera de DATA_FIN cálculo: =================================================== ================================ UBSAN: desplazamiento fuera de los límites en net/mptcp/protocol.c: El exponente de desplazamiento 470:29 32 es demasiado grande para el tipo 'unsigned int' de 32 bits CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Cola de trabajo: eventos mptcp_worker Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack .c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 __mptcp_retrans.cold+0x7 2/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 Process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 trabajador_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4 /0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ====================== ==================================================== ========= Este cambio limita el tiempo de espera máximo al limitar el tamaño del turno, lo que mantiene todos los valores intermedios dentro de los límites.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: auxdisplay: lcd2s: corrige la pérdida de memoria en ->remove() Una vez asignada, la estructura lcd2s_data nunca se libera. Solucione la pérdida de memoria cambiando a devm_kzalloc().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: arcnet: com20020: corrija null-ptr-deref en com20020pci_probe() Durante la inicialización del controlador, se requiere el puntero de información de la tarjeta, es decir, la variable 'ci'. Sin embargo, la definición de 'com20020pci_id_table' revela que este campo está vacío para algunos dispositivos, lo que provocará una desreferencia del puntero nulo al inicializar estos dispositivos. El siguiente registro lo revela: [3.973806] KASAN: null-ptr-deref en el rango [0x0000000000000028-0x000000000000002f] [3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_p ci] [3.975181] Seguimiento de llamadas: [3.976208] local_pci_probe+0x13f /0x210 [3.977248] pci_device_probe+0x34c/0x6d0 [3.977255]? pci_uevent+0x470/0x470 [3.978265] very_probe+0x24c/0x8d0 [3.978273] __driver_probe_device+0x1b3/0x280 [3.979288] driver_probe_device+0x50/0x370 Solucione este problema comprobando primero si el 'ci' es un puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: reparar fuga de conexión Hay un posible problema de fuga en la siguiente secuencia de ejecución: smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // luego espera el par cerrado Desafortunadamente, tcp_abort() puede descartar los mensajes CLC CONFIRM que todavía están en el búfer de envío tcp , en cuyo caso nuestro token de conexión no se puede entregar al lado del servidor, lo que significa que no podemos recibir ningún mensaje de cierre pasivo. Por lo tanto, es imposible desconectarlo en absoluto. Este parche intenta una forma muy sencilla de evitar este problema, una vez que el estado ha cambiado a SMC_ACTIVE después de tcp_abort(), podemos cancelar activamente la conexión smc, considerando que el estado es SMC_INIT antes de tcp_abort(), abandonar el proceso de desconexión completo no debería causar demasiado problema. De hecho, este problema puede existir siempre y cuando el servidor no reciba el mensaje CONFIRM CLC. En el futuro se deberá discutir si se debe agregar un temporizador después de smc_close_final(). Pero aun así, este parche proporciona una liberación más rápida para la conexión. En el caso anterior, también debería ser valioso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv6: asegúrese de llamar a ipv6_mc_down() como máximo una vez. Hay dos razones para llamar a addrconf_notify() con NETDEV_DOWN: o el dispositivo de red realmente está cayendo o IPv6 estaba deshabilitado en la interfaz. Si alguno de ellos permanece inactivo mientras el otro está activado, llamamos repetidamente al código para NETDEV_DOWN, incluido ipv6_mc_down(), pero nunca llamamos al ipv6_mc_up() correspondiente en el medio. Esto hará que se asigne una nueva entrada en idev->mc_tomb para cada grupo de multidifusión al que esté suscrita la interfaz, lo que a su vez filtrará una estructura ifmcaddr6 por cada grupo de multidifusión no trivial al que esté suscrita la interfaz. El siguiente reproductor filtrará al menos $n objetos: ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); configurar el enlace ip eth0; ip link set down eth0 done Unirse a grupos con IPV6_ADD_MEMBERSHIP (sin privilegios) o configurar sysctl net.ipv6.conf.eth0.forwarding en 1 (=> suscribirse a ff02::2) también se puede usar para crear un idev->mc_list no trivial , que filtrará objetos con la secuencia correcta de arriba a abajo. Según ambas fuentes de eventos NETDEV_DOWN, se debe considerar el estado de la interfaz IPv6: - no lista si la interfaz de red no está lista O IPv6 está deshabilitado - lista si la interfaz de red está lista Y IPv6 está habilitada Las funciones ipv6_mc_up() e ipv6_down() solo debe ejecutarse cuando este estado cambie. Implemente esto recordando cuándo el estado de IPv6 está listo y solo ejecute ipv6_mc_down() si realmente cambió de listo a no listo. La otra dirección (no listo -> listo) ya funciona correctamente, ya que: - la ruta de código activada de notificación de interfaz para NETDEV_UP / NETDEV_CHANGE regresa antes si ipv6 está deshabilitado, y - la ruta de código activada enable_ipv6=0 omite la inicialización completa de la interfaz siempre que addrconf_link_ready (dev) devuelve falso: llamar a ipv6_mc_up() repetidamente no filtra nada

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_queue: corrige posible use-after-free Eric Dumazet dice: El lado sock_hold() parece sospechoso, porque no hay garantía de que sk_refcnt no sea ya 0. En caso de falla, No podemos poner en cola el paquete y necesitamos indicar un error. La persona que llama descartará el paquete. v2: dividir el fragmento de captación previa de skb en un cambio separado

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: corrige el use-after-free en __nf_register_net_hook() No debemos eliminar la referencia a @new_hooks después de que se haya lanzado nf_hook_mutex, porque es posible que otros subprocesos ya hayan liberado nuestros ganchos asignados. ERROR: KASAN: use-after-free en nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [en línea] ERROR: KASAN: use-after-free en ganchos_validate net/netfilter/core.c:171 [en línea] ERROR: KASAN: use-after-free en __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438 Lectura de tamaño 2 en la dirección ffff88801c1a8000 por tarea syz-executor237/4430 CPU: 1 PID: 4430 Comm: syz-executor237 No contaminado 5.17.0 -rc5-syzkaller-00306-g2293be58d6a1 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/ 0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [en línea] kasan_report.cold+0x83/0xdf mm/ kasan/report.c: 459 nf_hook_entries_get_hook_ops include/linux/netfilter.h: 130 [inline] gooks_validate net/netfilter/core.c: 171 [inline] __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c: 438 nf_net_hook+0x77a/0x820 net/netfilter/core.c: 438 nf_net_hook+0x77a/0x820 net/netfilter/core.c: 438 nfhhook_net_net+0x11 /0x170 net/netfilter/core.c:571 nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587 nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218 synproxy_tg6_check+0x30d/0x560 ipv6/filtro de red/ ip6t_SYNPROXY.c:81 xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038 check_target net/ipv6/netfilter/ip6_tables.c:530 [en línea] find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables .c:573 traducir_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735 do_replace net/ipv6/netfilter/ip6_tables.c:1153 [en línea] do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c: 1639 nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101 ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024 rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084 ys_setsockopt+0x2db/0x610 neto/ socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [en línea] __se_sys_setsockopt net/socket.c:2188 [en línea] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188 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:0x7f65a1ace7d9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 1 15 00 00 90 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 B8 FF FF FF F7 D8 64 89 01 48 RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00000000000000006 RCX: 00007f65a1ace7d9 RDX: 00000040 RSI: 0000000000000029 RDI: 0000000000000003 RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 000000000000000 R10: 000000002 0000000 R11: 0000000000000246 R12: 00007f65a1b55130 R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000 La dirección del error pertenece a la página: página:ffffea0000706a00 refcount:0 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x1c1a8 flags: 0xfff000000 00000(nodo=0|zona=1|lastcpupid=0x7ff) crudo: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000 crudo: 0000000000000000 00000000000000000 00000000ffffffff 00000000000 00000 página volcada porque: kasan: mal acceso detectado page_owner rastrea la página como página liberada asignada por última vez mediante orden 2, migrar tipo Inamovible, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO) , pid 4430, ts 1061781545818, free_ts 1061791488993 prep_new_page mm/page_alloc.c:2434 [en línea] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blktrace: corrige el use after free para struct blk_trace Al rastrear todo el disco, se crearán 'dropped' y 'msg' en 'q->debugfs_dir' y 'bt->dir ' es NULL, por lo tanto blk_trace_free() no eliminará esos archivos. Lo que es peor, el siguiente UAF se puede activar debido al acceso a 'soltado' y 'msg' obsoletos: ============================== ===================================== ERROR: KASAN: use after free en blk_dropped_read+0x89 /0x100 Lectura de tamaño 4 en la dirección ffff88816912f3d8 por tarea blktrace/1188 CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) , BIOS ?-20190727_073836-4 Seguimiento de llamadas: dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xab/0x381 ? blk_dropped_read+0x89/0x100? blk_dropped_read+0x89/0x100 kasan_report.cold+0x83/0xdf ? blk_dropped_read+0x89/0x100 kasan_check_range+0x140/0x1b0 blk_dropped_read+0x89/0x100 ? blk_create_buf_file_callback+0x20/0x20? kmem_cache_free+0xa1/0x500 ? do_sys_openat2+0x258/0x460 full_proxy_read+0x8f/0xc0 vfs_read+0xc6/0x260 ksys_read+0xb9/0x150 ? vfs_write+0x3d0/0x3d0? fpregs_assert_state_consistent+0x55/0x60? exit_to_user_mode_prepare+0x39/0x1e0 do_syscall_64+0x35/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fbc080d92fd Código: ce 20 00 00 75 10 b8 00 00 00 00 0f 5 48 3d 01 f0 ff ff 73 31 c3 48 83 1 RSP: 002b :00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd RDX: 0000000000000100 R SI: 00007fbb95ff9cc0 RDI: 0000000000000045 RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd R10: 000000000153afa0 R11: 000000000293 R12: 00007fbb780008c0 R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8 Asignado por tarea 1050: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 do_blk_trace_setup+0xcb/0x410 __blk_trace_setup+0xac/0x130 e9/0x1c0 blkdev_ioctl+0xf1/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35 /0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae Liberado por la tarea 1050: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x103/0x180 kfree+0x9a/0x4c 0 __blk_trace_remove+0x53/0x70 blk_trace_ioctl+0x199/0x1c0 blkdev_common_ioctl+0x5e9 /0xb30 blkdev_ioctl+0x1a5/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae La dirección con errores pertenece al objeto en ffff88816912f380 que pertenece al caché kmalloc- 96 de tamaño 96 La dirección del error se encuentra 88 bytes dentro de región de 96 bytes [ffff88816912f380, ffff88816912f3e0) La dirección con errores pertenece a la página: página:000000009a1b4e7c refcount:1 mapcount:0 mapeo:00000000000000000 índice:0x0f banderas: 0x17ffffc0000200(slab|node= 0|zona=2|últimopupid=0x1fffff ) sin procesar: 0017ffffc0000200 ffffea00044f1100 muerto000000000002 ffff88810004c780 sin procesar: 0000000000000000 0000000000200020 00000001ffffffff 000000000000 0000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc =============================== =======================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/netfront: destruye colas antes de que real_num_tx_queues se ponga a cero xennet_destroy_queues() se basa en info->netdev->real_num_tx_queues para eliminar colas. Dado que d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: actualice los recuentos de colas en la ruta de cancelación de registro"), unregister_netdev() establece indirectamente real_num_tx_queues en 0. Esos dos hechos juntos significan que xennet_destroy_queues() llamado desde xennet_remove() no puede hacer su trabajo, porque s llamado después de unregister_netdev(). Esto da como resultado colas kfree-ing que todavía están vinculadas en napi, lo que finalmente falla: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - PGD de página no presente 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: GW 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Código: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 0 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 00000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 00000000000000000 R15: ffff8880066c6680 FS: 00000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: CR3: 00000000e998c006 CR4: 00000000003706e0 Seguimiento de llamadas: xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/ 0x30 bus_remove_device+0xd8/0x140 dispositivo_del+0x18b/0x410? _raw_spin_unlock+0x16/0x30? klist_iter_exit+0x14/0x20? xenbus_dev_request_and_reply+0x80/0x80 dispositivo_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Solucione este problema llamando a xennet_destroy_queues() desde xennet_uninit(), cuando real_num_tx_queues todavía esté disponible. Esto garantiza que las colas se destruyan cuando real_num_tx_queues se establece en 0, independientemente de cómo se llamó a unregister_netdev(). Reportado originalmente en https://github.com/QubesOS/qubes-issues/issues/7257