Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: synproxy: corrección de límites al analizar opciones TCP. El analizador de opciones TCP en synproxy (synproxy_parse_options) podría leer un byte fuera de los límites. Cuando la longitud es 1, el flujo de ejecución entra en el bucle, lee un byte del código de operación y, si el código de operación no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte más, que excede la longitud de 1. Esta solución está inspirada en la confirmación. 9609dad263f8 ("ipv4: tcp_input: corrige la pila fuera de los límites al analizar las opciones de TCP"). Cambios en v2: se agregó un retorno anticipado cuando la longitud <0 para evitar llamar a skb_header_pointer con una longitud negativa.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: Reparar la recuperación de página para la horquilla del par inactiva. Al agregar un flujo de horquilla, se crea una cola de envío del lado del firmware para el dispositivo de red del par, que reclama algunas páginas de memoria del host para su buffer de anillo interno. Si el dispositivo peer net se elimina/desvincula antes de eliminar el flujo de horquilla, entonces la cola de envío no se destruye, lo que genera un seguimiento de la pila en la eliminación del dispositivo pci: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): Tiempo de espera de MANAGE_PAGES(0x108). Provocará una fuga de un recurso de comando [748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): error al recuperar páginas: err -110 [748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): error al recuperar páginas (-110) para el ID de función 0x0 [748.002171] ------------[ cortar aquí ]------------ [ 748.001177] páginas FW el contador es 4 después de reclamar todas las páginas [748.001186] ADVERTENCIA: CPU: 1 PID: 12985 en drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [+0.002771] Módulos vinculados en: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [última descarga: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [748.001679] Código: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 GS: 00010286 [748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ee7 R12: ffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) 000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4 : 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [748.001654] Seguimiento de llamadas: [748.000576]? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [748.001416]? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [748.001354]? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] uno+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [748.001057]? lock_acquire+0x4d6/0x700 [748.000908]? lockdep_hardirqs_on_prepare+0x400/0x400 [748.001126]? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [748.000811]? filp_open+0x50/0x50 [748.000919]? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.00 ---truncado---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: udp: corrige la ejecución entre close() y udp_abort(). Kaustubh informó y diagnosticó un pánico en udp_lib_lookup(). La causa principal es que udp_abort() compite con close(). Ambas funciones de ejecución adquieren el bloqueo del socket, pero udp{v6}_destroy_sock() lo libera antes de realizar acciones destructivas. No podemos extender fácilmente el alcance del bloqueo del socket para evitar la ejecución; en su lugar, usamos el indicador SOCK_DEAD para evitar que udp_abort realice alguna acción cuando ocurre la ejecución crítica. Diagnosticado y probado por: Kaustubh Pandey

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:rds: corrige pérdida de memoria en rds_recvmsg. Syzbot informó pérdida de memoria en rds. El problema estaba en el recuento no puesto en caso de error. int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags) { ... if (!rds_next_incoming(rs, &inc)) { ... } Después de esto "if" inc refcount incrementado y if (rds_cmsg_recv (inc, mensaje, rs)) { ret = -EFAULT; salir; } ... fuera: devolver ret; } en caso de que rds_cmsg_recv() falle, el recuento no disminuirá. Y es fácil ver en el registro de ftrace que rds_inc_addref() no tiene el par rds_inc_put() en rds_recvmsg() después de rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us| rds_inc_addref(); 1) 3.853 us| rds_message_inc_copy_to_user(); 1) + 10.395 us| rds_cmsg_recv(); 1) + 34.260 us| }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: corrige la pérdida de memoria en netlbl_cipsov4_add_std. Reportado por syzkaller: BUG: pérdida de memoria objeto sin referencia 0xffff888105df7000 (tamaño 64): comm "syz-executor842", pid 360, jiffies 4294824824 ( edad 22,546 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e67ed558>] kmalloc include/linux/slab.h:590 [en línea] [<00000000e67ed558> ] kzalloc include/linux/slab.h:720 [en línea] [<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [en línea] [<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x234 0 net/netlabel/netlabel_cipso_v4.c: 416 [<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739 [<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [en línea] 00000204d7a1c>] genl_rcv_msg+0x2bf /0x4f0 net/netlink/genetlink.c:800 [<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504 [<00000000d78b9d2c>] genl_rcv+0x24/0x40 11 [ <000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [en línea] [<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340 [<00000000d5fd43b8>] enviar mensaje+0x789/0xc70 net/netlink/ af_netlink.c:1929 [<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [en línea] [<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674 [<00000000321d19 69>] ____sys_sendmsg+0x658/0x7d0 neto/ socket.c:2350 [<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404 [<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433 4ee8b6a5>] do_syscall_64+0x37/0x90 arco /x86/entry/common.c:47 [<00000000171c7cee>] Entry_SYSCALL_64_after_hwframe+0x44/0xae La memoria de apuntamiento doi_def->map.std está asignada en netlbl_cipsov4_add_std, pero no se ha liberado ningún lugar. Debe liberarse en cipso_v4_doi_free, lo que libera el recurso cipso DOI.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: se corrigió el use after free de la entrada encap en el controlador de actualización cercano. La función mlx5e_rep_neigh_update() no se actualizó para permitir la eliminación del bloqueo rtnl de la ruta de actualización del filtro TC y manejar adecuadamente inserción/eliminación simultánea de entradas encapsuladas que pueden conducir al siguiente use after free: [23827.464923] ================================ ==================================== [23827.469446] BUG: KASAN: use after free en mlx5e_encap_take +0x72/0x140 [mlx5_core] [23827.470971] Lectura de tamaño 4 en la dirección ffff8881d132228c por tarea kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 kworker/u20 :6 No contaminado 5.13.0 -rc3+ #5 [23827.473788] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [23827.475639] Cola de trabajo: mlx5e mlx5e_rep_neigh_update [ mlx5_core] [23827.476731] Seguimiento de llamadas: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896]? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537]? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831]? Process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ? __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Asignado por tarea 28248: [23827.507694] 0 [23827.508476] __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core ] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] 191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.51 7300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg +0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131] ____sys_sendmsg+0x590/0x770 [23827.520851] ___sys_sendmsg+0xd8/0x160 [23827. 521552] __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] Entry_SYSCALL_64_after_hwframe+0x44 /0xae [23827.523797] [23827.524163] Liberado por la tarea 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] _free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+ 0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] Process_one_work+0x8ac/0x14e0 [23827.530770 ] work_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/ 0x30 [23827.532785] [23827.533147] Última creación de trabajo potencialmente relacionado: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] _rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/ioremap: asigne la memoria reservada de EFI como cifrada para SEV. Algunos controladores requieren memoria marcada como datos de servicios de arranque de EFI. Para que el kernel no reutilice esta memoria después de ExitBootServices(), se utiliza efi_mem_reserve() para preservarla insertando un nuevo descriptor de memoria EFI y marcándolo con el atributo EFI_MEMORY_RUNTIME. En SEV, la memoria marcada con el atributo EFI_MEMORY_RUNTIME debe ser asignada cifrada por Linux; de lo contrario, el kernel podría fallar en el arranque como se muestra a continuación: EFI Variables Facility v0.08 2004-May-17 falla de protección general, probablemente para la dirección no canónica 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 No contaminado 5.12.4-2-default #1 openSUSE Tumbleweed Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 02 /06/2015 RIP: 0010:efi_mokvar_entry_next [...] Seguimiento de llamadas: efi_mokvar_sysfs_init? efi_mokvar_table_init do_one_initcall? __kmalloc kernel_init_freeable? rest_init kernel_init ret_from_fork Expanda la función __ioremap_check_other() para verificar adicionalmente este otro tipo de datos de arranque reservados en tiempo de ejecución e indicar que deben asignarse cifrados para un invitado SEV. [pb: mensaje de confirmación de masaje. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: aardvark: solucionó el pánico del kernel durante la transferencia de PIO. Intentar iniciar una nueva transferencia de PIO escribiendo el valor 0 en el registro PIO_START cuando la transferencia anterior aún no se ha completado (que se indica con el valor 1). en PIO_START) provoca un aborto externo en la CPU, lo que resulta en pánico del kernel: Interrupción de SError en CPU0, código 0xbf000002 - Pánico del kernel de SError - no se sincroniza: Interrupción de SError asincrónica Para evitar el pánico del kernel, es necesario rechazar una nueva transferencia de PIO cuando el anterior aún no ha terminado. Si la transferencia PIO anterior aún no ha finalizado, el kernel puede emitir una nueva solicitud PIO solo si se agotó el tiempo de espera de la transferencia PIO anterior. En el pasado, la causa root de este problema se identificó incorrectamente (como sucede a menudo durante el reentrenamiento del enlace o después de un evento de caída del enlace) y se implementó un truco especial en Trusted Firmware para detectar todos los eventos de SError en EL3, para ignorar los errores con el código 0xbf000002 y no reenviar cualquier otro error al kernel y en su lugar generar pánico desde el controlador de firmware confiable EL3. Enlaces a discusiones y parches sobre este problema: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci /20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted -firmware-a/+/1541 Pero la causa real fue el hecho de que durante el reentrenamiento del enlace o después de un evento de caída del enlace, la transferencia de PIO puede tardar más tiempo, hasta 1,44 segundos hasta que se agote el tiempo de espera. Esto aumenta la probabilidad de que el kernel emita una nueva transferencia PIO mientras que la anterior aún no ha finalizado. Después de aplicar este cambio en el kernel, es posible revertir el hack de TF-A mencionado y los eventos SError no tienen que detectarse en TF-A EL3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM Restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM de la vCPU para que el indicador SMM en la función MMU esté siempre sincronizado con el indicador de la vCPU. Si RSM falla (que no se emula correctamente), KVM se retirará sin llamar a post_leave_smm() y dejará la MMU en mal estado. La función incorrecta de MMU puede provocar una desreferencia del puntero NULL al tomar el rmap de una página oculta para una falla de página, ya que las búsquedas iniciales para gfn se realizarán con el indicador SMM de la vCPU (=0), mientras que la búsqueda de rmap utilizará el SMM de la página oculta. bandera, que proviene de la MMU (=1). SMM tiene un conjunto de ranuras de memoria completamente diferente, por lo que la búsqueda inicial puede encontrar una ranura de memoria (SMM=0) y luego explotar en la búsqueda de ranura de memoria de rmap (SMM=1). falla de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000000-0x00000000000000007] CPU: 1 PID: 8410 Comm: No contaminado 5.13.0 -rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [en línea] RIP: 0010: gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 Código: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP:ffffc90000ffe f98 EFLAGS : 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 00000000000000000 RSI: 0000000000000001 RDI: 00000000000 00001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 00000000000000000 R12: dffffc0000000000 R13: 0000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300 (0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 8e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: rmap_add arch/x86/kvm/mmu/mmu.c:965 [en línea] mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 __direct_map arch/x86/kvm/mmu/mmu. c:2862 [en línea] direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [en línea] kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/ mmu/mmu.c:5065 vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpu_run+0x416/0xc20 arch/x86/ kvm/x86.c:9494 kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c :3460 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:1069 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c :47 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x440ce9

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcba_usb: repara la pérdida de memoria en mcba_usb. Syzbot informó una pérdida de memoria en el controlador SocketCAN para la herramienta Microchip CAN BUS Analyzer. El problema estaba en usb_coherent no liberado. En mcba_usb_start() se asignan 20 buffers coherentes y no hay nada que los libere: 1) En la función de devolución de llamada, la urb se vuelve a enviar y eso es todo 2) En la función de desconexión, las urbs simplemente se eliminan, pero URB_FREE_BUFFER no está configurado (ver mcba_usb_start) y Esta bandera no se puede utilizar con buffers coherentes. Registro de errores: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: dispositivo desconectado | [ 1367.059384][ T8420] kmemleak: 20 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmem) Por lo tanto, todos los buffers asignados deben liberarse con usb_free_coherent() explícitamente NOTA: Se utiliza el mismo patrón para asignar y liberar buffers coherentes en controladores/net/can/usb/kvaser_usb/kvaser_usb_core.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: corrige Use-after-Free, mantenga presionada la referencia skb mientras está en uso. Este parche corrige un Use-after-Free encontrado por syzbot. El problema es que se toma un skb de la cola de skb por sesión, sin incrementar el recuento de referencias. Esto conduce a un use after free si el skb se toma simultáneamente de la cola de sesión debido a un CTS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: regulador: rt4801: corrige la desreferencia del puntero NULL si priv->enable_gpios es NULL, devm_gpiod_get_array_optional puede devolver NULL si no se asignó ningún GPIO.