Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hsr: debe asignar más bytes para la compatibilidad con RedBox el commit culpada olvidó cambiar hsr_init_skb() para asignar skb más grande para el caso de RedBox. De hecho, send_hsr_supervision_frame() agregará dos componentes adicionales (struct hsr_sup_tlv y struct hsr_sup_payload) syzbot informó el siguiente fallo: skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ 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 NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor No contaminado 6.12.0-syzkaller #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206 Código: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: skb_over_panic net/core/skbuff.c:211 [en línea] skb_put+0x174/0x1b0 net/core/skbuff.c:2617 send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342 hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436 call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794 expire_timers kernel/time/timer.c:1845 [en línea] __run_timers+0x6e8/0x930 kernel/time/timer.c:2419 __run_timer_base kernel/time/timer.c:2430 [en línea] __run_timer_base kernel/time/timer.c:2423 [en línea] run_timer_base+0x111/0x190 kernel/time/timer.c:2439 run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449 handle_softirqs+0x213/0x8f0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [en línea] anybody_softirq kernel/softirq.c:428 [en línea] __irq_exit_rcu kernel/softirq.c:637 [en línea] anyone_exit_rcu+0xbb/0x120 kernel/softirq.c:649 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: net/smc: inicializar close_work antes para evitar advertencias Encontramos una advertencia que indicaba que close_work se canceló antes de la inicialización. ADVERTENCIA: CPU: 7 PID: 111103 en kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: eventos smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Rastreo de llamadas: ? __wake_up_common+0x7a/0x190 ? trabajo_ocupado+0x80/0x80 __cancelar_temporizador_trabajo+0xe3/0x160 smc_cerrar_cancelar_trabajo+0x1a/0x70 [smc] smc_cerrar_aborto_activo+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] proceso_uno_trabajo+0x19e/0x340 subproceso_trabajador+0x30/0x370 ? proceso_uno_trabajo+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 Esto se debe a que cuando se activa smc_close_cancel_work, p. ej., el controlador RDMA es rmmod y se termina el LGR, conn->close_work se vacía antes de la inicialización, lo que genera WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn para conn en lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) Solucione esto inicializando close_work antes de establecer la conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: evitar un UAF potencial en default_operstate() syzbot informó un UAF en default_operstate() [1] El problema es una carrera entre el desmantelamiento de dispositivos y redes. Después de llamar a __rtnl_unlock() desde netdev_run_todo(), no podemos asumir que las redes de cada dispositivo aún estén activas. Asegúrese de que el dispositivo no esté en estado NETREG_UNREGISTERED y agregue un ASSERT_RTNL() antes de la llamada a __dev_get_by_index(). Es posible que movamos este ASSERT_RTNL() a __dev_get_by_index() en el futuro. [1] ERROR: KASAN: slab-use-after-free en __dev_get_by_index+0x5d/0x110 net/core/dev.c:852 Lectura de tamaño 8 en la dirección ffff888043eba1b0 por la tarea syz.0.0/5339 CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 No contaminado 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 imprimir_dirección_descripción mm/kasan/report.c:378 [en línea] imprimir_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __dev_get_by_index+0x5d/0x110 net/core/dev.c:852 estado_operación_predeterminado net/core/link_watch.c:51 [en línea] rfc2863_policy+0x224/0x300 net/core/link_watch.c:67 linkwatch_do_dev+0x3e/0x170 net/core/link_watch.c:170 netdev_run_todo+0x461/0x1000 net/core/dev.c:10894 rtnl_unlock net/core/rtnetlink.c:152 [en línea] rtnl_net_unlock include/linux/rtnetlink.h:133 [en línea] rtnl_dellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2541 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [en línea] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [en línea] __sock_sendmsg+0x221/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [en línea] __sys_sendmsg+0x269/0x350 net/socket.c:2669 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 RIP: 0033:0x7f2a3cb80809 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 Asignado por la tarea 5339: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [en línea] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc incluir/linux/kasan.h:260 [en línea] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314 kmalloc_noprof incluir/linux/slab.h:901 [en línea] kmalloc_array_noprof incluir/linux/slab.h:945 [en línea] netdev_create_hash net/core/dev.c:11870 [en línea] netdev_init+0x10c/0x250 net/core/dev.c:11890 ops_init+0x31e/0x590 net/core/net_namespace.c:138 setup_net+0x287/0x9e0 net/core/net_namespace.c:362 copy_net_ns+0x33f/0x570 net/core/net_namespace.c:500 crear_nuevos_espacios_de_nombres+0x425/0x7b0 kernel/nsproxy.c:110 dejar_de_compartir_espacios_de_nombres_nsproxy+0x124/0x180 kernel/nsproxy.c:228 dejar_de_compartir_ksys+0x57d/0xa70 kernel/fork.c:3314 __do_sys_unshare kernel/fork.c:3385 [en línea] __se_sys_unshare kernel/fork.c:3383 [en línea] __x64_sys_unshare+0x38/0x40 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: inicializar close_work antes para evitar advertencias Encontramos una advertencia que indicaba que close_work se canceló antes de la inicialización. ADVERTENCIA: CPU: 7 PID: 111103 en kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: eventos smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Rastreo de llamadas: ? __wake_up_common+0x7a/0x190 ? trabajo_ocupado+0x80/0x80 __cancelar_temporizador_trabajo+0xe3/0x160 smc_cerrar_cancelar_trabajo+0x1a/0x70 [smc] smc_cerrar_aborto_activo+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] proceso_uno_trabajo+0x19e/0x340 subproceso_trabajador+0x30/0x370 ? proceso_uno_trabajo+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 Esto se debe a que cuando se activa smc_close_cancel_work, p. ej., el controlador RDMA es rmmod y se termina el LGR, conn->close_work se vacía antes de la inicialización, lo que genera WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn para conn en lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) Solucione esto inicializando close_work antes de establecer la conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: Se corrige el use-after-free del socket del kernel en cleanup_bearer(). syzkaller informó un use-after-free del socket del kernel UDP en cleanup_bearer() sin reproducción. [0][1] Cuando bearer_disable() llama a tipc_udp_disable(), la desinfección del socket del kernel UDP se pospone mediante el trabajo que llama a cleanup_bearer(). tipc_net_stop() espera a que finalicen dichos trabajos comprobando tipc_net(net)->wq_count. Sin embargo, el trabajo disminuye el recuento demasiado pronto antes de liberar el socket del kernel, desbloqueando cleanup_net() y dando como resultado un use-after-free. Muevamos la disminución después de liberar el socket en cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf tiene 1/1 usuarios en sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: ERROR: KMSAN: use-after-free en udp_hashslot include/net/udp.h:85 [en línea] ERROR: KMSAN: use-after-free en udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [en línea] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [en línea] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 proceso_one_work kernel/workqueue.c:3229 [en línea] proceso_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit se creó en: slab_free_hook mm/slub.c:2269 [en línea] slab_free mm/slub.c:4580 [en línea] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [en línea] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [en línea] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 No contaminado 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 01/04/2014 Cola de trabajo: eventos cleanup_bearer

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: corrige la fuga de memoria cuando falla la creación de un nuevo control Ahora, aunque falla la creación de un nuevo control, no hemos liberado el conjunto de etiquetas ocupado por admin_q, aquí intentamos solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: wacom: solución cuando se obtiene el nombre del producto, puede haber un puntero nulo. Debido a que ciertos dispositivos informan incorrectamente dev->product, se producen desreferencias de puntero nulo cuando dev->product está vacío, lo que provoca posibles fallas del sistema. Este problema se encontró en el dispositivo EXCELSIOR DL37-D05 con placa base Loongson-LS3A6000-7A2000-DL37. Registros del núcleo: [56.470885] usb 4-3: nuevo dispositivo USB de velocidad completa número 4 que utiliza ohci-pci [56.671638] usb 4-3: error de lectura del descriptor de cadena 0: -22 [56.671644] usb 4-3: nuevo dispositivo USB encontrado, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [56.671647] usb 4-3: nuevas cadenas de dispositivos USB: Mfr=1, Product=2, SerialNumber=3 [56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: dispositivo USB HID v1.10 [HID 056a:0374] activado usb-0000:00:05.0-3/input0 [ 56.697719] CPU 2 No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [ 56.697732] Oops[#1]: [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015 [ 56.697737] Nombre del hardware: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 11/10/2024 [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [ 56.697745] t0 ffff800004818b2d t1 00000000000000000 t2 0000000000000003 t3 0000000000000005 [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 00000000000000000 t7 00000000000000000 [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom] [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120 [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE) [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 56.697835] BADV: 0000000000000000 [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 56.697838] Módulos vinculados en: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore leds de entrada mousedev clase led joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs tablas ip tablas x superposición amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit [ 56.697887] Proceso (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [ 56.697890] Pila: 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [ 56.697896] 000000000000000 0000011fffffffd 000000000000000 000000000000000 [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [ 56.697911] 9000001000ba000 ffff800004f9ce58 000000000000000 ffff800005470440 [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [ 56.697921] 000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 000000000000000 [ 56.697931] 90000001000bb8d0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la escritura fuera de los límites en ksmbd_vfs_stream_write. Un desplazamiento del cliente podría ser un valor negativo, lo que podría permitir escribir datos fuera de los límites del búfer asignado. Tenga en cuenta que este problema se produce al configurar 'vfs objects = streams_xattr parameter' en ksmbd.conf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se ha corregido la lectura fuera de los límites en ksmbd_vfs_stream_read. Un desplazamiento del cliente podría ser un valor negativo, lo que podría provocar una lectura fuera de los límites desde stream_buf. Tenga en cuenta que este problema se produce al configurar 'vfs objects = streams_xattr parameter' en ksmbd.conf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: can_set_termination(): permitir GPIO inactivos En el commit 6e86a1543c37 ("can: dev: proporcionar soporte de terminación basado en GPIO opcional") se agregó soporte de terminación basado en GPIO. Sin ninguna razón en particular, ese parche usa gpiod_set_value() para configurar el GPIO. Esto lleva a la siguiente advertencia, si el sistema usa un GPIO inactivo, es decir, detrás de un expansor de puerto I2C: | ADVERTENCIA: CPU: 0 PID: 379 en /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip No contaminado 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c Reemplace gpiod_set_value() por gpiod_set_value_cansleep() para permitir el uso de GPIO inactivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Agregar huge_pte_clear() específico de la arquitectura. Al ejecutar las pruebas automáticas mm run_vmtests.sh, aparece el siguiente error: BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 página volcada porque: PAGE_FLAGS_CHECK_AT_FREE indicador(es) establecido(s) Módulos vinculados en: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests No contaminado 6.12.0 #184 Nombre del hardware: QEMU Máquina virtual QEMU, BIOS desconocido 2/2/2022 Pila: 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 000000000000001 000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000ffffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 000000000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 000000000000000 0000000000071c1d ... Seguimiento de llamadas: [<9000000000223a94>] show_stack+0x5c/0x180 [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0 [<900000000056aa08>] página_incorrecta+0x1a0/0x1f0 [<9000000000574978>] folios_sin_referencia_gratis+0xbf0/0xd20 [<90000000004e65cc>] folios_colocar_referencias+0x1a4/0x2b8 [<9000000000599a0c>] páginas_y_caché_de_intercambio_gratis+0x164/0x260 [<9000000000547698>] vaciado_de_páginas_por_lotes_tlb+0xa8/0x1c0 [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218 [<9000000000543cb8>] salida_mmap+0x1a0/0x360 [<9000000000247658>] __mmput+0x78/0x200 [<900000000025583c>] hacer_salir+0x43c/0xde8 [<9000000000256490>] hacer_grupo_salir+0x68/0x110 [<9000000000256554>] grupo_salir_sistema+0x1c/0x20 [<9000000001c413b4>] hacer_llamada_sistema+0x94/0x130 [<90000000002216d8>] handle_syscall+0xb8/0x158 Deshabilitando la depuración de bloqueo debido a una contaminación del kernel ERROR: pgtables_bytes distintos de cero al liberar mm: -16384 En el sistema LoongArch, una entrada pte enorme no válida debe ser invalid_pte_table o un solo bit _PAGE_HUGE en lugar de un valor cero. Y debería ser lo mismo con una entrada pmd no válida, ya que pmd_none() es llamada por la función free_pgd_range() y pmd_none() devuelve 0 por huge_pte_clear(). Por lo tanto, un solo bit _PAGE_HUGE también se trata como una tabla pte válida y free_pte_range() se llamará en free_pmd_range(). free_pmd_range() pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); if (pmd_none_or_clear_bad(pmd)) continue; free_pte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end); Aquí invalid_pte_table se utiliza tanto para entradas pte enormes no válidas como para entradas pmd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: inodo libre cuando ocfs2_get_init_inode() falla syzbot informa inodos ocupados después del desmontaje, para el commit 9c89fe0af826 ("ocfs2: Error de gestión de dquot_initialize()") olvidó llamar a iput() cuando new_inode() tuvo éxito y dquot_initialize() falló.