Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: mm: No llamar a pmd dtor en el desmontaje de la tabla de páginas vmemmap Las tablas de páginas vmemmap, que se utilizan para RV64 con SPARSEMEM_VMEMMAP, se rellenan utilizando enormes tablas pmd (directorio intermedio de páginas). Sin embargo, la asignación de pmd no utiliza el mecanismo genérico utilizado por el código VMA (por ejemplo, pmd_alloc()), o el create_pgd_mapping()/alloc_pmd_late() específico de RISC-V. En su lugar, el código de la tabla de páginas vmemmap asigna una página y llama a vmemmap_set_pmd(). Esto da como resultado que el pmd ctor *no* se llame, ni tendría sentido hacerlo. Ahora, al desmantelar un pmd de la tabla de páginas vmemmap, el código de desinfección llamaría incondicional e incorrectamente al pmd dtor, lo que da como resultado un bloqueo (en el mejor de los casos). Este problema se encontró al ejecutar las autopruebas de HMM: | herramientas/pruebas/autopruebas/mm# ./test_hmm.sh smoke | ... # al descargar el módulo test_hmm.ko | página: refcount:1 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0x10915b | banderas: 0x1000000000000000(nodo=0|zona=1) | crudo: 1000000000000000 0000000000000000 dead0000000000122 0000000000000000 | raw: 0000000000000000 000000000000000 00000001ffffffff 0000000000000000 | página volcada porque: VM_BUG_ON_PAGE(ptdesc->pmd_huge_pte) | ------------[ cortar aquí ]------------ | ¡ERROR del kernel en include/linux/mm.h:3080! | ERROR del kernel [#1] | Módulos vinculados en: test_hmm(-) sch_fq_codel fuse drm drm_panel_orientation_quirks backlight dm_mod | CPU: 1 UID: 0 PID: 514 Comm: modprobe Contaminado: GW 6.12.0-00982-gf2a4f1682d07 #2 | Contaminado: [W]=WARN | Nombre del hardware: riscv-virtio qemu/qemu, BIOS 2024.10 10/01/2024 | epc : remove_pgd_mapping+0xbec/0x1070 | ra : remove_pgd_mapping+0xbec/0x1070 | epc : ffffffff80010a68 ra : ffffffff80010a68 sp : ff20000000a73940 | gp : ffffffff827b2d88 tp : ff6000008785da40 t0 : ffffffff80fbce04 | t1: 0720072007200720 t2: 706d756420656761 s0: ff20000000a73a50 | s1: ff6000008915cff8 a0: 0000000000000039 a1: 00000000000000008 | a2: ff600003fff0de20 a3: 0000000000000000 a4: 0000000000000000 | a5: 0000000000000000 a6: c0000000fffffff a7: ffffffff824469b8 | s2: ff1c0000022456c0 s3: ff1ffffffdbfffff s4: ff6000008915c000 | s5: ff6000008915c000 s6: ff6000008915c000 s7: ff1ffffffdc00000 | s8: 0000000000000001 s9: ff1ffffffdc00000 s10: ffffffff819a31f0 | s11: ffffffffffffffff t3: ffffffff8000c950 t4: ff60000080244f00 | t5 : ff60000080244000 t6 : ff20000000a73708 | estado: 0000000200000120 dirección incorrecta: ffffffff80010a68 causa: 0000000000000003 | [] eliminar_map_pgd+0xbec/0x1070 | [] vmemmap_free+0x14/0x1e | [] desactivar_sección+0x220/0x452 | [] eliminar_sección_sparse+0x4a/0x58 | [] __eliminar_páginas+0x7e/0xba | [] memunmap_páginas+0x2bc/0x3fe | [] dmirror_dispositivo_eliminar_fragmentos+0x2ea/0x518 [prueba_hmm] | [] hmm_dmirror_exit+0x3e/0x1018 [prueba_hmm] | [] __riscv_sys_eliminar_módulo+0x15a/0x2a6 | [] do_trap_ecall_u+0x1f2/0x266 | [] _new_vmalloc_restore_context_a0+0xc6/0xd2 | Código: bf51 7597 0184 8593 76a5 854a 4097 0029 80e7 2c00 (9002) 7597 | ---[ fin del seguimiento 000000000000000 ]--- | Pánico del kernel - no sincroniza: Excepción fatal en la interrupción Agregue una verificación para evitar llamar al dtor pmd, si el contexto de llamada es vmemmap_free().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: punto de invocación correcto de netdev_tx_reset_queue() Cuando virtnet_close es seguido por virtnet_open, es posible que algunas finalizaciones de TX permanezcan sin consumir, hasta que finalmente se procesen durante el primer sondeo NAPI después de netdev_tx_reset_queue(), lo que resulta en un bloqueo [1]. el commit b96ed2c97c79 ("virtio_net: mover la llamada netdev_tx_reset_queue() antes de la habilitación de napi RX") no fue suficiente para eliminar todos los casos de bloqueo de BQL para virtio-net. Este problema se puede reproducir con el último maestro net-next ejecutando: `while :; do ip l set DEV down; ip l set DEV up; done` bajo una carga de TX de red pesada desde el interior de la máquina. netdev_tx_reset_queue() en realidad se puede eliminar de la ruta virtnet_open; el dispositivo no se detiene en ningún caso. Para la parte principal de BQL, es como si el tráfico casi dejara de existir durante un período. Para el detector de bloqueo agregado a BQL, incluso si virtnet_close pudiera de alguna manera provocar que algunas finalizaciones de TX se retrasaran durante mucho tiempo, seguido de virtnet_open, podemos simplemente tomarlo como un bloqueo como se menciona en el commit 6025b9135f7a ("net: dqs: agregar detector de bloqueo de NIC basado en BQL"). Tenga en cuenta también que los usuarios aún pueden restablecer stall_max a través de sysfs. Por lo tanto, elimine netdev_tx_reset_queue() de virtnet_enable_queue_pair(). Esto elimina los bloqueos de BQL. Como resultado, netdev_tx_reset_queue() ahora se requiere explícitamente en la ruta de congelamiento/restauración. Este parche lo agrega inmediatamente después de free_unused_bufs(), siguiendo la regla general: netdev_tx_reset_queue() debe seguir cualquier liberación de SKB no seguida por netdev_tx_completed_queue(). Este parece ser el enfoque más consistente y optimizado, y ahora netdev_tx_reset_queue() se ejecuta siempre que se realiza free_unused_bufs(). [1]: ------------[ corte aquí ]------------ ¡ERROR del kernel en lib/dynamic_queue_limits.c:99! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Contaminado: GN 6.12.0net-next_main+ #2 Contaminado: [N]=TEST Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 Código: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 00000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Rastreo de llamadas: ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? __actualizar_carga_avg_cfs_rq+0x264/0x2d0 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arreglar UAF a través de la falta de coincidencia de los sabores de RCU de bpf_prog/attachment Los uprobes siempre usan bpf_prog_run_array_uprobe() bajo la protección de tareas-trace-RCU. Pero es posible adjuntar un programa BPF no durmiente a un uprobe, y los programas BPF no durmientes se liberan a través de RCU normal (ver __bpf_prog_put_noref()). Esto lleva a UAF de bpf_prog porque un período de gracia de RCU normal no implica un período de gracia de tareas-trace-RCU. Arréglelo esperando explícitamente un período de gracia de tareas-trace-RCU después de eliminar la conexión de un bpf_prog a un perf_event.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrige UAF en blkcg_unpin_online() blkcg_unpin_online() sube por la jerarquía blkcg y coloca el pin en línea. Para subir, usa blkcg_parent(blkcg) pero lo estaba llamando después de blkcg_destroy_blkgs(blkcg) que podría liberar el blkcg, lo que lleva al siguiente UAF: ====================================================================== ERROR: KASAN: slab-use-after-free en blkcg_unpin_online+0x15a/0x270 Lectura de tamaño 8 en la dirección ffff8881057678c0 por la tarea kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 No contaminado 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS desconocido 02/02/2022 Cola de trabajo: cgwb_release cgwb_release_workfn Seguimiento de llamadas: dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 ... Liberado por la tarea 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Tenga en cuenta que el UAF no es fácil de activar ya que la ruta libre es Se produjo un error indirecto detrás de un par de períodos de gracia de RCU y una ejecución de elemento de trabajo. Solo pude activarlo con msleep() artificial inyectado en blkcg_unpin_online(). Solucione el problema leyendo el puntero principal antes de destruir los blkg de blkcg.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Desreferenciar valor de retorno nulo En la función pqm_uninit hay una asignación de llamada de "pdd = kfd_get_process_device_data" que podría ser nulo, y este valor fue posteriormente desreferenciado sin verificación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: Se corrige la desreferencia de puntero NULL en capture_engine Cuando la estructura intel_context contiene NULL, genera un error de desreferencia de puntero NULL en drm_info(). (seleccionado de el commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Arreglar el puntero NULL de qi_batch con el dominio principal anidado El qi_batch se asigna al asignar la etiqueta de caché para un dominio. Mientras que para el dominio principal anidado, se omite. Por lo tanto, al intentar asignar páginas al principal anidado, se produjo una desreferencia NULL. Además, existe una posible fuga de memoria ya que no hay un bloqueo alrededor de la asignación de dominio->qi_batch. Para resolverlo, agregue un ayudante para la asignación de qi_batch y llámelo tanto en __cache_tag_assign_domain() como en __cache_tag_assign_parent_domain(). ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000200 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 8104795067 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 No contaminado 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632 Seguimiento de llamadas: ? __die+0x24/0x70 ? page_fault_oops+0x80/0x150 ? do_user_addr_fault+0x63/0x7b0 ? exc_page_fault+0x7c/0x220 ? asm_exc_page_fault+0x26/0x30 ? rango_de_vaciado_de_etiqueta_de_caché_np+0x13c/0x260 intel_iommu_iotlb_sync_map+0x1a/0x30 iommu_map+0x61/0xf0 lote_a_dominio+0x188/0x250 iopt_area_fill_domains+0x125/0x320 ? iopt_map_pages+0x63/0x100 iopt_map_common.isra.0+0xa7/0x190 iopt_map_user_pages+0x6a/0x80 iommufd_ioas_map+0xcd/0x1d0 iommufd_fops_ioctl+0x118/0x1c0 __x64_sys_ioctl+0x93/0xc0 hacer_syscall_64+0x71/0x140 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: eliminar etiquetas de caché antes de deshabilitar ATS La implementación actual elimina las etiquetas de caché después de deshabilitar ATS, lo que genera posibles fugas de memoria y fallas del kernel. Específicamente, las etiquetas de caché de tipo CACHE_TAG_DEVTLB pueden permanecer en la lista incluso después de que se libere el dominio, lo que provoca una condición de use-after-free. Este problema realmente aparece cuando múltiples VF de diferentes PF pasan a un solo proceso de espacio de usuario a través de vfio-pci. En tales casos, el núcleo puede bloquearse con mensajes como: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli No contaminado 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Rastreo de llamadas: ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ? asm_exc_page_fault+0x22/0x30 ? rango_de_desinfección_de_etiquetas_de_caché+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250 intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0 vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] Mueva cache_tag_unassign_domain() antes de iommu_disable_pci_caps() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: graniterapids: Corregir fallo del controlador vGPIO Mover la configuración irq_chip.name de la función probe() a la inicialización de la estructura "irq_chip" para corregir el fallo del controlador vGPIO durante el arranque. El fallo fue causado por una modificación no autorizada del campo irq_chip.name donde la estructura irq_chip se inicializó como const. Este comportamiento es una consecuencia de la implementación subóptima de gpio_irq_chip_set_chip(), que debería cambiarse para evitar descartar el calificador const. Registro de fallos: ERROR: no se puede gestionar el error de página para la dirección: ffffffffc0ba81c0 /#PF: acceso de escritura del supervisor en modo kernel /#PF: error_code(0x0003) - violación de permisos CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd No contaminado 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Nombre del hardware: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: nfit: vmalloc-out-of-bounds Lectura en acpi_nfit_ctl Se soluciona un problema detectado por syzbot con KASAN: ERROR: KASAN: vmalloc-out-of-bounds en cmd_to_func drivers/acpi/nfit/ core.c:416 [en línea] ERROR: KASAN: vmalloc-out-of-bounds en acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 El problema ocurre en cmd_to_func cuando se accede a la matriz call_pkg->nd_reserved2 sin verificar que call_pkg apunte a un búfer que tenga el tamaño adecuado como una estructura nd_cmd_pkg. Esto puede provocar un acceso fuera de los límites y un comportamiento indefinido si el búfer no tiene suficiente espacio. Para solucionar este problema, se agregó una verificación en acpi_nfit_ctl() para garantizar que buf no sea NULL y que buf_len sea menor que sizeof(*call_pkg) antes de acceder a él. Esto garantiza un acceso seguro a los miembros de call_pkg, incluida la matriz nd_reserved2.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: corrección del error NL80211_ATTR_MLO_LINK_ID en uno Dado que la validación del rango del atributo netlink proporciona una verificación inclusiva, el *máximo* del atributo NL80211_ATTR_MLO_LINK_ID debe ser IEEE80211_MLD_MAX_NUM_LINKS - 1, lo que de lo contrario provocaría un error de uno. Una pila de fallos para demostración: ==================================================================== ERROR: KASAN: acceso a memoria salvaje en ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 Lectura de tamaño 6 en la dirección 001102080000000c por la tarea fuzzer.386/9508 CPU: 1 PID: 9508 Comm: syz.1.386 No contaminado 6.1.70 #2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_report+0xe0/0x750 mm/kasan/report.c:398 kasan_report+0x139/0x170 mm/kasan/report.c:495 kasan_check_range+0x287/0x290 mm/kasan/generic.c:189 memcpy+0x25/0x60 mm/kasan/shadow.c:65 ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 rdev_tx_control_port net/wireless/rdev-ops.h:761 [en línea] nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453 genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756 genl_family_rcv_msg net/netlink/genetlink.c:833 [en línea] genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [en línea] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [en línea] __sock_sendmsg net/socket.c:728 [en línea] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [en línea] __do_sys_sendmsg net/socket.c:2591 [en línea] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd Actualice la política para garantizar una validación correcta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la competencia entre el reemplazo de elementos y close(). El reemplazo de elementos (con un socket diferente del almacenado) puede competir con el enlace de close() del socket, haciendo estallar y desvinculando el enlace. __sock_map_delete() anula la referencia incondicional del elemento (incorrecto): // establece map[0] = s0 map_update_elem(map, 0, s0) // elimina fd de s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // reemplaza map[0] con s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) si (conteo_de_referencias_y_pruebas(&psock)) sk_psock_drop(sk, psock) desbloqueo_spin(&stab->bloqueo) desbloqueo_sock(sk) __sock_map_delete bloqueo_spin(&stab->bloqueo) sk = *psk // s1 reemplazó a s0; sk == s1 si (!sk_prueba || sk_prueba == sk) // sk_prueba (s0) != sk (s1); sin rama sk = xchg(psk, NULL) si (sk) sock_map_unref(sk, psk) // desreferenciar s1; sks[idx] dejará colgado psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Luego close(map) pone en cola bpf_map_free_deferred, que finalmente llama a sock_map_free(). Esto da como resultado algunas advertencias refcount_t junto con un splat KASAN [1]. Corrija __sock_map_delete(), no permita sock_map_unref() en elementos que pueden haber sido reemplazados. [1]: ERROR: KASAN: slab-use-after-free en sock_map_free+0x10e/0x330 Escritura de tamaño 4 en la dirección ffff88811f5b9100 por la tarea kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 No contaminado 6.12.0+ #125 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Cola de trabajo: events_unbound bpf_map_free_deferred Rastreo de llamadas: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 Asignado por la tarea 1202: pila de guardado kasan+0x1e/0x40 seguimiento de guardado kasan+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 La librería ---truncada---