As for this "stable" kernel of the day, with no mentioned security fixes:
CHIKAMA masaki (1):
cpufreq: fix null object access on Transmeta CPU
Is trivially exploitable. Do I need to write up another exploit that disables SELinux again?
I can't count on one hand how many of these I see continue to get silently fixed in each
"stable" kernel release. Maybe someone on the oss-security list needs to educate the kernel
developers on this "unexploitable/DoS-only" class of bugs. Apparently my exploit hasn't
changed anything, as it's now over a year later.
I wonder if the developers just feel like they can get away with it if nobody notices or
complains? We know the developers aren't ignorant of the class of bugs, given their posts to
certain mailing lists, and the attempted development of features to protect against
exploitation of subsets of the bug class (see: http://lwn.net/Articles/283109/,
http://lkml.org/lkml/2007/6/6/29, and when they made it not so trivial to bypass with one line
of code: http://lkml.org/lkml/2007/11/16/277).
So I'm naturally curious to find out the reason. Perhaps these patches aren't getting
reviewed by people with proper knowledge of security implications of these and other kinds of
Users of any Linux distribution should be upset with this situation. When bugs aren't
properly marked as security-relevant or are silently fixed, they don't get backported to the
kernels provided by your distribution. So even though you're using the latest "secure" kernel
for your distribution, you can still be compromised by a number of silently fixed
vulnerabilities for which a patch already exists, but no distribution will know to apply.
It's very simple gentlemen:
If you have a pointer to a structure which contains a function pointer, and the pointer to the
structure is NULL, the bug is trivially exploitable.
If you have a pointer to a function pointer which is NULL, the bug is trivially exploitable.
Also, cleverly wording the bugs doesn't help anyone. When it is a NULL pointer dereference,
please label it properly as such. When you use phrases like:
Stephen Smalley (2):
SELinux: do not clear f_op when removing entries
or this one's real good:
Rémi Denis-Courmont (1):
Fixes a segmentation fault when trying to splice from a non-TCP socket.
it takes us a few more seconds to recognize it and add to our list of exploits.
BTW, it's good to know that the 'grep copy_from_user | grep -v sizeof' from 2005 is still a
great method of finding exploitable kernel vulnerabilities in under 5 minutes. The TPM
developers should be careful with their signed lengths (not fixed in the latest kernel).
And in case you thought the poor sysctl-based replacement for PaX's UDEREF which breaks some
popular applications protected you against the entire class of invalid userland dereferences,
let me remind you of http://lkml.org/lkml/2008/5/9/90
Maybe a month of silently-fixed kernel vulnerabilities is in order?