Re: Samba kernel panics.

On Tue, Nov 17, 2020 at 10:01 PM Mark Johnston <markj_at_freebsd.org> wrote:
>
> On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote:
> > On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote:
> > > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server
> > > craches the server.
> > > I did rebuild samba 4.11 but that does not help.
> > >
> > > The output on the console is the following.
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid =3; apic id = 06
> > > fault virtual address    = 0x803a122b8
> > > fault code                   = supervisor read instruction, protection
> > > violation
> > > instruction pointer      = 0x20:0x803a122b8
> > > stack pointer               = 0x28:0xfffffe0127733a50
> > > frame pointer              = 0x28:0x803a122b0
> > > code segment             = base 0x0, limit 0xfffff, type 0x1b
> > >                                    = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags          = 17340 (smbd)
> > > trap number                = 12
> > > panic: page fault
> > > cpuid =3
> > > time = 1605632521
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame
> > > 0xfffffe0127733700
> > > vpanic() at vpanic+0x182/frame 0xfffffe0127733750
> > > panic() at panic+0x43/frame 0xfffffe01277337b0
> > > trap_fatal() at trap_fatal+0x387/frame 0xfffffe0127733810
> > > trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0127733870
> > > trap() at trap+0x27d/frame 0xfffffe0127733980
> > > calltrap() at caltrap+0x8/frame 0xfffffe0127733980
> > > --- trap 0xc, rip = 0x803a122b8, rsp = 0xfffffe0127733a50, rbp = 0x803a122b0
> > > ---
> > > KDB: enter: panic
> > > [ thread pid 17340 tid 101772 ]
> > > stopped at        kdb_enter+0x37: movq     $0,0x1fa9446(%rip)
> > > db>
> >
> > This looks like SMEP catching an issue, but it is not clear why.
>
> Probably fixed by r367783?  The bug would have partially overwritten the
> stack frame, resulting in a jump to a user address after a return.
>

Ah, yes, sorry that I missed this -- smbd was in-fact the exact
program that the reporter noted observed it with, and what the fix was
confirmed with. Sorry for the breakage~

Kyle Evans