Bug 242913 - Immediate page fault panic caused by executing firefox via ssh
Summary: Immediate page fault panic caused by executing firefox via ssh
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Mark Johnston
URL:
Keywords: panic, patch
Depends on:
Blocks:
 
Reported: 2019-12-27 16:30 UTC by iz-rpi03
Modified: 2020-01-15 15:31 UTC (History)
1 user (show)

See Also:


Attachments
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).

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
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;
        linux_set_current(td);
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
https://reviews.freebsd.org/D23178
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

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