Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() Este parche corrige un error de desreferencia de puntero NULL en brcmfmac que ocurre cuando se aplica un valor alto de 'sd_sgentry_align' (por ejemplo, 512) y se envían muchos SKB en cola desde la cola pkt. El problema es la cantidad de entradas en la sgtable preasignada, es nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Dado el valor predeterminado [rt]xglom_size=32, en realidad es 35, que es demasiado pequeño. En el peor de los casos, la cola pkt puede terminar con 64 SKB. Esto ocurre cuando se agrega un nuevo SKB para cada SKB original si tailroom no es suficiente para albergar tail_pad. Se necesita al menos una entrada sg para cada SKB. Por lo tanto, eventualmente el "bucle skb_queue_walk" en brcmf_sdiod_sglist_rw puede quedarse sin entradas sg. Esto hace que sg_next devuelva NULL y esto causa el error. El parche establece nents en max(rxglom_size, txglom_size) * 2 para poder gestionar el peor de los casos. Por cierto, esto requiere solo 64-35=29 * 16 (o 20 si CONFIG_NEED_SG_DMA_LENGTH) = 464 bytes adicionales de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: establecer la limitación correcta del segmento sg AMDGPU El controlador debe establecer el max_segment_size correcto; de lo contrario, debug_dma_map_sg() se quejará sobre el sobremapeo de la longitud sg de AMDGPU de la siguiente manera: ADVERTENCIA: CPU: 6 PID: 1964 en kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [ 364.049444] Módulos vinculados en: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter superposición nvme_fabrics nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c puente stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl leds de entrada snd [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Contaminado: G OE 6.10.0-custom #492 [ 364.049579] Nombre del hardware: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 13/06/2021 [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [ 364.049585] Código: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Rastreo de llamadas: [ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80 [ 364.049614] ? __warn+0x8c/0x140 [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049621] ? report_bug+0x193/0x1a0 [ 364.049627] ? handle_bug+0x46/0x80 [ 364.049631] ? exc_invalid_op+0x1d/0x80 [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30 [ 364.049642] ? srso_return_thunk+0x5/0x5f [364.049939] ? ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm] [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memoria_de_gpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfd_ioctl_alloc_memoria_de_gpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: agregar una verificación para evitar que el índice de la matriz esté fuera de los límites en dbAdjTree Cuando el valor de lp es 0 al comienzo del bucle for, se volverá negativo en la siguiente asignación y deberíamos abandonar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: se corrige el error array-index-out-of-bounds en jfs_readdir. El stbl podría contener algunos valores no válidos. Se agregó una verificación para devolver un código de error en ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: qcom: camss: fix error path on configuration of power domains Existe la posibilidad de encontrar problemas de tiempo de ejecución durante la configuración de dominios de energía CAMSS, porque en la ruta de error dev_pm_domain_detach() se llama inesperadamente con NULL o puntero de error. Una de las formas más simples de reproducir el problema es probar el controlador CAMSS antes del registro de dominios de energía CAMSS, por ejemplo, si un controlador CAMCC de plataforma simplemente no está construido. Ejemplo de seguimiento de advertencia: No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000000000001a2 pc : dev_pm_domain_detach+0x8/0x48 lr : camss_probe+0x374/0x9c0 Seguimiento de llamadas: dev_pm_domain_detach+0x8/0x48 platform_probe+0x70/0xf0 really_probe+0xc4/0x2a8 __driver_probe_device+0x80/0x140 driver_probe_device+0x48/0x170 __device_attach_driver+0xc0/0x148 bus_for_each_drv+0x88/0xf0 __device_attach+0xb0/0x1c0 dispositivo_sonda_inicial+0x1c/0x30 dispositivo_sonda_bus+0xb4/0xc0 función_trabajo_sonda_diferida+0x90/0xd0 trabajo_uno_proceso+0x164/0x3e0 subproceso_trabajador+0x310/0x420 subproceso_k+0x120/0x130 ret_de_bifurcación+0x10/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/deadline: Se corrige la advertencia en migrants_enable para tareas impulsadas Al ejecutar el siguiente comando: while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done, finalmente se activa una advertencia: ADVERTENCIA: CPU: 43 PID: 2848 en kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Seguimiento de llamadas: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? asm_exc_invalid_op+0x16/0x20 entidad_desactivada_en_cola+0x631/0x6e0 tarea_desactivada_en_cola+0x7d/0x120 __establecer_cpus_permitidas+0xe3/0x280 __establecer_cpus_permitidas_ptr_bloqueado+0x140/0x1d0 __establecer_cpus_permitidas_ptr+0x54/0xa0 habilitar_migrar+0x7e/0x150 desbloqueo_rt_spin+0x1c/0x90 información_sig_enviar_grupo+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b Esta advertencia se produce porque set_cpus_allowed quita y pone en cola las tareas con el indicador ENQUEUE_RESTORE establecido. Si se impulsa la tarea, se activa la advertencia. Una tarea impulsada ya tenía sus parámetros establecidos por rt_mutex_setprio y no es necesaria una nueva llamada a setup_new_dl_entity, de ahí la llamada WARN_ON. Verifique si estamos volviendo a poner en cola una tarea impulsada y evite llamar a setup_new_dl_entity si ese es el caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: ref-verify: corrige use-after-free después de una acción de referencia no válida En btrfs_ref_tree_mod() después de que insertamos exitosamente la nueva entrada de referencia (variable local 'ref') en el rbtree de la entrada de bloque respectiva (variable local 'be'), si encontramos una acción inesperada de BTRFS_DROP_DELAYED_REF, generamos un error y liberamos la entrada de referencia sin eliminarla del rbtree de la entrada de bloque. Luego, en la ruta de error de btrfs_ref_tree_mod(), llamamos a btrfs_free_ref_cache(), que itera sobre todas las entradas de bloque y luego llama a free_block_entry() para cada una, y allí activaremos un use-after-free cuando se nos llame contra la entrada de bloque a la que agregamos la entrada de referencia liberada a su rbtree, ya que el rbtree todavía apunta a la entrada de bloque, ya que no la eliminamos del rbtree antes de liberarla en la ruta de error en btrfs_ref_tree_mod(). Solucione esto eliminando la nueva entrada de referencia del rbtree antes de liberarla. Syzbot informa esto con los siguientes seguimientos de pila: Error BTRFS (estado EA del bucle0 del dispositivo): Ref acción 2, raíz 5, ref_root 0, padre 8564736, propietario 0, desplazamiento 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [en línea] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [en línea] __se_sys_unlinkat fs/namei.c:4569 [en línea] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Error BTRFS (estado del dispositivo loop0 EA): Ref acción 1, raíz 5, ref_root 5, padre 0, propietario 260, desplazamiento 0, núm_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 actualización_ref_para_vaca+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [en línea] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 Error BTRFS (estado del dispositivo loop0 EA): Acción de referencia 2, raíz 5, ref_root 0, padre 8564736, propietario 0, desplazamiento 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 actualización_ref_para_vaca+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de use-after-free en btrfs_encoded_read_endio() Shinichiro informó el siguiente use-after-free que a veces sucede en nuestro sistema CI cuando se ejecuta btrfs/284 de fstests en un dispositivo ejecutor de TCMU: ERROR: KASAN: slab-use-after-free en lock_release+0x708/0x780 Lectura de tamaño 8 en la dirección ffff888106a83f18 por la tarea kworker/u80:6/219 CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 No contaminado 6.12.0-rc6-kts+ #15 Nombre del hardware: Supermicro Super Server/X11SPi-TF, BIOS 3.3 21/02/2020 Cola de trabajo: btrfs-endio btrfs_end_bio_work [btrfs] Seguimiento de llamadas: dump_stack_lvl+0x6e/0xa0 ? lock_release+0x708/0x780 print_report+0x174/0x505 ? lock_release+0x708/0x780 ? __virt_addr_valid+0x224/0x410 ? lock_release+0x708/0x780 kasan_report+0xda/0x1b0 ? lock_release+0x708/0x780 ? __wake_up+0x44/0x60 lock_release+0x708/0x780 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? bloqueo_se_retiene_tipo+0x9a/0x110 _raw_spin_unlock_irqrestore+0x1f/0x60 __wake_up+0x44/0x60 btrfs_encoded_read_endio+0x14b/0x190 [btrfs] btrfs_check_read_bio+0x8d9/0x1360 [btrfs] ? bloqueo_liberación+0x1b0/0x780 ? trace_lock_acquire+0x12f/0x1a0 ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs] ? proceso_una_obra+0x7e3/0x1460 ? bloqueo_adquirir+0x31/0xc0 ? proceso_uno_trabajo+0x7e3/0x1460 proceso_uno_trabajo+0x85c/0x1460 ? __pfx_proceso_uno_trabajo+0x10/0x10 ? asignar_trabajo+0x16c/0x240 subproceso_trabajador+0x5e6/0xfc0 ? __pfx_subproceso_trabajador+0x10/0x10 kthread+0x2c3/0x3a0 ? __pfx_kthread+0x10/0x10 retirar_de_bifurcación+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Asignado por la tarea 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs] send_extent_data+0xf0f/0x24a0 [btrfs] process_extent+0x48a/0x1830 [btrfs] changed_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x4f/0x70 kfree+0x143/0x490 btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs] enviar_datos_de_extensión+0xf0f/0x24a0 [btrfs] procesar_extensión+0x48a/0x1830 [btrfs] cambiar_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 hacer_llamada_al_sistema_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff888106a83f00 que pertenece a la caché kmalloc-rnd-07-96 de tamaño 96 La dirección con errores se encuentra 24 bytes dentro de la región liberada de 96 bytes [ffff888106a83f00, ffff888106a83f60) La dirección con errores pertenece a la página física: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004 sin procesar: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto Estado de la memoria alrededor de la dirección con errores: ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc >ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/tctx: workaround al problema de error de asignación de xa_store() syzbot activó el siguiente WARN_ON: WARNING: CPU: 0 PID: 16 en io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 que es la comprobación de cordura WARN_ON_ONCE(!xa_empty(&tctx->xa)); en __io_uring_free() cuando una io_uring_task está pasando por su put final. El caso de prueba de syzbot incluye la inyección de fallos de asignación de memoria, y parece que xa_store() puede fallar en una de sus asignaciones de memoria y terminar con ->head siendo distinto de NULL aunque no existan entradas en la matriz x. Hasta que se resuelva este problema, puede solucionarlo intentando iterar las entradas en nuestra matriz x y usar WARN_ON_ONCE() si encuentra alguna.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Fix sleeping in atomic context for PREEMPT_RT el commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setup_tlb_handler()") cambia el indicador gfp de GFP_KERNEL a GFP_ATOMIC para alloc_pages_node(). Sin embargo, para los núcleos PREEMPT_RT aún podemos obtener un error de "durmiendo en contexto atómico": [ 0.372259] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.372268] preempt_count: 1, esperado: 0 [ 0.372270] Profundidad de anidamiento de RCU: 1, esperado: 1 [ 0.372272] 3 bloqueos mantenidos por swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, en: get_page_from_freelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, en: rt_spin_trylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, en: __rmqueue_pcplist+0x30c/0xea0 [ 0.372314] marca de evento irq: 0 [ 0.372316] hardirqs habilitado por última vez en (0): [<000000000000000>] 0x0 [ 0.372322] hardirqs deshabilitado por última vez en (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372329] softirqs se habilitó por última vez en (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372335] softirqs se deshabilitó por última vez en (0): [<000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 No contaminado 6.12.0-rc7+ #1891 [ 0.372346] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 21/10/2022 [0.372349] Pila: 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 00000000000000000 900000010038b898 9000000007e53788 [ 0,372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0,372498] 000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0,372503] 00000000000000c4 000000000000001 00000000000002d 0000000000000003 [ 0,372509] 0000000000000030 0000000000000003 000000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 000000000000000 000000000000000 900000000c9f5f10 000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Seguimiento de llamadas: [ 0.372542] [<9000000005924778>] show_stack+0x38/0x180 [ 0.372548] [<90000000071519c4>] nivel_pila_volcado+0x94/0xe4 [ 0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] bloqueo_giro_rt+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] obtener_página_de_lista_libre+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] por_cpu_trap_init+0x114/0x140 [ 0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] inicio_secundario+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c Esto se debe a que en los núcleos PREEMPT_RT los spinlocks normales se reemplazan por spinlocks rt y rt_spin_lock() provocará un estado de suspensión. Solucione este problema deshabilitando por completo la optimización NUMA para los núcleos PREEMPT_RT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: se corrige f2fs_bug_on al desinstalar el sistema de archivos, se llama f2fs_evict_inode. La creación de archivos grandes durante el punto de control se desactiva hasta que se queda sin espacio y luego se elimina, luego se vuelve a montar para habilitar el punto de control nuevamente y luego se desmonta el sistema de archivos, lo que activa f2fs_bug_on como se muestra a continuación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount No contaminado 6.11.0-rc7-dirty #360 Oops: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Rastreo de llamadas: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 La causa raíz es: crear archivos grandes durante el período del punto de control de deshabilitación da como resultado que no haya suficientes segmentos libres, por lo que al volver a escribir el inodo raíz, fallará en f2fs_enable_checkpoint. Al desmontar el sistema de archivos después de habilitar el punto de control, el inodo raíz está sucio en la función f2fs_evict_inode, lo que activa BUG_ON. Los pasos para reproducir son los siguientes: dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir Vamos a volver a ensuciar el inodo cuando no haya segmentos libres mientras se deshabilita el punto de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: leds: clase: Proteger illumination_show() con led_cdev->led_access mutex Se observa un problema de puntero NULL si desde el Proceso A se agrega el dispositivo hid, lo que da como resultado la adición de una adición led_cdev y luego otra llamada para acceder al atributo led_cdev desde el Proceso B puede resultar en un problema de puntero NULL. Use mutex led_cdev->led_access para proteger el acceso a led->cdev y su atributo dentro de illumination_show() y max_brightness_show() y también actualice el comentario para mutex que debe usarse para proteger los campos del dispositivo de clase led. Proceso A Proceso B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 dispositivo_crear_con_grupos+0x48 dispositivo_crear_grupos_vargs+0xc8 dispositivo_agregar+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 intento_de_activar[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invocar_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brillo_show+0x20/0x4c dualshock4_led_get_brillo+0xc/0x74 [ 3313.874295][ T4013] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000060 [ 3313.874301][ T4013] Información de aborto de memoria: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (EL actual), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: error de traducción de nivel 2 [ 3313.874313][ T4013] Información de cancelación de datos: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] pgtable de usuario: páginas de 4k, VA de 39 bits, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Volcando búfer ftrace: [ 3313.874334][ T4013] (búfer ftrace vacío) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Rastreo de llamadas: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brillo_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invocar_llamada_al_sistema+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac