Created attachment 210257 [details] Information collected by savecore(8). Hello, when trying to execute a remote firefox (from a debian based system) via ssh(1) the kernel panics immediately. Executing xlock(1) from the same remote system does not trigger the panic. The kernel is a 13.0-CURRENT #1 r356122M: Fri Dec 27 14:55:13 CET 2019 root@myhost:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG and the panic backtrace is always like panic: page fault cpuid = 2 time = 1577461608 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b1f123c0 vpanic() at vpanic+0x17e/frame 0xfffffe00b1f12420 panic() at panic+0x43/frame 0xfffffe00b1f12480 trap_fatal() at trap_fatal+0x386/frame 0xfffffe00b1f124e0 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00b1f12550 trap() at trap+0x288/frame 0xfffffe00b1f12680 calltrap() at calltrap+0x8/frame 0xfffffe00b1f12680 --- trap 0xc, rip = 0xffffffff828ce27f, rsp = 0xfffffe00b1f12750, rbp = 0xfffffe00b1f12780 --- linux_file_close() at linux_file_close+0x1f/frame 0xfffffe00b1f12780 _fdrop() at _fdrop+0x1a/frame 0xfffffe00b1f127a0 closef() at closef+0x26d/frame 0xfffffe00b1f12830 unp_freerights() at unp_freerights+0x3a/frame 0xfffffe00b1f12870 unp_externalize() at unp_externalize+0x215/frame 0xfffffe00b1f12900 soreceive_generic() at soreceive_generic+0x5b0/frame 0xfffffe00b1f129c0 soreceive() at soreceive+0x44/frame 0xfffffe00b1f129e0 dofileread() at dofileread+0x81/frame 0xfffffe00b1f12a30 kern_readv() at kern_readv+0x49/frame 0xfffffe00b1f12a70 sys_read() at sys_read+0x83/frame 0xfffffe00b1f12ac0 amd64_syscall() at amd64_syscall+0x3a3/frame 0xfffffe00b1f12bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00b1f12bf0 --- syscall (3, FreeBSD ELF64, sys_read), rip = 0x8007e9f9a, rsp = 0x7fffffff6ba8, rbp = 0x7fffffff6be0 --- KDB: enter: panic Regards, Ralf
The linuxkpi file close function doesn't handle a null thread argument. As noted in e.g., closef() and devfs_close_f(), the unix domain socket code passes a null thread pointer to fo_close, so linux_file_close() should try to handle it. I think using curthread is fine in this case. diff --git a/sys/compat/linuxkpi/common/src/linux_compat.c b/sys/compat/linuxkpi/common/src/linux_compat.c index 614148ae212e..7a4c0986bb08 100644 --- a/sys/compat/linuxkpi/common/src/linux_compat.c +++ b/sys/compat/linuxkpi/common/src/linux_compat.c @@ -1498,6 +1498,8 @@ linux_file_close(struct file *file, struct thread *td) KASSERT(file_count(filp) == 0, ("File refcount(%d) is not zero", file_count(filp))); + if (td == NULL) + td = curthread; error = 0; filp->f_flags = file->f_flag; linux_set_current(td);
Affects sys/compat/linuxkpi, so assign to emulation@.
(In reply to Mark Johnston from comment #1) Just to be sure I have reproduced the panic. Applied your patch and tried again. With your patch applied the panic does not happen any more. Thank you. Should I close this bug report now or wait till the patch is in the repository?
(In reply to iz-rpi03 from comment #3) Thanks for testing. I'll close the PR once the patch is committed and merged to a stable branch.
https://reviews.freebsd.org/D23178
A commit references this bug: Author: markj Date: Wed Jan 15 15:31:35 UTC 2020 New revision: 356760 URL: https://svnweb.freebsd.org/changeset/base/356760 Log: Handle a NULL thread pointer in linux_close_file(). This can happen if a file is closed during unix socket GC. The same bug was fixed for devfs descriptors in r228361. PR: 242913 Reported and tested by: iz-rpi03@hs-karlsruhe.de Reviewed by: hselasky, kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D23178 Changes: head/sys/compat/linuxkpi/common/src/linux_compat.c
A commit references this bug: Author: markj Date: Wed Jan 22 00:30:27 UTC 2020 New revision: 356953 URL: https://svnweb.freebsd.org/changeset/base/356953 Log: MFC r356760: Handle a NULL thread pointer in linux_close_file(). PR: 242913 Changes: _U stable/12/ stable/12/sys/compat/linuxkpi/common/src/linux_compat.c
Thank you for the report.
A commit references this bug: Author: markj Date: Wed Jan 22 15:51:24 UTC 2020 New revision: 356987 URL: https://svnweb.freebsd.org/changeset/base/356987 Log: MFC r356760: Handle a NULL thread pointer in linux_close_file(). PR: 242913 Changes: _U stable/11/ stable/11/sys/compat/linuxkpi/common/src/linux_compat.c
*** Bug 246557 has been marked as a duplicate of this bug. ***
Author: gordon Date: Wed Jul 8 19:57:24 2020 New Revision: 363023 URL: https://svnweb.freebsd.org/changeset/base/363023 Log: Fix kernel panic in LinuxKPI subsystem. Approved by: so Security: FreeBSD-EN-20:14.linuxpki Modified: releng/11.3/sys/compat/linuxkpi/common/src/linux_compat.c releng/12.1/sys/compat/linuxkpi/common/src/linux_compat.c
Hi, The errata notice has broken links for this. https://www.freebsd.org/security/advisories/FreeBSD-EN-20:14.linuxkpi.asc I believe the links are correct, however the patch and corresponding signature file are misspelled. They should be "kpi" instead of "pki" (just like the errata notice link, itself which is also misspelled). Thank you, Teran