linux-kernel - Re: [PATCH 21/21] TTY: move tty buffers to tty

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1354046255.2444.10.camel@thor>
Date:	Tue, 27 Nov 2012 14:57:35 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Sasha Levin <levinsasha928@...il.com>
Cc:	Jiri Slaby <jslaby@...e.cz>, Jiri Slaby <jirislaby@...il.com>,
	gregkh@...uxfoundation.org, alan@...ux.intel.com,
	linux-kernel@...r.kernel.org, Dave Jones <davej@...hat.com>
Subject: Re: [PATCH 21/21] TTY: move tty buffers to tty_port

On Sat, 2012-11-03 at 20:53 -0400, Sasha Levin wrote:
> On 11/03/2012 07:06 PM, Sasha Levin wrote:
> > On 11/03/2012 11:55 AM, Jiri Slaby wrote:
> >> On 11/03/2012 03:03 AM, Sasha Levin wrote:
> >>> On 11/02/2012 12:18 PM, Jiri Slaby wrote:
> >>>> On 11/02/2012 05:07 PM, Sasha Levin wrote:
> >>>>> On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby <jslaby@...e.cz> wrote:
> >>>>>> On 10/31/2012 04:59 PM, Sasha Levin wrote:
> >>>>>>> So you probably want a lot more than 100k syscalls, why limit it at
> >>>>>>> all actually?
> >>>>>>
> >>>>>> I unset the limit but I still can't reproduce...
> >>>>>>
> >>>>>>> I've attached my .config for the guest kernel as reference.
> >>>>>>
> >>>>>> Even using this config does not help to reproduce that.
> >>>>>>
> >>>>>> Do you use some special trinity params?
> >>>>>
> >>>>> Not really:
> >>>>>
> >>>>>     ./trinity -m --quiet --dangerous -l off
> >>>>
> >>>> Oh, you run that as root??
> >>>>
> >>>>> Can I add something to my kernel to provide more info when it happens?
> >>>>
> >>>> Maybe the attached patch can tell us more...
> >>>>
> >>>
> >>> Nope, I see the warnings mentioned before, without the new 'HUH' warnings.
> >>
> >> Actually it does. It is exactly as you wrote some time earlier. The work
> >> is scheduled after is was cancelled and should not trigger anymore. Or,
> >> it is scheduled before it is supposed to do. Could you try the attached
> >> patch and report what happens with that patch?
> >>
> >> PS I can't reproduce by whatever I tried.
> >>
> >> thanks,
> >>
> > 
> > Interesting...
> > 
> > [  388.783955] tty is bad=0 ops=          (null)Pid: 6480, comm: kworker/1:2 Tainted: G        W
> > 3.7.0-rc3-next-20121102-sasha-00002-gbb570e0-dirty #111
> 
> So after fuzzing for a while I'm also seeing these:
> 
> [  603.533932] tty is bad=-2 ops=          (null)Pid: 37, comm: kworker/4:0 Tainted: G        W    3.7.0-rc3-next-20121102-sasha-000
> 02-gbb570e0-dirty #112

Hi Sasha,

Assuming this access-after-free is still reproducible for you, would you
be willing to try the patch below? I tried to reproduce this and
couldn't (with multiple cores and with just single core).

It would distinguish between case A (that the buf work is not being
cancelled) and case B (that the buf work is being scheduled after the
port has already been freed). It should BUG in case B, which would also
expose the call chain. It won't help at all in case A though :\

Regards,
Peter Hurley

-- >% --
Subject: [PATCH -next] tty: debug: Narrow possible causes of access-after-free


Signed-off-by: Peter Hurley <peter@...leysoftware.com>
---
 drivers/tty/pty.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index be6a373..893fe69 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -409,6 +409,7 @@ static void pty_cleanup(struct tty_struct *tty)
 {
 	tty->port->itty = NULL;
 	tty_port_put(tty->port);
+	tty->port = NULL;
 }
 
 /* Traditional BSD devices */
-- 
1.8.0



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/