Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal: Core: corrige la desreferencia del puntero TZ_GET_TRIP NULL No llame a get_trip_hyst() desde Thermal_genl_cmd_tz_get_trip() si la zona térmica no define una.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: se corrige el doble list_add al habilitar VMD en modo escalable Al habilitar VMD e IOMMU en modo escalable, se muestra el siguiente registro de kernel/rastreo de llamadas de pánico del kernel en la plataforma Eagle Stream (CPU Sapphire Rapids) durante el arranque: pci 0000:59:00.5: Agregar al grupo iommu 42... vmd 0000:59:00.5: Puente de host PCI al bus 10000:80 pci 10000:80:01.0: [8086:352a] tipo 01 clase 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: habilitación de etiquetas extendidas pci 10000:80:01.0: PME# compatible desde D0 D3hot D3cold pci 10 000:80: 01.0: DMAR: La configuración de RID2PASID falló pci 10000:80:01.0: No se pudo agregar al grupo iommu 42: -16 pci 10000:80:03.0: [8086:352b] tipo 01 clase 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64 bits] pci 10000:80:03.0: habilitación de etiquetas extendidas pci 10000:80:03.0: PME# admitido desde D0 D3hot D3cold ------------[ cortar aquí ]--- --------- ¡ERROR del kernel en lib/list_debug.c:29! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Nombre del hardware: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/ Cola de trabajo 2022: eventos work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Código: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 00000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: 888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Llamar Seguimiento: intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0 x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x 820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 proceso_one_work +0x1e2/0x3b0 hilo_trabajador+0x1c4/0x3a0 ? hilo_rescate+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 módulos vinculados en: --- [end rastre 0xffffffff80000000-0xffffffffbffffff) ---[ fin del pánico del kernel - no se sincroniza: excepción grave ]--- La siguiente salida 'lspci' muestra que los dispositivos '10000:80:*' son subdispositivos del dispositivo VMD 0000:59:00.5: $ lspci ... 0000:59:00.5 Controlador de bus RAID: Dispositivo de administración de volumen Intel Corporation Controlador RAID NVMe (rev. 20) ... 10000:80:01.0 Puente PCI: Dispositivo Intel Corporation 352a (rev. 03) 10000:80:03.0 Puente PCI : Dispositivo Intel Corporation 352b (rev 03) 10000:80:05.0 Puente PCI: Dispositivo Intel Corporation 352c (rev 03) 10000:80:07.0 Puente PCI: Dispositivo Intel Corporation 352d (rev 03) 10000:81:00.0 Memoria no volátil controlador: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Shift valores probados en snd_soc_put_volsw() por +min Mientras que los valores $val/$val2 pasados desde el espacio de usuario son siempre >= 0 enteros, los límites del control pueden ser números enteros con signo y $min puede ser distinto de cero y menor que cero. Para validar correctamente $val/$val2 contra platform_max, primero agregue el desplazamiento $min a val.