Re: kern/58466: Kernel panic in ucompoll

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR kern/58466; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Paul Ripke <stix%stix.id.au@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
	hannken%NetBSD.org@localhost
Subject: Re: kern/58466: Kernel panic in ucompoll
Date: Thu, 25 Jul 2024 05:04:13 +0000

 > Jul 24 21:48:55 slave /netbsd: [ 2260291.0658539] uvm_fault(0xffff92260e4=
 31b38, 0x0, 1) -> e
 
 The 0x0 here means something is trying to use the null page.
 
 > Jul 24 21:48:55 slave /netbsd: [ 2260291.0658539] trap type 6 code 0 rip =
 0xffffffff804957ff cs 0x8 rflags 0x10246 cr2 0xe8 ilevel 0 rsp 0xffffcb8450=
 369bf0
 
 The cr2 here is the actual address, 0xe8.
 
 > Jul 24 21:48:55 slave /netbsd: [ 2260291.0678538] ucompoll() at netbsd:uc=
 ompoll+0x2a
 
 This is the faulting instruction, and:
 
 (gdb) x/i ucompoll+0x2a
    0xffffffff804be468 <ucompoll+42>:    mov    0xe8(%rax),%edi
 (gdb) print &((struct ucom_softc *)0)->sc_tty
 $2 =3D (struct tty **) 0xe8
 (gdb) list *(ucompoll+0x2a)
 0xffffffff804be468 is in ucompoll (/home/riastradh/netbsd/current/src/sys/d=
 ev/usb/ucom.c:849).
 844     int
 845     ucompoll(dev_t dev, int events, struct lwp *l)
 846     {
 847             const int unit =3D UCOMUNIT(dev);
 848             struct ucom_softc * const sc =3D device_lookup_private(&uco=
 m_cd, unit);
 849             struct tty *tp =3D sc->sc_tty;
 850    =20
 851             UCOMHIST_FUNC(); UCOMHIST_CALLED();
 852    =20
 853             return (*tp->t_linesw->l_poll)(tp, events, l);
 
 So sc is null, and it crashes trying to compute sc->sc_tty.
 
 But how is sc null?  It shouldn't be possible to enter ucompoll
 without a device private for the unit number -- either:
 
 (a) there has never been such a unit, in which case there should be no
     paths to ucompoll with this number; or
 
 (b) that unit is being detached concurrently, in which case spec_poll
     should either
 
      i. acquire a reference that blocks detach from finishing until
         ucompoll done (by holding up spec_io_drain which holds up
         spec_close which holds up vdevgone), or
 
     ii. (possibly block and then) fail with POLLERR, via failure in
         spec_io_enter -> vdead_check, without entering ucompoll; or
 
 (c) that unit has been detached, in which case the vnode has been
     revoked with vdevgone in ucomdetach and should no longer be
     accessible as such and ucompoll should again not be entered.
 
 Obviously I'm missing a path where control can sneak into ucompoll
 with a detached unit, though!