Just a quick note to announce gentoo-sources-2.6.38 has been released which includes the fbcondecor patch. Also note that the per-session group scheduling patch is included in this release from upstream. I also committed vanilla-sources-2.6.38, as well.
Archive for the 'Gentoo' Category
The Gentoo Kernel Team (thanks, asn!) have released 3 patched kernels that cover the Econet root exploit described at: http://lwn.net/Articles/419141/
This covers (CVE-2010-3850), (CVE-2010-3849) and (CVE-2010-4258).
The following gentoo-sources contain the fixes: gentoo-sources-2.6.36-r4, gentoo-sources-2.6.35-r14 and gentoo-sources-2.6.32-r23.
Edit: 2.6.36-r4, not r6, which does not exist, yet.
If you haven’t heard about the new ~200 line patch which, for some users, has improved interactivity on the desktop, you can read about it here.
I have released a masked version of gentoo-sources (gentoo-sources-2.6.36-r2) which contains the backport to this kernel version written by the original author.
If anyone wants to try this patch on 2.6.36, you can just unmask gentoo-sources-2.6.36-r2, and try it out.
Attention all Media, Gentoo users and my fellow Gentoo devs:
A new kernel vulnerability has been reported and the gentoo bug has been filed. Within 4 hours of this filing, the kernel team has released the following:
The fix for CVE-2010-3904 has been back ported to all gentoo-source versions that are currently supported. (2.6.32-rX, 2.6.34-rX and 2.6.35-rX)
This fix is now released in the following genpatches:
The following newly released gentoo-sources kernels contain the patch:
The following stable request bugs have been filed for these kernels:
Please note that no stable request has been filed for 2.6.35-r11, as we wait for the prerequisite 30 days for the new baselayout to be requested to be stabled before we can do so. If you are running a 2.6.35 gentoo-source kernel, please upgrade to the latest version. Note that as of this post, upstream has not released new vanilla kernel versions containing the fix.
In light of the recent kernel vulnerabilities, issues with our kernel stabilization policy have been brought to light.
The discussion and potential solution was initiated by Kerin Millar, one of our more technical users (who I would like to see become a dev). He opened a bug and the discussion that followed can be read on bug #338739.
To sum up, we want to be able to stabilize kernels faster, especially in the case when a vulnerability is discovered.
We are looking to get agreement from the arch teams for the policy to be as follows:
For a new version release: 2.6.X, the stabilization will follow the same steps as it does today. We open a bug, and all the arches stabilize as they see fit.
Once this happens, any subsequent point release (2.6.X.y) will be automatically stabilized for any arches that had the previous version stabled. This includes gentoo-sources, especially since sometimes security patches are not released for “older” kernels. (2.6.34, for example).
I appreciate arch team leads’ buy-in/alternative solutions/comments on the bug, some already have. The faster we can get a solid policy in place the faster we get security patched kernels to our users.
I appreciate everyone’s time and effort, I wanted to blog this so people don’t think the kernel team is doing nothing to address any identified shortcoming.
As always, feel free to contact me on any medium if you would like to discuss.
Let’s talk about kernel releases, the latest two kernel vulnerabilities, and what vanilla or gentoo-sources you should be running.
The two vulnerabilities I’m talking about are:
>=gentoo-sources-2.6.32-r18 and vanilla-sources-220.127.116.11 contain the fixes for both CVE-2010-3081 and CVE-2010-3301.
stable request: http://bugs.gentoo.org/show_bug.cgi?id=338317
>=gentoo-sources-2.6.34-r11 (and no vanilla 2.6.34) contain the fixes for both CVE-2010-3081 and CVE-2010-3301.
stable request: http://bugs.gentoo.org/show_bug.cgi?id=339819
>=gentoo-sources-2.6.35-r8 >= vanilla-sources-18.104.22.168 contain the fixes for both CVE-2010-3081 and CVE-2010-3301.
2.6.35 will only be stabilized after the new baselayout 1.2.14-r1 has been in the tree for 30 days. I described the problem in an earlier blog post so I will not rehash the whole story
If *anyone* feels a kernel version needs to be stabilized we have this cool thing called bugzilla. Open a bug! We also have this other cool thing (I don’t think Gentoo invented it, not sure) called IRC. I am on IRC 24/7 and will always look to see if someone highlights my name. Talk to me first. Then feel free to bash me if I don’t respond in our user’s best interest. I always try to do what’s best for the community and if I am slacking, it’s only due to life/wife/family/job.
The gentoo-sources team actively supports gentoo-source users. No matter the keyword state. We used to only support two versions (current release and 1 – current release). But now we support the latest upstream LTS as well.
We would also welcome any users or devs who are interested in maintaining the kernel at Gentoo to join the team.
Hope this helps clarify things, always feel free to reach out to me.
Why isn’t any version of gentoo-sources 2.6.35 stable?
There exists a bug that appears with the combination of the dhcpcd module from baselayout-1 and kernel versions >= 2.6.35.
Since we could not use a stable kernel with a stable baselayout, arch teams were not keen on stablizing the kernel alone.
We have been working on the dhcpcd fix in bug #262097.
We have a working patch and Vapier has blessed, committed it and then released a new baselayout which uses it; baselayout-1.12.14.
On the other side, WilliamH and some others are working to stablize openrc which will make baselayout 1 obsolete. We are attacking this issue from both ends which will eventually result in a stable 2.6.35 kernel.
In the meantime, if anyone wants to test the new baselayout-1, please do so and report any bugs.
Thanks to the following users and developers for reporting, testing and contributing to the patch.
Paul B. Henson
Does anyone have an suggestions for a good sized (60+ inch ) desk that can handle multiple computer systems?
It would be great to have trays to hide wires and be one level to handle 3 or more computers with LCD monitors.
I find keyboard trays to be space limiting. An L-shaped or curved design would work for me.
It’s a good idea to have multiple systems for Kernel work so as not to bork your primary computers and I’m starting to outgrow my desk. Looking to setup an addtional system for systemd stuff and I have no room!
It can’t be a crazy homemade job, I’m married and have an approval process to go through. (even though it will reside in the man-cave.)
The kernel vulnerability detailed at the register has been fixed in the follow gentoo-source versions:
This vulnerability allows root access escalation on 64 bit installations. Hardened users can read blueness’ post to the mailing list.
Details on what patches are contained in these releases can be found on the genpatches website.
I just released gentoo-sources 2.6.32-r14, 2.6.34-r6 and 2.6.35-r2. These all include the patch for the local privilege escalation flaw bug that was recently announced. So, I do recommended all gentoo-sources users upgrade to these latest versions.
There is also a bug fix included for people that were experiencing the freeze/oops in 22.214.171.124 as referenced in this bug.
Please note that 2.6.33 is no longer being supported by Gentoo-Sources.