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-07-09 04:21 UTC (History)
4 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. ***
Comment 11 Ed Maste freebsd_committer 2020-07-08 20:08:31 UTC
Author: gordon
Date: Wed Jul  8 19:57:24 2020
New Revision: 363023
URL: https://svnweb.freebsd.org/changeset/base/363023

  Fix kernel panic in LinuxKPI subsystem.

  Approved by:  so
  Security:     FreeBSD-EN-20:14.linuxpki

Comment 12 Teran McKinney 2020-07-09 04:21:24 UTC

The errata notice has broken links for this.


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,