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] [day] [month] [year] [list]
Date:	Wed, 4 Jun 2008 00:57:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Roland McGrath <roland@...hat.com>
Cc:	Oleg Nesterov <oleg@...sign.ru>, ebiederm@...ssion.com,
	mingo@...e.hu, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] coredump: zap_threads() must skip kernel threads

On Tue,  3 Jun 2008 14:49:58 -0700 (PDT) Roland McGrath <roland@...hat.com> wrote:

> > This is a bugfix, yes?
> > 
> > How does it get triggered?
> 
> Yes, I think it fixes a bug.  The trigger would be an aio request doing
> some work (inside aio_kick_handler) simultaneous with some thread in the
> requester's mm doing a core dump (inside zap_threads).
> 
> > Do you think the bug is sufficiently serious to fix it in 2.6.26?  In
> > 2.6.25.x?  If so, it would be better if this patch were not dependent
> > upon the preceding ones, which do not appear to be 2.6.26 or -stable
> > material.
> 
> It has probably never been seen for real, but might be possible to produce
> with an exploit that works hard to hit the race.  I'm not sure off hand
> what all the bad effects would be, mainly those of SIGKILL'ing the
> workqueue thread (keventd I guess).  The core-dumping threads will be stuck
> in uninterruptible waits and never be killable.
> 
> Oleg's cleanups make the fix much nicer because there is an easy persistent
> flag to check without races.  Probably the most isolated fix for this is
> something like the bit below (wholly untested).  This is hairy enough that
> I think Oleg's 1/3 + 2/3 would be preferable even for -stable.

OK, thanks.

I'll tentatively queue these three for 2.6.26 and will leave 2.6.25.x
alone.  The bug seems sufficiently obscure?

(This required a bit of massaging of
coredump-zap_threads-must-skip-kernel-threads.patch in fs/exec.c due, I
assume, to dependencies on other things which we have queued for
2.6.27).


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ