linux-kernel - Re: [PATCH] tty_port: Restore tty port default ops on unregistering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200210145445.GA22240@localhost>
Date:   Mon, 10 Feb 2020 15:54:45 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty_port: Restore tty port default ops on unregistering

On Tue, Feb 04, 2020 at 07:03:37PM +0100, Loic Poulain wrote:
> On Tue, 4 Feb 2020 at 10:47, Johan Hovold <johan@...nel.org> wrote:
> >
> > On Wed, Jan 29, 2020 at 09:07:04AM +0100, Loic Poulain wrote:
> > > When a port is unregistered from serdev, its serdev specific client_ops
> > > pointer is nullified, which can lead to future null pointer dereference.
> > > Fix that by restoring default client_ops when port is unregistered from
> > > serdev.
> >
> > Hmm, yeah, this seems like something we should fix as 8250 appears to
> > allow reregistering ports, but...
> >
> > > port registering/unregistering can happen several times, at least it
> > > happens when statically registered 8250 ISA port are replaced at boot
> > > time by e.g. device-tree defined 8250 ports.
> >
> > How did the serdev controller get registered in the first place here if
> > you're talking about statically registered 8250 ISA ports (i.e. where is
> > the client defined)?
> >
> > Did you actually ever hit this one?
> 
> Yes, but never in the mainline.

Ok, thanks for confirming.

> Actually a set of changes [1] [2] in the AOSP common kernel mades the tty
> ports bound to serdev by default, except for one(s) with console attached.
> So with some platforms the ISA ttyS0 is firstly registered with serdev and
> then replaced (unregistered/registered) later in the boot by the 8250 port
> enumerated from the fdt and used for console (expecting default tty ops).
> 
> TBH I disagree with the way it has been done in the AOSP, but it highlighted
> this possible null ops path, which can be fixed either by resetting the
> default ops on tty port unregister (this patch), or on register.

Yeah, those AOSP commits doesn't make much sense, especially not the
first one since it doesn't provide any means to define the client.

> [1]
> https://android.googlesource.com/kernel/common/+/c550a54f23026e92633c5145e8b919cf590a5624
> [2]
> https://android.googlesource.com/kernel/common/+/cc3b00864e3b316ff106f948834d7e0cc6244921

I spent some time looking into this today, and this doesn't seem to be
an issue for mainline unless we are reloading 8250 drivers.

Specifically, the statically defined ports that 8250 core would register
when an 8250 driver is being unbound could end up with a NULL client
ops.

This is seems unlikely to be an issue in practice, but I think we should
plug this nonetheless.

I already fixed the related issue of serdev not resetting the client_ops
on failed registration in aee5da783878 ("serdev: fix tty-port client
deregistration"), and I think the unregistration case should be handled
similarly by the serdev ttyport controller driver (rather than by tty
core).

I've prepared a patch with a commit message outlining how this may
affect mainline and included a stable tag. This should fix the issue in
AOSP as well, even that first commit [1] above really should be
reverted.

Johan