# sys-kernel/gentoo-sources

## Xywa

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

 

...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?

----------

## aCOSwt

 *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 ?

----------

## Xywa

 *aCOSwt wrote:*   

>  *Xywa wrote:*   Should we use the old 3.4.5? 
> 
> Do you mean 3.4.45 ?
> 
> Then yes, this is advisable.
> ...

 

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

----------

## aCOSwt

 *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.

----------

## shanew

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.

----------

## aCOSwt

 *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.

----------

## Hu

 *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.

----------

## aCOSwt

 *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.

----------

## Hu

 *aCOSwt wrote:*   

>  *Hu wrote:*   it does not invalidate the quoted portion. 
> 
> It does.
> 
> The title of this thread is "sys-kernel/gentoo-sources".
> ...

 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:

```
$ 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.

----------

## aCOSwt

 *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.

----------

## Hu

 *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.

----------

## kurly

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.

----------

## Hu

 *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.

----------

## jasn

Well then..

I have to ask..

Is it safe?

 :Wink: 

----------

## wcg

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.

----------

## jasn

 *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..

----------

## wcg

[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.

----------

## wcg

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.)

----------

## TomWij

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.

----------

## wcg

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:

```

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.

----------

