From: Greg KH <gregkh@linuxfoundation.org>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>, Jiri Slaby <jslaby@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-serial <linux-serial@vger.kernel.org>
Subject: Re: [GIT PULL] TTY/Serial driver fixes for 4.11-rc4
Date: Fri, 14 Apr 2017 14:30:29 +0200 [thread overview]
Message-ID: <20170414123029.GA17217@kroah.com> (raw)
In-Reply-To: <CAOMGZ=G9t7ih=ydr=fkKn6cbgu5-qbdQs7XChmn=d598H95QVA@mail.gmail.com>
On Fri, Apr 14, 2017 at 11:41:26AM +0200, Vegard Nossum wrote:
> On 13 April 2017 at 20:34, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 13, 2017 at 09:07:40AM -0700, Linus Torvalds wrote:
> >> On Thu, Apr 13, 2017 at 3:50 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> >> >
> >> > I've bisected a syzkaller crash down to this commit
> >> > (5362544bebe85071188dd9e479b5a5040841c895). The crash is:
> >> >
> >> > [ 25.137552] BUG: unable to handle kernel paging request at 0000000000002280
> >> > [ 25.137579] IP: mutex_lock_interruptible+0xb/0x30
> >>
> >> It would seem to be the
> >>
> >> if (mutex_lock_interruptible(&ldata->atomic_read_lock))
> >>
> >> call in n_tty_read(), the offset is about right for a NULL 'ldata'
> >> pointer (it's a big structure, it has a couple of character buffers of
> >> size N_TTY_BUF_SIZE).
> >>
> >> I don't see the obvious fix, so I suspect at this point we should just
> >> revert, as that commit seems to introduce worse problems that it is
> >> supposed to fix. Greg?
> >
> > Unless Dmitry has a better idea, I will just revert it and send you the
> > pull request in a day or so.
>
> I don't think we need to rush a revert, I'd hope there's a way to fix
> it properly.
For this late in the release cycle, for something as complex as tty
ldisc handling, for an issue that has been present for over a decade,
the safest thing right now is to go back to the old well-known code by
applying a revert :)
> So the original problem is that the vmalloc() in n_tty_open() can
> fail, and that will panic in tty_set_ldisc()/tty_ldisc_restore()
> because of its unwillingness to proceed if the tty doesn't have an
> ldisc.
>
> Dmitry fixed this by allowing tty->ldisc == NULL in the case of memory
> allocation failure as we can see from the comment in tty_set_ldisc().
>
> Unfortunately, it would appear that some other bits of code do not
> like tty->ldisc == NULL (other than the crash in this thread, I saw
> 2-3 similar crashes in other functions, e.g. poll()). I see two
> possibilities:
>
> 1) make other code handle tty->ldisc == NULL.
>
> 2) don't close/free the old ldisc until the new one has been
> successfully created/initialised/opened/attached to the tty, and
> return an error to userspace if changing it failed.
>
> I'm leaning towards #2 as the more obviously correct fix, it makes
> tty_set_ldisc() transactional, the fix seems limited in scope to
> tty_set_ldisc() itself, and we don't need to make every other bit of
> code that uses tty->ldisc handle the NULL case.
That sounds reasonable to me, care to work on a patch for this?
thanks,
greg k-h
next prev parent reply other threads:[~2017-04-14 12:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-26 11:04 [GIT PULL] TTY/Serial driver fixes for 4.11-rc4 Greg KH
2017-04-13 10:50 ` Vegard Nossum
2017-04-13 16:07 ` Linus Torvalds
2017-04-13 18:34 ` Greg KH
2017-04-14 9:41 ` Vegard Nossum
2017-04-14 12:30 ` Greg KH [this message]
2017-05-02 16:35 ` Dmitry Vyukov
2017-05-02 21:52 ` Vegard Nossum
2017-05-03 11:25 ` Dmitry Vyukov
2017-05-03 12:01 ` Greg KH
2017-05-30 9:21 ` Dmitry Vyukov
2017-05-30 12:09 ` Alan Cox
2017-05-31 8:39 ` Dmitry Vyukov
2017-05-31 11:16 ` Greg KH
2017-05-31 15:04 ` Alan Cox
2017-06-01 12:06 ` Dmitry Vyukov
2017-06-02 0:06 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170414123029.GA17217@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.