Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Borrar prog->jited_len junto con prog->jited syzbot informó un intento ilegal de copy_to_user() desde bpf_prog_get_info_by_fd() [1] Todavía no hubo reproducción de este error, pero creo que el commit 0aef499f3172 ("mm/usercopy: Detectar desbordamientos de vmalloc") está exponiendo un error anterior en bpf arm64. bpf_prog_get_info_by_fd() analiza prog->jited_len para determinar si la imagen JIT se puede copiar al espacio de usuario. Mi teoría es que syzbot logró obtener un programa donde prog->jited_len se ha establecido en 43, mientras que prog->bpf_func se ha borrado. No está claro por qué copy_to_user(uinsns, NULL, ulen) está activando esta advertencia en particular. Pensé que find_vma_area(NULL) no encontraría un vm_struct. Como no tenemos el bloqueo de giro vmap_area_lock, es posible que el vm_struct encontrado fuera basura. [1] usercopy: ¡Se detectó un intento de exposición de memoria del kernel desde vmalloc (desplazamiento 792633534417210172, tamaño 43)! ¡ERROR del kernel en mm/usercopy.c:101! Error interno: Oops - BUG: 0 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 25002 Comm: syz-executor.1 No contaminado 5.18.0-syzkaller-10139-g8291eaafed36 #0 Nombre del hardware: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 00000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9: 657275736f707865 x8: ffff80000a30c550 x7: ffff80000b773830 x6: ffff80000b773830 x5: 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 00000000000000064 Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [en línea] __check_object_size mm/usercopy.c:252 [en línea] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [en línea] check_copy_size include/linux/thread_info.h:235 [en línea] copia_al_usuario include/linux/uaccess.h:159 [en línea] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5019 [en línea] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invocar_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Código: aa0003e3 d00038c0 91248000 97fff65f (d4210000)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: bgmac: Se corrige la pérdida de recuento de referencias en bcma_mdio_mii_register of_get_child_by_name() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no sea necesario. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Seguimiento: se corrige la función inactiva llamada desde un contexto no válido en el kernel RT Al configurar bootparams="trace_event=initcall:initcall_start tp_printk=1" en la línea de comandos, se llamó a output_printk() y a spin_lock_irqsave() en la adecuación del contexto de interrupción atómica y deshabilitada de irq. En el kernel PREEMPT_RT, estos bloqueos se reemplazan con rt-spinlock sleepable, por lo que se activará la llamada de pila trace. Corríjalo con raw_spin_lock_irqsave cuando PREEMPT_RT y "trace_event=initcall:initcall_start tp_printk=1" estén habilitados. ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempción deshabilitada en: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu: se corrige la posible eliminación de referencias PTR nulas en arm_smmu_device_probe(). Esto provocará una eliminación de referencias PTR nulas al usar 'res', si platform_get_resource() devuelve NULL, por lo que se pasa a usar 'res' después de devm_ioremap_resource() que lo comprobará para evitar la eliminación de referencias PTR nulas. Y se usa devm_platform_get_and_ioremap_resource() para simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mips: cpc: Se corrige la pérdida de recuento de referencias en mips_cpc_default_phys_base. Agregue of_node_put() faltante para liberar el recuento de referencias incrementado por of_find_compatible_node().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: agregar descriptores de acceso para leer/establecer tp->snd_cwnd Tuvimos varios errores a lo largo de los años con código que rompía la suposición de que tp->snd_cwnd es mayor que cero. Últimamente, syzbot informó que se puede activar WARN_ON_ONCE(!tp->prior_cwnd) agregado en el commit 8b8a321ff72c ("tcp: corregir cwnd cero en tcp_cwnd_reduction"), y sin una reproducción tendríamos que dedicar un tiempo considerable a encontrar el error. En lugar de quejarnos demasiado tarde, queremos detectar dónde y cuándo tp->snd_cwnd se establece en un valor ilegal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtl818x: Evitar el uso de colas no inicializadas El uso de colas no existentes puede provocar un pánico en el kernel con tarjetas rtl8180/rtl8185. Ignore la prioridad skb para esas tarjetas, solo tienen una cola tx. Pierre Asselin (pa@panix.com) informó sobre el fallo del kernel en el foro de Gentoo: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html También confirmó que este parche soluciona el problema. En resumen, esto sucedió: Después de actualizar wpa_supplicant de 2.9 a 2.10, el kernel se bloqueó con un "error de división: 0000" al conectarse a un AP. El puerto de control tx ahora intenta usar IEEE80211_AC_VO para la prioridad, que wpa_supplicants comienza a usar en 2.10. Como solo la parte rtl8187se del controlador admite QoS, la prioridad del skb se establece en IEEE80211_AC_BE (2) por mac80211 para las tarjetas rtl8180/rtl8185. Luego, rtl8180 lee incondicionalmente la prioridad y finalmente se bloquea en la línea 544 de drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c sin este parche: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" es cero para las tarjetas rtl8180/rtl8185, tx_ring[2] nunca se inicializó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evitar el bloqueo por falta de espacio en el diario reservando 1 depósito de diario El bloqueo por falta de espacio en el diario se informó de vez en cuando. Tal bloqueo puede ocurrir en la siguiente situación. Cuando todos los depósitos de diario están completamente llenos por jset activo con una carga de E/S de escritura pesada, el registro del conjunto de caché (después de un reinicio) cargará todos los jsets activos y los insertará en el btree nuevamente (lo que se llama reproducción del diario). Si una bkey registrada en el diario se inserta en un nodo btree y da como resultado la división del nodo btree, se puede activar una nueva solicitud de diario. Por ejemplo, el btree crece un nivel más después de la división del nodo, entonces el registro del nodo raíz en el superbloque del dispositivo de caché se actualizará mediante bch_journal_meta() desde bch_btree_set_root(). Pero no hay espacio en los depósitos de diario, la reproducción del diario tiene que esperar a que se recupere un nuevo depósito de diario después de reproducir al menos un depósito de diario. Este es un ejemplo de cómo ocurre el bloqueo por falta de espacio en el diario. La solución para evitar el bloqueo es reservar 1 depósito de diario en tiempo de ejecución y solo permitir que el depósito de diario reservado se use durante el procedimiento de registro del conjunto de caché para cosas como la reproducción del diario. Entonces, el espacio del diario nunca se llenará por completo, ya no hay posibilidad de que se produzca un bloqueo por falta de espacio en el diario. Este parche agrega un nuevo miembro "bool do_reserve" en struct journal, se inicializa a 0 (falso) cuando se asigna struct journal y se establece en 1 (verdadero) por bch_journal_space_reserve() cuando se realiza toda la inicialización en run_cache_set(). En el tiempo de ejecución, cuando journal_reclaim() intenta asignar un nuevo depósito de diario, se llama a free_journal_buckets() para verificar si hay suficientes depósitos de diario libres para usar. Si solo hay 1 depósito de diario libre y journal->do_reserve es 1 (verdadero), el último depósito está reservado y free_journal_buckets() devolverá 0 para indicar que no hay ningún depósito de diario libre. Luego, journal_reclaim() se dará por vencido y la próxima vez intentará ver si hay un depósito de diario libre para asignar. Con este método, siempre hay un depósito de diario reservado en tiempo de ejecución. Durante el registro del conjunto de caché, journal->do_reserve es 0 (falso), por lo que el depósito de diario reservado se puede utilizar para evitar el bloqueo por falta de espacio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: corrige el use-after-free eliminando un puntero wcid que no sea RCU Corrige un problema detectado por KASAN sobre el use-after-free en mt76_txq_schedule protegiendo mtxq->wcid con rcu_lock entre mt76_txq_schedule y sta_info_[alloc, free]. [18853.876689] ======================================================================= [18853.876751] ERROR: KASAN: use-after-free en mt76_txq_schedule+0x204/0xaf8 [mt76] [18853.876773] Lectura de tamaño 8 en la dirección ffffffaf989a2138 por la tarea mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 No contaminado 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215 [18853.876840] Seguimiento de llamadas: [18853.876861] dump_backtrace+0x0/0x3ec [18853.876878] show_stack+0x20/0x2c [18853.876899] dump_stack+0x11c/0x1ac [18853.876918] print_address_description+0x74/0x514 [18853.876934] kasan_report+0x134/0x174 [18853.876948] __asan_report_load8_noabort+0x44/0x50 [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] ret_from_fork+0x10/0x30 [18853.877098] [18853.877112] Asignado por la tarea 941: [18853.877131] kasan_save_stack+0x38/0x68 [18853.877147] __kasan_kmalloc+0xd4/0xfc [18853.877163] kasan_kmalloc+0x10/0x1c [18853.877177] __kmalloc+0x264/0x3c4 [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211_auth+0x20/0x2c [mac80211] [18853.877733] rdev_auth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211] [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genl_rcv_msg+0x748/0x93c [18853.877954] netlink_rcv_skb+0x160/0x2a8 [18853.877969] genl_rcv+0x3c/0x54 [18853.877985] netlink_unicast_kernel+0x104/0x1ec [18853.877999] netlink_unicast+0x178/0x268 [18853.878015] netlink_sendmsg+0x3cc/0x5f0 [18853.878030] sock_sendmsg+0xb4/0xd8 [18853.878043] ____sys_sendmsg+0x2f8/0x53c [18853.878058] ___sys_sendmsg+0xe8/0x150 [18853.878071] __sys_sendmsg+0xc4/0x1f4 [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c [18853.878101] el0_svc_common+0x1b4/0x390 [18853.878115] do_el0_svc_compat+0x8c/0xdc [18853.878131] el0_svc_compat+0x10/0x1c [18853.878146] el0_sync_compat_handler+0xa8/0xcc [18853.878161] el0_sync_compat+0x188/0x1c0 [18853.878171] [18853.878183] Liberado por la tarea 10927: [18853.878200] kasan_save_stack+0x38/0x68 [18853.878215] kasan_set_track+0x28/0x3c [18853.878228] kasan_set_free_info+0x24/0x48 [18853.878244] __kasan_slab_free+0x11c/0x154 [18853.878259] kasan_slab_free+0x14/0x24 [18853.878273] slab_free_freelist_hook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] sta_info_free+0x198/0x210 [mac80211] [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211] [18853.878628] __sta_info_flush+0x300/0x37c [mac80211] [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211] [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211] [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211] [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211] [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211] [18853.879628] dpm_run_callback+0x58/0x408 [18853.879642] __device_suspend+0x4cc/0x864 [18853.879658] async_suspend+0x34/0xf4 [18 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vduse: corrige la desreferencia de puntero NULL en el acceso a sysfs El dispositivo de control no tiene drvdata. Por lo tanto, obtendremos una desreferencia de puntero NULL al acceder al atributo msg_timeout del dispositivo de control a través de sysfs: [ 132.841881][ T3644] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000f8 [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271) [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094) [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59) [ 132.871164][ T3644] ? archivo_bin_de_eliminación_de_dispositivo (drivers/base/core.c:2088) [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164) [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230) [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041) [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238) [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminador 1)) [ 132.876319][ T3644] kernel_read (fs/read_write.c:459) [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94) [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186) [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207) [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189) [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132) [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419) Para solucionarlo, no cree el atributo innecesario para el dispositivo de control. ya no.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot recibió un nuevo informe [1] que finalmente apunta a un error muy antiguo, agregado en el soporte inicial para el sondeo de MTU. tcp_mtu_probe() tiene comprobaciones sobre el inicio de un sondeo de MTU si tcp_snd_cwnd(tp) >= 11. Pero nada impide que tcp_snd_cwnd(tp) se reduzca más tarde y antes de que el sondeo de MTU tenga éxito. Este error conduciría a posibles divisiones por cero. La depuración agregada en el commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") ha valido la pena :) Mientras estamos en ello, aborde los posibles desbordamientos en este código. [1] ADVERTENCIA: CPU: 1 PID: 14132 en include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Módulos vinculados en: CPU: 1 PID: 14132 Comm: syz-executor.2 No contaminado 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [en línea] RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Código: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [en línea] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [en línea] __se_sys_sendto net/socket.c:2127 [en línea] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 Código: 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: st21nfca: se corrigen las fugas de memoria en la gestión de EVT_TRANSACTION. Las rutas de error no liberan la memoria asignada previamente. Agregue devm_kfree() a esas rutas de error.