linux-kernel - Re: [159/244] ipc/mqueue.c: fix mq

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]

Date:	Thu, 29 Sep 2011 12:37:15 -0700
From:	Andrew Morton <akpm00@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Doug Ledford <dledford@...hat.com>, stable-review@...nel.org,
	torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Jiri Slaby <jslaby@...e.cz>,
	Manfred Spraul <manfred@...orfullife.com>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [159/244] ipc/mqueue.c: fix mq_open() return value

On Thu, 29 Sep 2011 12:08:55 -0700
Greg KH <gregkh@...e.de> wrote:

> > And in fact, upon further reflection, I think maybe that particular
> > test could use being split into two distinct tests.  One for wrapping
> > the byte counter, which would return -ENOMEM, and one for exceeding
> > RLIMIT_MSGQUEUE which would return -EPERM (not sure if that's right, I
> > would have to poke around elsewhere, but it seems a better response
> > when you are violating a ulimit than nomem to me anyway).
> 
> Ok, care to get the patch into Linus's tree and then I can take it into
> stable?

Doug, the thing to do here is to rework your recent mqueue patchset. 
Prepare a minimal, critical-stuff series of bugfix patches against
current Linus mainline which is also applicable to -stable.  We can
merge that into 3.1 or, more likely, into 3.2-rc1/3.1.x.

Then, later, we can merge up the less critical parts of that patchset.

otoh, the only not-applicable-to-stable part of that patchset appears
to be "[1/5] ipc/mqueue: cleanup definition names and locations" and
it's fairly small.  So we could perhaps just merge all five into
3.2-rc1, with a -stable backport.

Doing that backport would require that we first backport the buggy
patches (ie: this one), which is a bit weird.  Perhaps it would be
better for you to prepare a reworked patch series for 3.0.x after
that five-patch series hits mainline.
--
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/