Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: usbhid: buffers raw_report libres en usbhid_stop. Libera los buffers raw_report no enviados cuando se elimina el dispositivo. Corrige una pérdida de memoria informada por syzbot en: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: agregue verificación de errores a ext4_ext_replay_set_iblocks(). Si la llamada a ext4_map_blocks() falla debido a un sistema de archivos dañado, ext4_ext_replay_set_iblocks() puede quedarse atascado en un bucle infinito. Esto podría reproducirse ejecutando generic/526 con un sistema de archivos que tenga inline_data y fast_commit habilitados. El sistema iniciará sesión repetidamente en la consola: Advertencia EXT4-fs (dispositivo dm-3): ext4_block_to_path:105: bloque 1074800922 > max en el inodo 131076 y la pila en la que se atasca es: ext4_block_to_path+0xe3/0x130 ext4_ind_map_blocks+0x93/ 0x690 ext4_map_blocks+0x100/0x660 skip_hole+0x47/0x70 ext4_ext_replay_set_iblocks+0x223/0x440 ext4_fc_replay_inode+0x29e/0x3b0 ext4_fc_replay+0x278/0x550 do_one_pass+0x646/ 0xc10 jbd2_journal_recover+0x14a/0x270 jbd2_journal_load+0xc4/0x150 ext4_load_journal+0x1f3/0x490 ext4_fill_super+0x22d4/ 0x2c00 Con este parche, generic/526 todavía falla, pero el sistema ya no se bloquea en un bucle cerrado. Es probable que la causa raíz sea que la reproducción fast_commit esté corrompiendo los sistemas de archivos con inline_data, y probablemente necesitemos agregar un mejor manejo de errores en la ruta del código de reproducción de confirmación rápida más allá de lo que se hace aquí, lo que esencialmente simplemente rompe el bucle infinito sin informar al niveles superiores del código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Manejar el error de inicialización de SRCU durante el inicio del seguimiento de la página. Verifique el retorno de init_srcu_struct(), que puede fallar debido a OOM, al inicializar el mecanismo de seguimiento de la página. La falta de verificación conduce a un puntero NULL deref encontrado por un syzkaller modificado. [Mueva la llamada hacia el principio de kvm_arch_init_vm. -Paolo]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: conntrack: serializar cambios de tamaño y limpiezas de hash. Syzbot pudo activar la siguiente advertencia [1] Syzbot aún no encontró ninguna reproducción, pero pude desencadenar un problema similar al tener 2 scripts ejecutándose en paralelo, cambiando los tamaños de hash de conntrack y: para j en `seq 1 1000`; dejar de compartir -n /bin/true >/dev/null ; done Se necesitarían más de 5 minutos para limpiar las estructuras net_namespace. Esto se debe a que nf_ct_iterate_cleanup() tiene que reiniciarse cada vez que ocurre un cambio de tamaño. Al agregar un mutex, podemos serializar los cambios de tamaño y las limpiezas de hash y también hacer que get_next_corpse() sea más rápido omitiendo los depósitos vacíos. Incluso sin cambios de tamaño en la imagen, este parche acelera considerablemente el desmantelamiento del espacio de nombres de la red. [1] INFORMACIÓN: la tarea syz-executor.0:8312 no puede morir durante más de 144 segundos. tarea:syz-executor.0 estado:R ejecutando pila de tareas:25672 pid: 8312 ppid: 6573 banderas:0x00004006 Seguimiento de llamadas: context_switch kernel/sched/core.c:4955 [en línea] __schedule+0x940/0x26f0 kernel/sched/core .c:6236 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 local_bh_enable include/ Linux /bottom_half.h:32 [en línea] get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [en línea] nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/ nf_conntrack_core.c:2469 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 setup_net+0x639/0xa30 net/core/net_namespace.c:349 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy .c:110 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksys_unshare+0x445/0x920 kernel/fork.c:3128 __do_sys_unshare kernel/fork.c:3202 [en línea] __se_sys_unshare kernel/fork.c:3200 [en línea] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae : 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000 Mostrando todos los bloqueos retenidos en el sistema: 1 bloqueo retenido por khungtaskd/27: #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, : debug_show_all_locks+0x53 /0x260 kernel/locking/lockdep.c:6446 2 bloqueos retenidos por kworker/u4:2/153: #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: arch_atomic64_set arch /x86/include/asm/atomic64_64.h:34 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: arch_atomic_long_set include/linux/atomic/atomic-long .h:41 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [en línea] # 0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: set_work_data kernel/workqueue.c:634 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+. }-{0:0}, en: set_work_pool_and_clear_pending kernel/workqueue.c:661 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: Process_one_work+0x896/ 0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, en: Process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 1 bloqueo retenido por systemd-udevd/2970: 1 bloqueo retenido por in:imklog/6258: #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, en: __fdget_pos+0xe9/0x100 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: verifique el valor de retorno después de llamar a platform_get_resource(). Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de svm_migrate_fini. El administrador de dispositivos libera recursos específicos del dispositivo cuando un controlador se desconecta de un dispositivo, las llamadas a devm_memunmap_pages y devm_release_mem_region en svm_migrate_fini son redundantes. Provoca el siguiente seguimiento de advertencia después del parche "drm/amdgpu: dividir amdgpu_device_fini en temprano y tarde", por lo tanto, elimine la función svm_migrate_fini. ERROR: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 ADVERTENCIA: CPU: 1 PID: 3646 en drivers/base/devres.c:795 devm_release_action+0x51/0x60 Seguimiento de llamadas:? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu_device_fini_sw+0x45/0 x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu]

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io_uring: permite reprogramación condicional para iteradores intensivos. Si tenemos muchos hilos y anillos, la lista tctx puede volverse bastante grande. Esto es especialmente cierto si seguimos creando nuevos hilos y anillos. Lo mismo ocurre con la lista de buffers proporcionada. Sea amable e inserte un punto de reprogramación condicional mientras itera los nodos para su eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: también busque 'phys' phandle. Al pasar 'phys' en el árbol de dispositivos para describir el phandle USB PHY (que es la forma recomendada según Documentation/devicetree /bindings/usb/ci-hdrc-usb2.txt) se observa la siguiente desreferencia del puntero NULL en i.MX7 e i.MX8MM: [1.489344] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000098 [1.498170] Información de cancelación de memoria: [ 1.500966] ESR = 0x96000044 [ 1.504030] EC = 0x25: DABT (EL actual), IL = 32 bits [ 1.509356] SET = 0, FnV = 0 [ 1.512416] EA = 0, S1PTW = 0 [ 1.515569] FSC = 0x04: error de traducción de nivel 0 [1.520458] Información de cancelación de datos: [1.523349] ISV = 0, ISS = 0x00000044 [1.527196] CM = 0, WnR = 1 [1.530176] [0000000000000098] dirección de usuario pero active_mm es intercambiador [1.536544 ] Error interno: Ups : 96000044 [#1] PREEMPT SMP [ 1.542125] Módulos vinculados en: [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3 [ 1.551901] Nombre de hardware: Kontron i.MX8MM N801X S (DT) [1.557133] Cola de trabajo: events_unbound deferred_probe_work_func [1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [1.568998] pc: imx7d_charger_detection+0x3f0/0x510 [ 1. 573973] lr: imx7d_charger_detection+0x22c /0x510 Esto sucede porque las funciones del cargador verifican la presencia de phy dentro de la estructura imx_usbmisc_data (data->usb_phy), pero el núcleo chipidea llena el usb_phy pasado a través de 'phys' dentro de 'struct ci_hdrc' (ci->usb_phy). Esto provoca la desreferencia del puntero NULL dentro de imx7d_charger_detection(). Solucione el problema buscando también 'phys' en caso de que no se encuentre 'fsl,usbphy'. Probado en una placa imx7s-warp.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: vaciar el icache de la CPU actual antes que otras CPU. En SiFive Unmatched, recientemente encontré el siguiente BUGal arrancar: [0.000000] ftrace: asignar 36610 entradas en 144 páginas [0.000000] Ups - instrucción ilegal [#1] [ 0.000000] Módulos vinculados en: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Nombre del hardware: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc: riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0 .000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 00000000000000004 t2 : 00000000000000000 s0: ffffffff81803e60 [0.000000] s1: 0000000000000000 a0: ffffffff81a22238 a1: ffffffff81803e10 [0.000000] a2: 000000000000000 a3: 0000000 000000000 a4: 0000000000000000 [0.000000] a5: 0000000000000000 a6: ffffffff8000989c a7: 0000000052464e43 [0.000000] s2: ffffffff81a220c8 s3: 0000000000000000 s4: 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [0.000000] s11: 0000000000000004 t3: 0000000000000001 t4: 0000000000000008 [0.000000] t5: ffcf04000808 t6: ffffffe3ffddf188 [0.000000] estado : 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000002 [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [] Flush_icache_all+0x12/0x1a [ 0.000000] [] patch_text_nosync+0x26/0x32 [ 0.000000] [] ftrace_init_nop+0x52/0x8c [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/ 0x360 [ 0.000000] [] ftrace_init+ 0x80/0x130 [ 0.000000] [] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Pánico en el kernel - no se sincroniza: ¡Intentó finalizar la tarea inactiva! [0.000000] ---[ fin del pánico del kernel: no se sincroniza: ¡se intentó finalizar la tarea inactiva! ]--- Mientras ftrace recorre una lista de direcciones para parchear, siempre fallaba al parchear la misma función: riscv_cpuid_to_hartid_mask. Al observar el seguimiento, la instrucción ilegal se encuentra en esta misma función. Sin embargo, patch_text_nosync, después de parchear las instrucciones, llama a flush_icache_range. Pero observando lo que sucede en esta función: Flush_icache_range -> Flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask El icache y el dcache de la CPU actual nunca se sincronizan entre el parche de riscv_cpuid_to_hartid_mask y la llamada a esta misma función. Así que solucione este problema limpiando el icache de la CPU actual antes de pedirle a las otras CPU que hagan lo mismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: mvm: Corrige posible desreferencia NULL En __iwl_mvm_remove_time_event() comprueba que 'te_data->vif' sea NULL antes de desreferenciarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. Esta forma es segura porque tanto ioc_rqos_done_bio() como blkcg_iolatency_done_bio() no funcionan si no se realiza un seguimiento de la biografía.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: se rompe si skb_header_pointer devuelve NULL en sctp_rcv_ootb. Siempre debemos verificar si el retorno de skb_header_pointer es NULL antes de usarlo; de lo contrario, puede causar null-ptr-deref, como informó syzbot: KASAN : null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [en línea] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input .c:196 Seguimiento de llamadas : sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 incluir/linux /netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [en línea] ip6_rcv_finish net/ipv6/ip6_input.c:76 [en línea] NF_HOOK include/linux/netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c :297