Bug 242913 - Immediate page fault panic caused by executing firefox via ssh
Summary: Immediate page fault panic caused by executing firefox via ssh
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Mark Johnston
Keywords: panic, patch
: 246557 (view as bug list)
Depends on:
Reported: 2019-12-27 16:30 UTC by iz-rpi03
Modified: 2020-05-19 13:42 UTC (History)
2 users (show)

See Also:

Information collected by savecore(8). (169.33 KB, text/plain)
2019-12-27 16:30 UTC, iz-rpi03
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description iz-rpi03 2019-12-27 16:30:39 UTC
Created attachment 210257 [details]
Information collected by savecore(8).


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

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
Comment 1 Mark Johnston freebsd_committer 2020-01-13 20:57:53 UTC
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;
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2020-01-14 11:13:00 UTC
Affects sys/compat/linuxkpi, so assign to emulation@.
Comment 3 iz-rpi03 2020-01-14 11:33:23 UTC
(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?
Comment 4 Mark Johnston freebsd_committer 2020-01-14 20:12:33 UTC
(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.
Comment 5 Mark Johnston freebsd_committer 2020-01-14 20:36:03 UTC
Comment 6 commit-hook freebsd_committer 2020-01-15 15:31:58 UTC
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

  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

Comment 7 commit-hook freebsd_committer 2020-01-22 00:31:36 UTC
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

  MFC r356760:
  Handle a NULL thread pointer in linux_close_file().

  PR:	242913

_U  stable/12/
Comment 8 Mark Johnston freebsd_committer 2020-01-22 00:36:42 UTC
Thank you for the report.
Comment 9 commit-hook freebsd_committer 2020-01-22 15:51:33 UTC
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

  MFC r356760:
  Handle a NULL thread pointer in linux_close_file().

  PR:	242913

_U  stable/11/
Comment 10 Mark Johnston freebsd_committer 2020-05-19 13:42:46 UTC
*** Bug 246557 has been marked as a duplicate of this bug. ***