Ubuntu QA:
BlogBrainstorm
Log in
Ubuntu QA
The Ubuntu community has contributed 10324 ideas, 46361 comments, 1015854 votes

Idea #8047: Fix the unpatched kernel vulnerabilities



up
238
down
Written by Eldmannen the 4 May 08 at 09:30. Category: Security.
Related to: Nothing/Others. Status: New
Description
There are at least 13 unpatched security vulnerabilities in the Linux kernel.
Please fix these. Some of them are many years old...

* Linux Kernel CHRP Denial of Service Security Issue
* Linux Kernel Multiple Vulnerabilities
* Linux Kernel Various Vulnerabilities
* Linux Kernel SMP "/proc" Race Condition Denial of Service
* Linux Kernel perfmon Local Denial of Service Vulnerability
* Linux Kernel IP ID Value Increment Weakness
* Linux Kernel Socket Data Buffering Denial of Service
* Linux Kernel URB and IPv6 Flowlabel Handling Denial of Service
* Linux Kernel "syscall()" Argument Handling Denial of Service
* Linux Kernel "is_hugepage_only_range()" Denial of Service
* Linux Kernel Multiple Vulnerabilities
* Linux Kernel Page Fault Handler Privilege Escalation
* Linux Kernel Multiple Vulnerabilities
* Linux Kernel Binary Format Loaders Privilege Escalation
* Linux Kernel Multiple Vulnerabilities
* Linux Kernel IGMP and "__scm_send()" Vulnerabilities
* Linux Kernel Local DoS and Memory Content Disclosure Vulnerabilities
* Linux Kernel smb Filesystem Implementation Multiple Vulnerabilities
* Linux Kernel ELF Binary Loader Setuid File Handling Vulnerabilities
* Linux Kernel ide-cd SG_IO Functionality Permission Bypass Vulnerability
* Linux Kernel NFS and ptmx Denial of Service Vulnerabilities
* Linux Kernel File Offset Pointer Handling Memory Disclosure Vulnerability
* Linux Kernel Sbus PROM Driver Multiple Integer Overflow Vulnerabilities
* Linux Kernel IEEE 1394 Driver Integer Overflow Vulnerabilities
* Linux Kernel Framebuffer Driver Direct Userspace Access Vulnerability

See Secunia for more information:
* http://secunia.com/product/2719/?task=advisories

Attachments
No attachments.


Duplicates


Comments
Auzy wrote on the 4 May 08 at 13:17
You'd think they would... At the very least, we MUST investigate these, and close the ones fixed (if any).

Who wants race conditions and all that in their kernel?

Eldmannen wrote on the 4 May 08 at 14:55
Yeah, the race conditions needs to fixed, especially now that the CPU industry is moving more towards SMP and more cores.

I guess race conditions can be quite tricky to fix, but the integer overflows doesn't sound like something to difficult to fix.

Redrazor39 wrote on the 5 May 08 at 00:42
WE MUST FIX ALL OF THESE AND MORE!!!

vexorian wrote on the 5 May 08 at 01:09
Oh, thanks for your brainstorm, I am sure the devs were planning to leave these unfixed, but now that you posted this they have changed their mind.

vexorian wrote on the 5 May 08 at 01:10
Anyways, secunia is not exactly the best source here.

Auzy wrote on the 5 May 08 at 02:38
Marketting is also about perception. The reason I voted +1 is because every jackass these days goes out and base entire security reports on sites such as this, so if done, they should be marked as such immediately, so some knob will use it as "evidence" of how linux is insecure, blah blah blah.


However, how do we know they really are? Remember, DevFS had lots of issues (I definately know it had some race conditions) by the end of its reign, which will never be fixed, but they weren't because there was no active maintainer, and not many people like to go out of their way to try to fix bugs which may take hours to fix, and even longer to test fully.

If the original developers of these features are no longer with the team, its possible, nobody will really go out of their way to fix them. Some things take hours to fix, and some things you need to even change the API slightly for.

Coding new features is fun stuff. Debugging your kernel for 5 hours trying to determine the cause of a race condition, and then working out how to fix it? Me personally.. not so fun. So we cant be sure

Auzy wrote on the 5 May 08 at 03:05
rather some knob wont start calling linux insecure because they aren't marked as done yet.

tgape wrote on the 6 May 08 at 02:55
First, I find it interesting that the given link lists all the bugs in detail - the 13 still open, and the 131 that have been closed.

I've taken the time to go through most of them anyway. I'm pretty sure most of them *have* been fixed. I recognize many that I know were fixed.

However, it's not really 13 bugs; it's more like 20+ - quite a few of them are inappropriate joining of completely separate issues under one heading. From what I've seen in the field, there are three big reasons not to do this:

1. It makes it more difficult to track resolution, because it's harder to find the old report when you hear the bug's been fixed. Also, you have to update the same report many times because they're probably not going to be all fixed at the same time.

2. Many people have difficulty correctly rating a bunch of problems at once. It's much easier to separate them and rate them individually.

3. People tend to tune out. Ok, I'm not subject to that one, or that one or that one. Man, this is just a waste of my time.

Especially when you get farther down the list, the

tgape wrote on the 7 May 08 at 18:49
... message apparently gets truncated.

the real meat of my comment was that most of these are fixed bugs which merely weren't closed due to poor tracking on the part of Secunia. It's likely that a significant part of Secunia's tracking problem was inappropriate bundling.

(Note: bundling of diverse bugs by the vendor who produces the software is significantly different than when a third party vendor does it. Specifically, the vendor can ensure that all of the bundled bugs do, indeed, get fixed at the same time. Other groups cannot do this, as they are not in control of exactly what is released when.)


Post your comment