View previous topic :: View next topic |
Author |
Message |
Xywa Veteran
Joined: 23 Jul 2005 Posts: 1631 Location: /mnt/Gentoo/Europe
|
Posted: Thu May 16, 2013 6:14 am Post subject: sys-kernel/gentoo-sources |
|
|
Hi,
From Yesterday we have such information here:
http://packages.gentoo.org/package/sys-kernel/gentoo-sources
Quote: | Users are adviced to upgrade to the latest kernel. Dropped amd64, x86 and hppa
keywords on affected 3.7.10 kernels as 3.8.13 has stabilized for them; dropped
testing keywords as well, since 3.7.10-r1 contains no more keywords it is
dropped from the tree. 3.7.10 still has some less common arches awaiting
3.8.13 stabilization. |
...so I wont be able to use the kernel 3.7.10 (or any other 3.7) now.
So what about those people, for whom driver rtsx_pci (card reader) doesn't work from kernlel 3.8 till 3.9.2?
See the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=57061
Should we use the old 3.4.5? Or maybe we shouldn't use built-in card reader at all, as no one at the moment is interested in fixing the driver in the kernel? |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Thu May 16, 2013 7:24 am Post subject: Re: sys-kernel/gentoo-sources |
|
|
Xywa wrote: | Should we use the old 3.4.5? |
Do you mean 3.4.45 ?
Then yes, this is advisable.
BTW, 3.4.45 is actually less than a week old.
And if it is working for you, why would you look for anything else ? _________________
|
|
Back to top |
|
|
Xywa Veteran
Joined: 23 Jul 2005 Posts: 1631 Location: /mnt/Gentoo/Europe
|
Posted: Thu May 16, 2013 10:03 am Post subject: Re: sys-kernel/gentoo-sources |
|
|
aCOSwt wrote: | Xywa wrote: | Should we use the old 3.4.5? |
Do you mean 3.4.45 ?
Then yes, this is advisable.
BTW, 3.4.45 is actually less than a week old.
And if it is working for you, why would you look for anything else ? |
Yes, I mean 3.4.45.
I mean 3.4 was relased in 21 May 2012 and 3.7 in 11 December 2012, so why should I leave the newer 3.7 (which was pretty fine for me for the last couple of months) into 3.4?
http://en.wikipedia.org/wiki/Linux_kernel |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Thu May 16, 2013 10:25 am Post subject: Re: sys-kernel/gentoo-sources |
|
|
Xywa wrote: | why should I leave the newer 3.7 |
Absolutely nothing tells you that you should stop using 3.7 kernels. Tom wrote: | Users are adviced to |
Just you are informed that there are a couple of security issues in 3.7 kernels and, if you feel concerned with these issues, you might consider the opportunity to move to other available kernels known for not being impacted by these security issues.
BTW, I still get 2.6.38 systems running. (networkless) and I did not understand its disappearance from the portage tree as a sign that I should upgrade. _________________
|
|
Back to top |
|
|
shanew n00b
Joined: 16 Sep 2006 Posts: 34 Location: Austin, TX
|
Posted: Thu May 16, 2013 4:08 pm Post subject: |
|
|
Note that the security issue is not limited to the 3.7 kernels, but runs up to 3.8.8, and more importantly all the way back as far as 2.6.37.
If you're not running a multi-user system or you absolutely positively trust the other users (and trust that no one can guess their passwords or otherwise access the system via their account), then you might be fine staying with an older kernel. But, if you're running a multi-user system, I would guess that preventing a local root exploit would be more important than a card reader. |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Thu May 16, 2013 4:19 pm Post subject: |
|
|
shanew wrote: | more importantly all the way back as far as 2.6.37. |
All the way back, all the way back...
apart from 3.4 >=3.4.42 / 3.2 >=3.2.45 / 3.0 > 3.0.75 that is also to say that you are in fact safe with "all the way back" in the gentoo-sources tree. _________________
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21602
|
Posted: Thu May 16, 2013 10:51 pm Post subject: |
|
|
aCOSwt wrote: | shanew wrote: | more importantly all the way back as far as 2.6.37. |
All the way back, all the way back...
apart from 3.4 >=3.4.42 / 3.2 >=3.2.45 / 3.0 > 3.0.75 that is also to say that you are in fact safe with "all the way back" in the gentoo-sources tree. | Your post is a bit confusing, but I think you are trying to point out that there exist recent stable releases of old kernels and that such recent stable release have the fix. This is true, but it does not invalidate the quoted portion. The point shanew was trying to convey is that the bug is present in every major kernel release from 2.6.37 onward, so picking older kernels only makes sense if you pick a stable release of that kernel with the fix. Given the simplicity of the fix, anyone willing to use patch can backport the fix into a kernel of their choosing. The OP might consider doing this if he is determined to continue to use 3.7.10. However, I should point out that given how long 3.7 has been EOL, some fixes in 3.8 may be security fixes that ought to be in 3.7, which the OP would be missing by a selective backport. I am not aware of any fixes marked as such, but then the fix that triggered this thread was not all that well marked either. |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Thu May 16, 2013 11:11 pm Post subject: |
|
|
Hu wrote: | it does not invalidate the quoted portion. |
It does.
The title of this thread is "sys-kernel/gentoo-sources".
All the way back from 3.7.10 in sys-kernel/gentoo-sources have the fix. _________________
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21602
|
Posted: Fri May 17, 2013 1:39 am Post subject: |
|
|
aCOSwt wrote: | Hu wrote: | it does not invalidate the quoted portion. |
It does.
The title of this thread is "sys-kernel/gentoo-sources".
All the way back from 3.7.10 in sys-kernel/gentoo-sources have the fix. | As best I can tell, v3.7.10, both vanilla and Gentoo, is affected. If you disagree, please provide a specific citation. Additionally, shanew stated, and I reiterated, that the offending commit is present in the major release of every kernel down to 2.6.37, so barring a specific patch to resolve the problem, every kernel version since then is affected. As I also stated, some kernel series have received a backported patch to fix the issue. Recent kernel 3.8 and kernel 3.9 series are known to have the fix. Others may also have it, and the fix could be easily backported.
By my analysis, vanilla v3.7.10 is affected:
Code: | $ git show v3.7.10:kernel/events/core.c | grep -A5 \ perf_swevent_init\(
static int perf_swevent_init(struct perf_event *event)
{
int event_id = event->attr.config;
if (event->attr.type != PERF_TYPE_SOFTWARE)
return -ENOENT;
| Current Subversion revision for the gentoo-sources patches is 2378. Most recent Subversion revision in which gentoo-sources patches for directory 3.7 were modified is 2315. None of the gentoo-sources patches visible in the 3.7 directory as of that revision appear to be relevant to the problem under discussion. |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Fri May 17, 2013 5:54 am Post subject: |
|
|
Hu wrote: | As best I can tell, v3.7.10, both vanilla and Gentoo, is affected. If you disagree, please provide a specific citation. |
Then... I will, quote... myself! aCOSwt wrote: | you are informed that there are a couple of security issues in 3.7 kernels |
That is no more no less than what I write in my second post.
We are since, uselessly IMNSHO, arguing about the way back from the 3.7 as emergeable from sys-kernel/gentoo-sources.
Of course if that makes you happy to demonstrate evidences, I am perfectly fine with this but I am still personally convinced that life is far too short for arguing about them.
Edit : btw of verbi gratia :
I personally posted here with the sole intention to help the OP. *NOT* to demonstrate that I am correct.
Help that I will summarize the following way :
a/ No, you should not stop using sys-kernel/gentoo-sources-3.7.10, you are only adviced to.
b/ sys-kernel/gentoo-sources-3.7.10 is concerned by a couple of security related issues you might feel concerned with depending on what you use your system for and its environment.
c/ If your device is correctly supported under <sys-kernel/gentoo-sources-3.7.10 kernels, then you can select anyone of the <sys-kernel/gentoo-sources-3.7.10 kernels. All of them are safe with regards to the above mentioned security issues. _________________
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21602
|
Posted: Sat May 18, 2013 12:56 am Post subject: |
|
|
aCOSwt wrote: | c/ If your device is correctly supported under <sys-kernel/gentoo-sources-3.7.10 kernels, then you can select anyone of the <sys-kernel/gentoo-sources-3.7.10 kernels. All of them are safe with regards to the above mentioned security issues. | You quoted yourself claiming that 3.7.10 is unaffected, but as I showed, vanilla v3.7.10 is affected. When I requested a citation, I wanted you to either quote a third party who specifically contradicts me with evidence showing where I am wrong or to otherwise provide a specific reason why it is incorrect for me to state that the PERF_EVENTS security bug is not applicable. I might also accept a third party quote contradicting me without evidence if it came from a community figure generally known to be an expert in the area, such as a maintainer of a publicly visible stable kernel or a maintainer of the subsystem in question. Quoting your own earlier post where you made that claim, without providing evidence in the original post or in the quoting post, does not advance your position. I found no evidence that Gentoo v3.7.10 carries a patch that would make it unaffected. Therefore, with regard to the security issue which triggered the thread, v3.7.10 is not safe. |
|
Back to top |
|
|
kurly Apprentice
Joined: 02 Apr 2012 Posts: 260
|
Posted: Sat May 18, 2013 1:17 am Post subject: |
|
|
You two seem to be talking past each other.
All versions less than 3.7.10 (I assume that's what aCOSwt means by the "<" symbol) available under sys-kernel/gentoo-sources (assuming you have sync'd portage lately) today are safe. The version 3.7.10 no longer has keywords for the most common arches (amd64, x86). 3.7.10 is vulnerable and will be removed altogether as soon as the less common arches get around to stabilizing 3.8.13. This has been documented in Bug 469854.
If you run amd64 or x86, whether stable or ~arch, you are safe to use any keyworded version of sys-kernel/gentoo-sources, since the only remaining affected version is no longer available for your arch. If you decide to unmask it despite being keyword-masked, then you risk trouble.
3.7.10 is not safe on any architecture. All other gentoo-sources kernels are safe. To be super clear, as of the time of this writing, that includes 3.0.75-3.0.78, 3.2.45, 3.4.42-3.4.45, 3.8.9-3.8.13, 3.9.0-3.9.2. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21602
|
Posted: Sat May 18, 2013 6:07 pm Post subject: |
|
|
kurly wrote: | All versions less than 3.7.10 (I assume that's what aCOSwt means by the "<" symbol) available under sys-kernel/gentoo-sources (assuming you have sync'd portage lately) today are safe. The version 3.7.10 no longer has keywords for the most common arches (amd64, x86). 3.7.10 is vulnerable and will be removed altogether as soon as the less common arches get around to stabilizing 3.8.13. This has been documented in Bug 469854.
If you run amd64 or x86, whether stable or ~arch, you are safe to use any keyworded version of sys-kernel/gentoo-sources, since the only remaining affected version is no longer available for your arch. If you decide to unmask it despite being keyword-masked, then you risk trouble.
3.7.10 is not safe on any architecture. All other gentoo-sources kernels are safe. To be super clear, as of the time of this writing, that includes 3.0.75-3.0.78, 3.2.45, 3.4.42-3.4.45, 3.8.9-3.8.13, 3.9.0-3.9.2. | Thank you. I read aCOSwt's posts to be a claim that v3.7.10 was safe and that the OP could pick any older kernel he liked (that is, any kernel matching v3.0.N, v3.1.N, etc. for any N) as safe, neither of which were true. The qualifiers you impose regarding recent sync and selecting only kernels still available for emerge when using a recent tree restrict the set to ones which should be safe. |
|
Back to top |
|
|
jasn Guru
Joined: 05 May 2005 Posts: 439 Location: Maryland, US
|
Posted: Sat May 18, 2013 11:14 pm Post subject: |
|
|
Well then..
I have to ask..
Is it safe?
|
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Sun May 19, 2013 7:52 pm Post subject: |
|
|
Is there a GLSA for these kernel security issues? I am wondering if the
security vulnerability or vulnerabilities only exist in 3.7.10 kernels that have
perf enabled. _________________ TIA |
|
Back to top |
|
|
jasn Guru
Joined: 05 May 2005 Posts: 439 Location: Maryland, US
|
Posted: Sun May 19, 2013 8:47 pm Post subject: |
|
|
wcg wrote: | Is there a GLSA for these kernel security issues? |
No GLSA yet. Just this bug report, and also this other forum thread.
wcg wrote: | I am wondering if the security vulnerability or vulnerabilities only exist in 3.7.10 kernels that have perf enabled. |
As pointed out in at least the other forum thread, affected linux kernels include 2.6.37 through 3.8.9 and you are correct in that in order for the vulnerability to exist, it requires the kernel to be compiled with PERF_EVENTS enabled.
Good Luck.. |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Mon May 20, 2013 6:18 am Post subject: |
|
|
[PERF_EVENTS]
Ah. Looking in make menuconfig, this option cannot be disabled from there
in 3.7.10. (It is not an option, menuconfig enables it unconditionally in that
kernel. One would need to search all of the Kconfig files in the kernel source
tree to see what else depends on it before disabling it manually, simply
by editing .config before compiling the kernel.)
Thanks for the explanation. _________________ TIA |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Tue May 21, 2013 3:52 pm Post subject: |
|
|
This URL explains how the vulnerability could be exploited:
http://www.reddit.com/r/netsec/comments/1eb9iw/sdfucksheeporgs_semtexc_local_linux_root_exploit/c9ykrck
If one needs to use a kernel that is "not fixed" for this
vulnerability for hardware reasons (drivers for your hardware
work in some not fixed kernels but not in any of the
kernels that have this vulnerability patched), the easiest
thing to do would be to patch the kernel bug yourself.
The patches that I have seen that actually close the vulnerability
are very small and self-contained. They are like "don't
check this 64-bit value as if it were a 32-bit type in this
one spot in the kernel code." And that's it. You don't even
need patch. It is such a small change one could do it with
nano and get it right.
This would be the least disruptive imho, because you don't
have to make any adjustments to your otherwise working
kernel .config.
(make menuconfig probably enables PERF_EVENTS unconditionally
because more than just perf ("performance testing") uses code enabled
by it, including something that would break the kernel if it were disabled.)
(As for 3.8.13, linux-headers-3.8 is still in testing rather than stable. So
what changes are there from linux-headers-3.7 to linux-headers-3.8?
Do any of them break glibc, util-linux, iptables, openssh, or sysvinit?
Etc.) _________________ TIA |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Tue May 21, 2013 8:19 pm Post subject: |
|
|
Just to be clear, all versions currently in the Portage tree are not vulnerable to this except for 3.7.10 which awaits 3.8.13 stabilization on less important arches, all other vulnerable versions were removed. |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Wed May 22, 2013 11:52 pm Post subject: |
|
|
fyi, this is the patch to fix it (in the quoted section of this message):
http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04302.html
So, to fix this vulnerability in a particular kernel that has it,
find /usr/src/linux/kernel/events/core.c, edit that file and
find the line:
Code: |
int event_id = event->attr.config;
|
Change the "int" to "u64", save the file, and recompile and reinstall
your kernel. You will no longer have this PERF_EVENTS vulnerability. _________________ TIA |
|
Back to top |
|
|
|