Please test and stabilize sys-kernel/gentoo-sources-3.2.1-r2. This kernel contains the fix for the root exploit CVE-2012-0056 (Linux Local Privilege Escalation via SUID /proc/pid/mem Write).[1] [1] http://blog.zx2c4.com/749
amd64 is ok
amd64 ok
amd64 done. Thanks Maurizio and Michael
Compile and run on my machine. No bugs. x86: ok
Archtested on x86: Everything seems fine.
Hi, I'm adding vanilla sources 3.2.2 to this list for the same reason. I just committed it. My amd64 arch friends, adding you guys back for this. Thanks for being super responsive, as always.
I do not understand why stabilizing 3.2 at a rush as sys-kernel/gentoo-sources-3.1.10-r1 also contains the fix for CVE-2012-0056, doesn't it?
Currently, there is no 3.1 or 3.2 stable vanilla kernel that is not affected by the exploit. The only stable 3.1 is affected. So, users the latest stable vanilla kernel are running an exploitable kernel. Is that enough reason for you?
Mike, I guess Fabian means other. As you wrote in your blog: The following kernels now contain the fix: gentoo-sources-3.2.1-r2 gentoo-sources-3.1.10-r1 gentoo-sources-3.0.17-r2 So, if I understand well, he means, why we stabilize also 3.2 series instead of stabilizing only 3.0 and 3.1? Obvious I'm talking about gentoo-sources and not vanilla
amd64 done also for vanilla.
(In reply to comment #9) > Mike, I guess Fabian means other. > > As you wrote in your blog: > The following kernels now contain the fix: > > gentoo-sources-3.2.1-r2 > > gentoo-sources-3.1.10-r1 > > gentoo-sources-3.0.17-r2 > > So, if I understand well, he means, why we stabilize also 3.2 series instead of > stabilizing only 3.0 and 3.1? > Obvious I'm talking about gentoo-sources and not vanilla I'm not sure what you mean since gentoo-sources-3.1.10-r1 and gentoo-sources-3.0.17-r2 are already stable for everyone except for ppc and ppc64.
(In reply to comment #11) > > > > So, if I understand well, he means, why we stabilize also 3.2 series instead of > > stabilizing only 3.0 and 3.1? > > Obvious I'm talking about gentoo-sources and not vanilla > > > I'm not sure what you mean since gentoo-sources-3.1.10-r1 and > gentoo-sources-3.0.17-r2 are already stable for everyone except for ppc and > ppc64. Previous commentators asked whether we really need stabilizing gentoo-sources-3.2.1-r2 with sys-kernel/gentoo-sources-3.1.10-r1 already stable and not affected with CVE-2012-0056? Just for me as example, I have to masked 3.2.1-r2 cause I need VirtualBox and don't want to install it from ~amd64.
(In reply to comment #12) > (In reply to comment #11) > > > > > > So, if I understand well, he means, why we stabilize also 3.2 series instead of > > > stabilizing only 3.0 and 3.1? > > > Obvious I'm talking about gentoo-sources and not vanilla > > > > > > I'm not sure what you mean since gentoo-sources-3.1.10-r1 and > > gentoo-sources-3.0.17-r2 are already stable for everyone except for ppc and > > ppc64. > > Previous commentators asked whether we really need stabilizing > gentoo-sources-3.2.1-r2 with sys-kernel/gentoo-sources-3.1.10-r1 already stable > and not affected with CVE-2012-0056? > > Just for me as example, I have to masked 3.2.1-r2 cause I need VirtualBox and > don't want to install it from ~amd64. That is what I meant. I understand the reason for stabilizing sys-kernel/vanilla-sources-3.2.1, but not for stabilizing sys-kernel/gentoo-sources-3.2.1-r2. I am just wondering what the policy is. For me it does not matter as I can manually force running the patched 3.1.x versions.
With this quick stabilization you broke builds for stable virtualbox-modules. Such rush was not needed for the case since we have 3.1.x kernel with CVE patch applied. I think in this case the proper update scenario was not applied hence build error for virtualbox-modules. The main question is: why archs confirmed this upgrade path without due consideration of possible failures?
Out of kernels drivers that fail to build have never stopped kernel stabilizations in Gentoo.
HPPA won't go stable, as this kernel fails to boot the system. Marked -hppa. Incidentally, I noticed that 3.1.10-r1 /is/ marked stable. Luckily that version appears to work. The thing is that 3.1.10-r1 went stable entirely without arch team testing, it seems, so the question remaining is why 3.2.* should probably be officially tested when 3.1.10 apparently wasn't.
Marked ppc/ppc64 stable.
(In reply to comment #16) > HPPA won't go stable, as this kernel fails to boot the system. Marked -hppa. > > Incidentally, I noticed that 3.1.10-r1 /is/ marked stable. 3.1.10 is now marked -hppa too. It's highly unreliable as compared to 3.1.6.
(In reply to comment #18) > (In reply to comment #16) > > HPPA won't go stable, as this kernel fails to boot the system. Marked -hppa. > > > > Incidentally, I noticed that 3.1.10-r1 /is/ marked stable. > > 3.1.10 is now marked -hppa too. It's highly unreliable as compared to 3.1.6. Could you put the 3.1/2100_proc-mem-handling-fix.patch patch in 3.1.6 too, please?
(In reply to comment #19) > Could you put the 3.1/2100_proc-mem-handling-fix.patch patch in 3.1.6 too, > please? Er, it was removed? What's happening here?
(In reply to comment #17) > Marked ppc/ppc64 stable. It has problems wrt #401617
arm stable
Stable for HPPA.
x86 stable, thanks Mikle
alpha/ia64/s390/sh/sparc stable
