Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6:sr: corrige posible use-after-free y null-ptr-deref La estructura de operaciones pernet para el subsystem debe registrarse antes de registrar la familia netlink genérica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: aumenta el tamaño del búfer en afs_update_volume_status() La longitud máxima del volumen->valor vid es de 20 caracteres. Por lo tanto, aumente el tamaño de idbuf[] hasta 24 para evitar el desbordamiento. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [DH: En realidad, es 20 + NUL, así que auméntalo a 24 y usa snprintf()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección de ejecucións entre bpf_timer_cancel_and_free y bpf_timer_cancel La siguiente ejecución es posible entre bpf_timer_cancel_and_free y bpf_timer_cancel. Dirigirá una UAF en el temporizador->temporizador. bpf_timer_cancel(); spin_lock(); t = temporizador->tiempo; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = temporizador->temporizador; temporizador->temporizador = NULL; spin_unlock(); hrtimer_cancel(&t->temporizador); klibre(t); /* UAF en t */ hrtimer_cancel(&t->timer); En bpf_timer_cancel_and_free, este parche libera el temporizador->temporizador después de un período de gracia de rcu. Esto requiere una adición de rcu_head a "struct bpf_hrtimer". Otro kfree(t) ocurre en bpf_timer_init, esto no necesita un kfree_rcu porque todavía está bajo spin_lock y otros aún no han visible el temporizador->temporizador. En bpf_timer_cancel, se agrega rcu_read_lock() porque este asistente puede usarse en un contexto de sección no crítica para rcu (por ejemplo, desde un programa bpf que se puede dormir). Se han auditado otros usos de temporizador->temporizador en helpers.c, bpf_timer_cancel() es el único lugar donde se usa temporizador->temporizador fuera de spin_lock. Otra solución considerada es marcar una bandera t-> en bpf_timer_cancel y borrarla una vez finalizado hrtimer_cancel(). En bpf_timer_cancel_and_free, está ocupado esperando a que se borre la bandera antes de kfree(t). Este parche incluye una solución sencilla y libera el temporizador->temporizador después de un período de gracia de rcu.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: la adición de DLPAR no inicializa completamente pci_controller Cuando se agrega dinámicamente un dispositivo PCI, el kernel falla con una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel activado leído en 0x00000030 Dirección de instrucción errónea: 0xc0000000006bbe5c Vaya: acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 Módulos NUMA pSeries vinculados en: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_r pcgss nfsv4 dns_resolver nfs lockd gracia fscache netfs xsk_diag vinculación nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5 _ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod CPU fusible : 17 PID: 2685 Comm: drmgr No contaminado 6.7.0-203405+ #66 Nombre de hardware: IBM,9080-HEX POWER10 (sin procesar) 0x800200 0xf000006 de:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006b be5c LR : c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 No contaminado (6.7.0-203405+) MSR: 8000000000009033 CR: 2400 2220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Seguimiento de llamadas: iommu_init_device+0x26c/0x318 (no confiable) iommu_device_ enlace+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+ 0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_s can_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+ 0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b 0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+ 0x124/0x330 system_call_vectored_common+0x15c/0x2ec el commit a940904443e4 ("powerpc/iommu: agregue iommu_ops para informar capacidades y permitir dominios de bloqueo") rompió la adición DLPAR de dispositivos PCI. Lo anterior agregó la estructura iommu_device a pci_controller. Durante el arranque del SYSTEM, se descubren dispositivos PCI y esta estructura iommu_device recién agregada se inicializa mediante una llamada a iommu_device_register(). Durante la adición DLPAR de un dispositivo PCI, se asigna una nueva estructura pci_controller pero no se realizan llamadas a la interfaz iommu_device_register(). La solución es registrar también el dispositivo iommu durante la adición de DLPAR.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: act_mirred: use el trabajo pendiente para el ingreso duplicado. La prueba que Davide agregó en el compromiso ca22da2fbd69 ("act_mirred: use el trabajo pendiente para llamadas anidadas para el ingreso duplicado") bloquea nuestras máquinas virtuales de prueba. aproximadamente cada 10 ejecuciones, con el conocido punto muerto tcp_v4_rcv -> tcp_v4_rcv informado por lockdep. El problema descrito anteriormente por Davide (ver Enlace) es que si invertimos el flujo de tráfico con la redirección (salida -> entrada) podemos llegar al mismo socket que generó el paquete. Y es posible que todavía estemos sosteniendo el bloqueo del enchufe. La solución común a estos puntos muertos es colocar el paquete en el trabajo pendiente de Rx, en lugar de ejecutar la ruta de Rx en línea. Haga eso para todas las reversiones de salida -> entrada, no solo una vez que comenzamos a anidar llamadas reflejadas. En el pasado, existía la preocupación de que la dirección indirecta del trabajo pendiente provocara la pérdida de informes de errores o estadísticas menos precisas. Pero la solución actual no parece solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dccp/tcp: Unhash sk de ehash para error de asignación de tb2 después de check_estalblished(). syzkaller informó una advertencia [0] en inet_csk_destroy_sock() sin reproducción. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); Sin embargo, el registro del syzkaller insinuó que connect() falló justo antes de la advertencia debido a FAULT_INJECTION. [1] Cuando se llama a connect() para un socket independiente, buscamos un puerto efímero disponible. Si existe un depósito bhash para el puerto, llamamos a __inet_check_establecido() o __inet6_check_establecido() para verificar si el depósito es reutilizable. Si es reutilizable, agregamos el socket en ehash y configuramos inet_sk(sk)->inet_num. Luego, buscamos el depósito bhash2 correspondiente e intentamos asignarlo si no existe. Aunque rara vez ocurre en el uso real, si la asignación falla, debemos revertir los cambios mediante check_establecido(). De lo contrario, un enchufe desconectado podría ocupar ilegalmente una entrada ehash. Tenga en cuenta que no volvemos a colocar tw en ehash porque es posible que sk ya haya respondido a un paquete para tw y sería mejor liberar tw antes bajo tal presión de memoria. [0]: ADVERTENCIA: CPU: 0 PID: 350830 en net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Módulos vinculados en: Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Código: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e 7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e 46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 00000000000000000 R10: 0000000000009e78 R11: 00 00000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knl GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 5555 Llamada 5554 Seguimiento: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/ socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Código: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3 5 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 00000000000000003 RAX: ffffffffffffffda RBX: 00000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 000000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e431 70 [1]: FAULT_INJECTION: forzando un fallo. nombre failslab, intervalo 1, probabilidad 0, espacio 0, tiempos 0 CPU: 0 PID: 350833 Comm: syz-executor.1 No contaminado 6.7.0-12272-g2121c43f88f5 #9 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: smartpqi: solucione enable_managed_interrupts Corrija el problema de registro de blk-mq con el parámetro del módulo enable_managed_interrupts habilitado. Cuando desactivamos el indicador PCI_IRQ_AFFINITY predeterminado, el controlador debe registrarse con blk-mq usando blk_mq_map_queues(). Actualmente, el controlador está llamando a blk_mq_pci_map_queues(), lo que genera un seguimiento de la pila y posiblemente un comportamiento indefinido. Seguimiento de pila: [7.860089] scsi host2: smartpqi [7.871934] ADVERTENCIA: CPU: 0 PID: 238 en block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [7.889231] Módulos vinculados en: sd_mod t10_pi sg uas smartpqi (+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fusible [7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 No contaminado 4.18.0-372.88.1.el8_6_smartpqi_test .x86_64 #1 [7.944336] Nombre del hardware: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 08/03/2022 [ 7.963026] Cola de trabajo: eventos work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Código: 4 8 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 5 7 49 89 y siguientes 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000 0000000010 [ 7.978284] RDX: 00000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc370 7d38 R09: ffff91929b81ac00 [ 7.978287] R10: 00000000000000001 R11: ffffa95fc3707ac0 R12: 00000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 0 0000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [8.172816] DR0: [ 8.172818] PKRU : 55555554 [8.172819] Seguimiento de llamadas: [8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [8.279302] pqi_ctrl_init+0xacf/0 xc8e [smartpqi] [8.294085]? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.3 51193] proceso_one_work+0x1a7/0x360 [8.364462]? create_worker+0x1a0/0x1a0 [8.379252] work_thread+0x1ce/0x390 [8.392623]? create_worker+0x1a0/0x1a0 [8.406295] kthread+0x10a/0x120 [8.418428]? set_kthread_struct+0x50/0x50 [8.431532] ret_from_fork+0x1f/0x40 [8.444137] ---[ final de seguimiento 1bf0173d39354506 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/qedr: corrija el flujo de error qedr_create_user_qp Evite la siguiente advertencia asegurándose de liberar los recursos asignados en caso de que qedr_init_user_queue() falle. -----------[ cortar aquí ]----------- ADVERTENCIA: CPU: 0 PID: 143192 en drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/ 0xf0 [ib_uverbs] Módulos vinculados en: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace fscache netfs 8 021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fusible drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [última descarga: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: cargado No contaminado 5.14.0-408.el 9.x86_64 #1 Nombre del hardware: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 25/01/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Código: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc 60 EF BANDERAS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 00000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 00000000000039000 R12: ffff8f0d5b36cd80 R13: ff ff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 00000000000000000( 0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7 210002 CR4: 00000000001706f0 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __advertir+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x8 7c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Código: no se puede acceder a los bytes del código de operación en RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9 200 RSI: 00000000c0181b01 RDI: 00000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 --[ final de seguimiento 888a9b92e04c5c97 ]--

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: admite la especificación del parámetro srpt_service_guid. Hace que la carga de ib_srpt con este conjunto de parámetros funcione. El comportamiento actual es que configurar ese parámetro mientras se carga el módulo del kernel ib_srpt desencadena el siguiente fallo del kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 Seguimiento de llamadas: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/ 0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: roles: soluciona el problema del puntero NULL al colocar la referencia del módulo. En el diseño actual, el controlador de clase de rol usb obtendrá la referencia del módulo principal usb_role_switch después de que el usuario obtenga el dispositivo usb_role_switch y coloque la referencia después del El usuario puso el dispositivo usb_role_switch. Sin embargo, el dispositivo principal de usb_role_switch se puede eliminar antes de que el usuario coloque usb_role_switch. Si es así, entonces, el problema del puntero NULL se solucionará cuando el usuario coloque la referencia del módulo principal. Esto guardará el puntero del módulo en la estructura de usb_role_switch. Entonces, no necesitamos encontrar el módulo iterando relaciones largas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: corrige la memoria doblemente libre cuando se maneja el paquete cero 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, solicitud 832); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (solicitud->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, solicitud); El controlador agrega una solicitud de paquete cero adicional cuando pone en cola un paquete, cuya longitud mod tamaño máximo del paquete es 0. Cuando se complete la transferencia, ejecute la línea 831, usb_gadget_giveback_request() liberará esta solicitud. La condición 836 es verdadera, por lo que cdns3_gadget_ep_free_request() libera esta solicitud nuevamente. Registro: [1920.140696][ T150] ERROR: KFENCE: lectura de uso después de liberación en cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Lectura de uso después de liberación en 0x000000003d 1cd10b (en kcerca -#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Agregar cheque en la línea 829, omitir llamada usb_gadget_giveback_ request() si tiene una longitud cero adicional solicitud de paquete. No es necesario llamar a usb_gadget_giveback_request() porque está asignado en este controlador.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: cdns3: uso de memoria fijo después de liberar en cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->lista); ... 'priv_req' en realidad es gratuito en cdns3_gadget_ep_free_request(). Pero list_del_init() usa priv_req->list después. [ 1542.642868][ T534] ERROR: KFENCE: lectura de uso después de liberación en __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Lectura de uso después de liberación en 0x000000009ed0ba99 (en kfence-#3 ): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0x e4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839] [ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Mueva list_del_init() antes de cdns3_gadget_ep_free_request() para resolver este problema.