Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: wacom: corrección de fallo en wacom_aes_battery_handler(). El commit fd2a9b29dc9c ("HID: wacom: Eliminar la fuente de alimentación AES tras una inactividad prolongada") introdujo wacom_aes_battery_handler(), que está programado como un trabajo retrasado (aes_battery_work). En wacom_remove(), aes_battery_work no se cancela. Por lo tanto, si se retira el dispositivo mientras aes_battery_work está pendiente, se producen fallos graves o el error "Uy: fallo de protección general..." al ejecutar wacom_aes_battery_handler(). Por ejemplo, esto ocurre con dispositivos USB integrados tras la reanudación de la hibernación cuando aes_battery_work estaba pendiente en ese momento. Por lo tanto, tenga cuidado de cancelar aes_battery_work en wacom_remove().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/ras: Corregir confusión de dispositivo del controlador CPER Por inspección, cxl_cper_handle_prot_err() está haciendo una serie de suposiciones frágiles que pueden llevar a caídas: 1/ Supone que los endpoints identificados en el registro son un dispositivo CXL-type-3, nada lo garantiza. 2/ Supone que el dispositivo está enlazado al controlador cxl_pci, nada lo garantiza. 3/ Leve, mantiene el bloqueo del dispositivo sobre el seguimiento del puerto del conmutador sin ninguna razón ya que el seguimiento se genera 100% a partir de los datos en el registro. Corrija aquellos comprobando que el endpoint PCIe engendre un cxl_memdev antes de asumir el formato de los datos del controlador y mueva el bloqueo a donde se requiere. En consecuencia, esto también hace que la implementación esté lista para aceleradores CXL que no están enlazados a cxl_pci.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pkey: Evitar el desbordamiento en el cálculo del tamaño para memdup_user() El número de entradas de la lista de destino apqn contenidas en la variable 'nr_apqns' está determinado por el espacio de usuario a través de una llamada ioctl, por lo que el resultado del producto en el cálculo del tamaño pasado a memdup_user() puede desbordarse. En este caso, el tamaño real del área asignada y el valor que lo describe no estarán sincronizados, lo que provocará varios tipos de comportamiento impredecible más adelante. Utilice un ayudante memdup_array_user() adecuado que devuelva un error si se detecta un desbordamiento. Tenga en cuenta que es diferente de cuando nr_apqns es inicialmente cero: ese caso se considera válido y debe manejarse en implementaciones posteriores de pkey_handler. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: previene la deref NULL en clip_push(). El commit responsable no detectó que vcc_destroy_socket() llama a clip_push() con un skb NULL. Si clip_devs es NULL, clip_push() se bloquea al leer skb->truesize.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Corregir lectura fuera de los límites en snd_usb_get_audioformat_uac3() En snd_usb_get_audioformat_uac3(), el valor de longitud devuelto por snd_usb_ctl_msg() se usa directamente para la asignación de memoria sin validación. Esta longitud la controla el dispositivo USB. El búfer asignado se convierte a un uac3_cluster_header_descriptor y se accede a sus campos sin verificar que el búfer sea lo suficientemente grande. Si el dispositivo devuelve una longitud menor de la esperada, esto conduce a una lectura fuera de los límites. Añada una comprobación de longitud para garantizar que el búfer sea lo suficientemente grande para uac3_cluster_header_descriptor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_core: Se corrige el use-after-free en vhci_flush() syzbot informó use-after-free en vhci_flush() sin reproducción. [0] Desde el splat, un subproceso cierra() un descriptor de archivo vhci mientras su dispositivo estaba siendo usado por iotcl() en otro subproceso. Una vez que se libera el último fd refcnt, vhci_release() llama a hci_unregister_dev(), hci_free_dev() y kfree() para struct vhci_data, que está configurado en hci_dev->dev->driver_data. El problema es que no hay sincronización después de desvincular hdev de hci_dev_list en hci_unregister_dev(). Podría haber otro subproceso que aún acceda al hdev que se obtuvo antes de la operación de desvinculación. Podemos usar SRCU para dicha sincronización. Ejecutemos hci_dev_reset() en SRCU y esperemos a que se complete en hci_unregister_dev(). Otra opción sería restaurar hci_dev->destruct(), que se eliminó en el commit 587ae086f6e4 ("Bluetooth: Eliminar el bloque de comandos hci-destruct no utilizado"). Sin embargo, esta no sería una buena solución, ya que no deberíamos ejecutar hci_unregister_dev() mientras haya solicitudes ioctl() en curso, lo que podría provocar otro error de KCSAN en la ejecución de datos. Tenga en cuenta que otros controladores parecen tener el mismo problema, por ejemplo, virtbt_remove(). [0]: ERROR: KASAN: slab-use-after-free en skb_queue_empty_lockless include/linux/skbuff.h:1891 [en línea] ERROR: KASAN: slab-use-after-free en skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Lectura de tamaño 8 en la dirección ffff88807cb8d858 por la tarea syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 No contaminado 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de desreferencias de punteros inodos no válidos durante la reproducción de registros. En algunos casos, al ejecutar read_one_inode(), si se obtiene un puntero nulo, se accede a una ruta de error o a una ruta de paso en el caso de __add_inode_ref(). En este caso, se realiza algo como: iput(&inode->vfs_inode);, lo que genera un puntero inodo no válido que desencadena un acceso no válido a memoria y provoca un fallo. Para solucionar esto, es necesario asegurarse de no realizar dichas desreferencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: userfaultfd: corrige la ejecución de userfaultfd_move y la caché de intercambio. Esta confirmación corrige dos tipos de ejecuciones, pueden tener resultados diferentes: Barry informó un BUG_ON en el commit c50f8e6053b0, podemos ver el mismo BUG_ON si la búsqueda del mapa de archivos devolvió NULL y folio se agrega a la caché de intercambio después de eso. Si se activa otro tipo de ejecución (folio modificado tras la búsqueda), es posible que el contador RSS esté dañado: [406.893936] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_ANONPAGES val:-1 [406.894071] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_SHMEMPAGES val:1 Porque el folio se está contabilizando en la VMA incorrecta. No estoy seguro de si habrá alguna corrupción de datos, aunque parece que no. Los problemas anteriores ya son críticos. Al ver un PTE de entrada de intercambio, userfaultfd_move realiza una búsqueda de caché de intercambio sin bloqueo e intenta mover el folio encontrado a la VMA que falla. Actualmente, se basa en la comprobación del valor de PTE para garantizar que el folio movido siga perteneciendo a la entrada de intercambio src y que no se haya añadido ningún folio nuevo a la caché de intercambio, lo cual resulta poco fiable. Al trabajar y revisar la serie de tablas de intercambio con Barry, se observan y reproducen las siguientes ejecuciones existentes [1]: En el siguiente ejemplo, move_pages_pte mueve src_pte a dst_pte, donde src_pte es una PTE de entrada de intercambio que contiene la entrada de intercambio S1, y S1 no está en la caché de intercambio: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí tiene entrada = S1 ... ... // folio A es un nuevo folio asignado // y se instala en src_pte // src_pte ahora apunta al folio A, S1 // tiene conteo de intercambio == 0, puede liberarse // mediante folio_swap_swap o la recuperación del asignador de intercambio. // folio B es un folio en otro VMA. // S1 se libera, el folio B puede usarlo // para intercambiar sin problemas. ... folio = filemap_get_folio(S1) // ¡¡¡Tengo el folio B aquí!!! ... ... // Ahora S1 está libre para volver a usarse. // Ahora src_pte es una entrada de intercambio PTE // que mantiene S1 de nuevo. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Comprobación aprobada porque src_pte == S1 folio_move_anon_rmap(...) // ¡¡¡Se movió el folio B inválido aquí!!! La ventana de ejecución es muy corta y requiere múltiples colisiones de múltiples eventos raros, por lo que es muy improbable que suceda, pero con un reproductor construido deliberadamente y una ventana de tiempo mayor, se puede reproducir fácilmente. Esto se puede arreglar comprobando si el folio devuelto por filemap es el folio de caché de intercambio válido después de adquirir el bloqueo de folio. Otra ejecución similar es posible: filemap_get_folio puede devolver NULL, pero el folio (A) podría intercambiarse dentro y fuera de nuevo usando la misma entrada de intercambio después de la búsqueda. En tal caso, el folio (A) puede permanecer en el caché de intercambio, por lo que también debe moverse: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí obtuvo entry = S1, y S1 no está en el caché de intercambio folio = filemap_get ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/shmem, swap: corregir bloqueo suave con swapin mTHP El siguiente bloqueo suave se puede reproducir fácilmente en mi máquina de prueba con: echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 es un dispositivo de intercambio de 48G mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true; hacer dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done Luego de un rato: watchdog: BUG: bloqueo suave - ¡CPU#0 bloqueada durante 763 s! [cat:5787] Módulos vinculados: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: cargado Contaminado: GL 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntario)· Contaminado: [L]=SOFTLOCKUP Nombre del hardware: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 ? xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 La razón es simple, la lectura anticipada trajo algún folio de orden 0 en la caché de intercambio y El folio mTHP de intercambio que se está asignando entra en conflicto con él, por lo que swapcache_prepare falla y provoca que shmem_swap_alloc_folio devuelva -EEXIST, y shmem simplemente reintenta una y otra vez, causando este bucle. Se puede solucionar aplicando una solución similar para el intercambio mTHP anónimo. El cambio de rendimiento es muy leve; tiempo de intercambio 10g cero folios con shmem (prueba realizada 12 veces): Antes: 2.47 s Después: 2.48 s [kasong@tencent.com: añadir comentario]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuga de userns y mnt_idmap en open_tree_attr(2). Una vez que want_mount_setattr() ha devuelto un resultado positivo, requiere finish_mount_kattr() para liberar ->mnt_userns. Un fallo en do_mount_setattr() no cambia esto. Como resultado, podemos acabar con fugas de userns y posiblemente también de mnt_idmap.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige un posible bloqueo al reconectar canales Se corrige cifs_signal_cifsd_for_reconnect() para que adopte el orden de bloqueo correcto y evite que se produzca el siguiente bloqueo ========================================================= ADVERTENCIA: se detectó una posible dependencia de bloqueo circular 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt: vaciar correctamente las listas de redireccionamiento de XDP Encontramos el siguiente fallo al probar una característica XDP_REDIRECT en producción: [56251.579676] corrupción de list_add. next->prev debería ser prev (ffff93120dd40f30), pero era ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cortar aquí ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456 ---truncado---