Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: vaciar la cola de trabajadores delalloc antes de detener el kthread del limpiador durante el desmontaje Durante la ruta de desmontaje, en close_ctree(), primero detenemos el kthread del limpiador, utilizando kthread_stop() que libera el task_struct asociado, y luego detenemos y destruimos todas las colas de trabajo. Sin embargo, después de detener el limpiador, es posible que aún tengamos un trabajador de la cola delalloc_workers ejecutando inode.c:submit_compressed_extents(), que llama a btrfs_add_delayed_iput(), que a su vez intenta despertar el kthread del limpiador, que ya se destruyó antes, lo que resulta en un uso después de la liberación en el task_struct. Syzbot informó esto con los siguientes seguimientos de pila: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Lectura de tamaño 8 en la dirección ffff8880259d2818 por la tarea kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 No contaminado 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: btrfs-delalloc btrfs_work_helper Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [en línea] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave incluir/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [en línea] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [en línea] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [en línea] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 Asignado por la tarea 2: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [en línea] gancho de alloc de publicación de losa mm/slub.c:4104 [en línea] nodo de alloc de losa mm/slub.c:4153 [en línea] nodo de alloc de caché kmem_noprof+0x1d9/0x380 mm/slub.c:4205 nodo de estructura de tareas de asignación kernel/fork.c:180 [en línea] estructura de tareas dup+0x57/0x8c0 kernel/fork.c:1113 proceso de copia+0x5d1/0x3d50 kernel/fork.c:2225 clon de kernel+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [en línea] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Liberado por la tarea 24: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [en línea] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [en línea] gancho slab_free mm/slub.c:2338 [en línea] slab_free mm/slub.c:4598 [en línea] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [en línea] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [en línea] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Corrija la dirección del mapa DMA de migración La dirección del mapa del dispositivo DMA de SVM debe configurarse igual que la configuración de anulación del mapa DMA; de lo contrario, el núcleo DMA informará la siguiente advertencia. Antes de finalizar esta solución, hay una discusión sobre el tipo de mapeo DMA (basado en flujo o coherente) en este caso de migración KFD, seguido de https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/. Como no hay dma_sync_single_for_*() en el búfer DMA al que se accede, esto se debe a que esta operación de migración debe sincronizarse de manera adecuada y automática. Dado que es posible que no haya un problema de rendimiento en varias políticas de sincronización de caché de la sincronización DMA. Por lo tanto, para simplificar la alineación de la configuración de la dirección DMA, configuremos la dirección del mapa DMA como BIDIRECCIONAL. [ 150.834218] ADVERTENCIA: CPU: 8 PID: 1812 en kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Módulos vinculados en: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) 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 overlay nvme_fabrics nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common 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 snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd leds de entrada [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) 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 [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Contaminado: G OE 6.10.0-custom #492 [ 150.834358] Nombre del hardware: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 13/06/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Código: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 00000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Seguimiento de llamadas: [ 150.834385] [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: serializar llamadas a nf_register_net_hooks() syzbot encontró una carrera en ila_add_mapping() [1] la confirmación 031ae72825ce ("ila: llamar a nf_unregister_net_hooks() antes") intentó solucionar un problema similar. Al observar la reproducción de syzbot, tenemos comandos ILA_CMD_ADD simultáneos. Agregue un mutex para asegurarse de que, como máximo, un hilo esté llamando a nf_register_net_hooks(). [1] ERROR: KASAN: slab-use-after-free en rht_key_hashfn include/linux/rhashtable.h:159 [en línea] ERROR: KASAN: slab-use-after-free en __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Lectura de tamaño 4 en la dirección ffff888028f40008 por la tarea dhcpcd/5501 CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd No contaminado 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [en línea] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [en línea] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [en línea] rhashtable_lookup_fast include/linux/rhashtable.h:672 [en línea] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [en línea] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [en línea] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [en línea] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [en línea] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [en línea] invoke_softirq kernel/softirq.c:435 [en línea] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [en línea] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_packet: arreglo vlan_get_protocol_dgram() vs MSG_PEEK La confirmación culpada olvidó el caso MSG_PEEK, lo que permitió un bloqueo [1] como lo encontró syzbot. Reelabore vlan_get_protocol_dgram() para que no toque skb en absoluto, de modo que pueda usarse desde muchas CPU en el mismo skb. Agregue un calificador const al argumento skb. [1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev: ------------[ corte aquí ]------------ ¡ERROR del kernel en net/core/skbuff.c:206! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 No contaminado 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [en línea] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Código: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [en línea] sock_recvmsg+0x22f/0x280 net/socket.c:1055 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [en línea] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [en línea] __do_sys_recvmmsg net/socket.c:3037 [en línea] __se_sys_recvmmsg net/socket.c:3030 [en línea] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_packet: arreglo vlan_get_tci() vs MSG_PEEK La confirmación culpada olvidó el caso MSG_PEEK, lo que permitió un bloqueo [1] como lo encontró syzbot. Reelabore vlan_get_tci() para que no toque skb en absoluto, de modo que pueda usarse desde muchas CPU en el mismo skb. Agregue un calificador const al argumento skb. [1] skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev: ------------[ corte aquí ]------------ ¡ERROR del kernel en net/core/skbuff.c:206! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 No contaminado 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [en línea] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Código: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565 packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0x22f/0x280 net/socket.c:1066 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814 ___sys_recvmsg net/socket.c:2856 [en línea] do_recvmmsg+0x426/0xab0 net/socket.c:2951 __sys_recvmmsg net/socket.c:3025 [en línea] __do_sys_recvmmsg net/socket.c:3048 [en línea] __se_sys_recvmmsg net/socket.c:3041 [en línea] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: restringir SO_REUSEPORT a sockets inet Después de la confirmación culpada, los sockets criptográficos podrían destruirse accidentalmente desde la devolución de llamada de RCU, como lo detectó zyzbot [1]. Intentar adquirir un mutex en la devolución de llamada de RCU no está permitido. Restringir la opción de socket SO_REUSEPORT a los sockets inet. La v1 de este parche admitía sockets TCP, UDP y SCTP, pero la prueba fcnal-test.sh necesitaba compatibilidad con RAW e ICMP. [1] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 Profundidad de anidación de RCU: 0, expected: 0 1 bloqueo retenido por ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:337 [en línea] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2561 [en línea] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preempción deshabilitada en: [] softirq_handle_begin kernel/softirq.c:402 [en línea] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 No contaminado 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Llamada Rastro: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [en línea] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [en línea] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [en línea] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: establecer indicadores ATTR_CTIME al configurar mtime David informó que la nueva advertencia de setattr_copy_mgtime aparece de la siguiente manera. [ 113.215316] ------------[ cortar aquí ]------------ [ 113.215974] ADVERTENCIA: CPU: 1 PID: 31 en fs/attr.c:300 setattr_copy+0x1ee/0x200 [ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 No contaminado 6.13.0-rc1+ #234 [ 113.220127] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [ 113.221530] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] [ 113.222220] RIP: 0010:setattr_copy+0x1ee/0x200 [ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0 [ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202 [ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003 [ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0 [ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa [ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38 [ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000 [ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000 [ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0 [ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 113.234797] Call Trace: [ 113.235116] [ 113.235393] ? __warn+0x73/0xd0 [ 113.235802] ? setattr_copy+0x1ee/0x200 [ 113.236299] ? report_bug+0xf3/0x1e0 [ 113.236757] ? handle_bug+0x4d/0x90 [ 113.237202] ? exc_invalid_op+0x13/0x60 [ 113.237689] ? asm_exc_invalid_op+0x16/0x20 [ 113.238185] ? setattr_copy+0x1ee/0x200 [ 113.238692] btrfs_setattr+0x80/0x820 [btrfs] [ 113.239285] ? get_stack_info_noinstr+0x12/0xf0 [ 113.239857] ? __module_address+0x22/0xa0 [ 113.240368] ? handle_ksmbd_work+0x6e/0x460 [ksmbd] [ 113.240993] ? __module_text_address+0x9/0x50 [ 113.241545] ? __module_address+0x22/0xa0 [ 113.242033] ? unwind_next_frame+0x10e/0x920 [ 113.242600] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 113.243268] notify_change+0x2c2/0x4e0 [ 113.243746] ? stack_depot_save_flags+0x27/0x730 [ 113.244339] ? set_file_basic_info+0x130/0x2b0 [ksmbd] [ 113.244993] set_file_basic_info+0x130/0x2b0 [ksmbd] [ 113.245613] ? process_scheduled_works+0xbe/0x310 [ 113.246181] ? worker_thread+0x100/0x240 [ 113.246696] ? kthread+0xc8/0x100 [ 113.247126] ? ret_from_fork+0x2b/0x40 [ 113.247606] ? ret_from_fork_asm+0x1a/0x30 [ 113.248132] smb2_set_info+0x63f/0xa70 [ksmbd] ksmbd está intentando configurar atime y mtime mediante notify_change sin configurar también ctime. Por lo tanto, este parche agrega indicadores ATTR_CTIME al configurar mtime para evitar una advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/core: corrige nuevas fugas de objetos damon_target en damon_commit_targets() Serie de parches "mm/damon/core: corrige fugas de memoria y entradas ignoradas de damon_commit_ctx()". Debido a dos errores en damon_commit_targets() y damon_commit_schemes(), que se llaman desde damon_commit_ctx(), algunas entradas de usuario pueden ignorarse y algunos objetos de memoria pueden filtrarse. Arréglelos. Tenga en cuenta que solo los usuarios de la interfaz sysfs de DAMON se ven afectados. Otros módulos de usuario de la API del núcleo de DAMON que se centran más en usos de producción simples y dedicados, incluidos DAMON_RECLAIM y DAMON_LRU_SORT, no utilizan la función con errores de la misma manera, por lo que no se ven afectados. Este parche (de 2): Cuando se agregan nuevos objetivos DAMON a través de damon_commit_targets(), los objetivos recién creados no se desasignan cuando falla la actualización de los datos internos (damon_commit_target()). Peor aún, incluso si la configuración se realiza correctamente, el nuevo objetivo no está vinculado al contexto. Por lo tanto, los nuevos objetivos siempre se filtran independientemente de la falla de configuración de los datos internos. Corrija las filtraciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: No advertir al cancelar el trabajo de WQ_MEM_RECLAIM del trabajador !WQ_MEM_RECLAIM Después de la confirmación 746ae46c1113 ("drm/sched: Marcar las colas de trabajo del programador con WQ_MEM_RECLAIM") amdgpu comenzó a ver la siguiente advertencia: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110 ... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720 ... [ ] La intención de la verificación realizada en check_flush_depedency es asegurar el progreso hacia adelante durante la recuperación de memoria, marcando los casos en los que un proceso de recuperación de memoria o un elemento de trabajo de recuperación de memoria se vacían de un contexto no marcado como seguro para la recuperación de memoria. Esto es correcto durante el vaciado, pero cuando se llama desde las rutas cancel(_delayed)_work_sync() es un falso positivo porque el trabajo ya se está ejecutando o no se ejecutará en absoluto. Por lo tanto, cancelarlo es seguro y podemos relajar los criterios de advertencia informando al asistente del contexto de llamada. Referencias: 746ae46c1113 ("drm/sched: Marcar las colas de trabajo del programador con WQ_MEM_RECLAIM")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Arreglar restauración de irq no válida en scx_ops_bypass() Al agregar el bloqueo de irqsave/restore externo, 0e7ffff1b811 ("scx: Arreglar la agresividad en scx_ops_bypass()") olvidó convertir un rq_unlock_irqrestore() interno en rq_unlock() que podría volver a habilitar IRQ prematuramente, lo que genera la siguiente advertencia: raw_local_irq_restore() llamado con IRQ habilitados ADVERTENCIA: CPU: 1 PID: 96 en kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Sched_ext: create_dsq (habilitando) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : warn_bogus_irq_restore+0x30/0x40 lr : warn_bogus_irq_restore+0x30/0x40 ... Rastreo de llamadas: warn_bogus_irq_restore+0x30/0x40 (P) warn_bogus_irq_restore+0x30/0x40 (L) scx_ops_bypass+0x224/0x3b8 scx_ops_enable.isra.0+0x2c8/0xaa8 bpf_scx_reg+0x18/0x30 ... marca de evento irq: 33739 hardirqs habilitados por última vez en (33739): [] scx_ops_bypass+0x174/0x3b8 hardirqs deshabilitados por última vez en (33738): [] _raw_spin_lock_irqsave+0xb4/0xd8 Elimina el _irqrestore() perdido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_core: Se corrige la función inactiva llamada desde un contexto no válido. Esto modifica hci_cb_list para que no use mutex hci_cb_list_lock para evitar errores como el siguiente: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/mutex.c:585 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 4 locks held by kworker/u9:2/5070: #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline] #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335 #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline] #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335 #2: ffff8880665d0078 (&hdev->lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914 #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915 CPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: hci0 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 __might_resched+0x5d4/0x780 kernel/sched/core.c:10187 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752 hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline] hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939 hci_event_func net/bluetooth/hci_event.c:7514 [inline] hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569 hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: adv7511: Se corrige el use-after-free en adv7533_attach_dsi() El puntero host_node se asignó y liberó en adv7533_parse_dt() y, posteriormente, adv7533_attach_dsi() utiliza el mismo. Corrija este problema de use-after-free eliminando of_node_put() en adv7533_parse_dt() y llamando a of_node_put() en la ruta de error de probe() y también en remove().