linux-kernel - Re: fasync_remove

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 7 Mar 2013 19:20:44 -0500
From:	Dave Jones <davej@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: fasync_remove_entry oops

On Thu, Mar 07, 2013 at 06:54:09PM -0500, Dave Jones wrote:
 > On Thu, Mar 07, 2013 at 03:46:24PM -0800, Linus Torvalds wrote:
 >  > On Thu, Mar 7, 2013 at 3:14 PM, Dave Jones <davej@...hat.com> wrote:
 >  > > And.. More fun with pipes.
 >  > >         for (fp = fapp; (fa = *fp) != NULL; fp = &fa->fa_next) {
 >  > >     1650:       49 8b 06                mov    (%r14),%rax
 >  > >
 >  > > So we got to fasync_remove_entry with a NULL fa struct.
 >  > >
 >  > > Can we just add more NULL checks here, or does that need to happen
 >  > > at a higher level ?
 >  > 
 >  > I think you'll find that it's not fapp that was NULL.
 > 
 > yeah, brainfart
 > 
 >  > The caller was
 >  > pipe_rdwr_fasync -> fasync_helper, and pipe_rdwr_fasync always passes
 >  > in
 >  > 
 >  >     &pipe->fasync_readers
 >  > 
 >  > (and writers) so it looks like it is pipe that was NULL. Really odd.
 >  > How did the open of the pipe succeed with a NULL i_pipe? We do have
 >  > i_pipe == NULL, but that should happen only with a not-yet-opened
 >  > pipe, or after the last close.
 >  > 
 >  > In neither case should you have that pipe_rdwr_fasync() call.
 >  > 
 >  > The fact that this happens for a delayed __fput() makes me think it
 >  > was never a successful open to begin with, but how did the FASYNC flag
 >  > get set in that case? Do we actually allow it in the open flags..
 >  > Hmm..
 >  > 
 >  > So if we need new NULL pointer checks, I think they'd need to be
 >  > something like the attached patch.
 >  
 > I'll give it a shot. Can't be any worse than what we have already.

I seem to be hitting the first pipe related oops a few times..
(Subject: pipe_release oops 3-4 mails upthread)

I don't know yet if that's just preventing me from getting to test the
pipe_rdwr_fasync path, but I haven't hit it since applying that patch.

	Dave 

--
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/