Created attachment 242039 [details] dmesg from a dual-EPYC PowerEdge R7525 I'm getting a couple of panics in the linux_sys_futex code when using the VS Code Remote SSH extension from my Linux machine to my FreeBSD 14-CURRENT PowerEdge R7525 system. I've attached the dmesg. FreeBSD maxamd 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n262792-7e0f8b79b773-dirty: Sun May 7 07:58:16 MDT 2023 bcran@maxamd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 First is "mutex umtxql not owned": root@maxamd:/var/crash # kgdb -n 0 ... Unread portion of the kernel message buffer: panic: mutex umtxql not owned at /usr/src/sys/kern/kern_umtx.c:510 cpuid = 136 time = 1683471469 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0416344c40 vpanic() at vpanic+0x152/frame 0xfffffe0416344c90 panic() at panic+0x43/frame 0xfffffe0416344cf0 __mtx_assert() at __mtx_assert+0xa0/frame 0xfffffe0416344d00 umtxq_remove_queue() at umtxq_remove_queue+0x4a/frame 0xfffffe0416344d30 linux_sys_futex() at linux_sys_futex+0x5ae/frame 0xfffffe0416344e00 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0416344f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0416344f30 --- syscall (202, Linux ELF64, linux_sys_futex), rip = 0x801e0bde2, rsp = 0xc86803da0, rbp = 0x168ed58 --- KDB: enter: panic Uptime: 56m5s Dumping 9776 out of 260660 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, -------------------------------------------- Second is "_mtx_lock_sleep: recursed on non-recursive mutex umtxql" Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex umtxql @ /usr/src/sys/compat/linux/linux_futex.c:718 cpuid = 196 time = 1683477614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe04ba90bba0 vpanic() at vpanic+0x152/frame 0xfffffe04ba90bbf0 panic() at panic+0x43/frame 0xfffffe04ba90bc50 __mtx_lock_sleep() at __mtx_lock_sleep+0x41f/frame 0xfffffe04ba90bce0 __mtx_lock_flags() at __mtx_lock_flags+0xe9/frame 0xfffffe04ba90bd30 linux_sys_futex() at linux_sys_futex+0x6c5/frame 0xfffffe04ba90be00 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe04ba90bf30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe04ba90bf30 --- syscall (202, Linux ELF64, linux_sys_futex), rip = 0x80160c1ee, rsp = 0xc8d801c08, rbp = 0 --- KDB: enter: panic Uptime: 5m8s Dumping 9500 out of 260660 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
Do you have a core? Assuming keys are process shared.
Yes, I have cores. I've uploaded them to https://people.freebsd.org/~bcran/crashes/20230507/ .
commit 62f40433ab47ad4a9694a22a0313d57661502ca1 Author: Olivier Certner <olce@FreeBSD.org> AuthorDate: Wed Sep 4 14:38:12 2024 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: Wed Sep 4 14:38:12 2024 +0000 umtx: shm: Fix use-after-free due to multiple drops of the registry reference umtx_shm_unref_reg_locked() would unconditionally drop the "registry" reference, tied to USHMF_LINKED. This is not a problem for caller umtx_shm_object_terminated(), which operates under the 'umtx_shm_lock' lock end-to-end, but it is for indirect caller umtx_shm(), which drops the lock between umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that deregisters the umtx shared region (from 'umtx_shm_registry'; umtx_shm_find_reg() only finds registered shared mutexes). Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg() but before umtx_shm_unref_reg(true), would then decrease twice the reference count for the single reference standing for the shared mutex's registration. Reported by: Synacktiv Reviewed by: kib Approved by: emaste (mentor) Security: FreeBSD-SA-24:14.umtx Security: CVE-2024-43102 Security: CAP-01 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46126