2.6.25.10 security fixes, please assign CVE id

[Marcus Meissner <meissner () suse de>]

http://lwn.net/Articles/288473/

> Stable kernel 2.6.25.10
> Posted Jul 3, 2008 15:34 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] 
> ..and once again, users get the usual treatment of not actually being told why an upgrade is
> so strongly encouraged. it seems that in this episode of the -stable security fix coverup
> series (that's not to say that the corresponding vanilla commits got a better treatment), we
> got at least two fine examples of how such bugs should not fall victim of the kernel devs'
> full disclosure policy.
>
> as for the particular bugs:
>
> 1.
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commitdiff;h=2a739dd53ad7ee010ae6e155438507f329dce788
> adds several checks against NULL function pointers, which is an immediate 'get direct ring-0
> code execution' flag, unfortunately we don't learn whether this is actually possible or not,
> but one assumes the STRONGLY encouraged upgrade wasn't for nothing at least.

This is CVE-2008-2812.
 
> 2.
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commitdiff;h=1e9a615bfce7996ea4d815d45d364b47ac6a74e8
> is an even better one, it allows one to overflow the task struct refcount (a 32 bit atomic_t
> on the affected amd64) and cause its subsequent freeing with dangling references to it all
> over the place (including 'current' of the ptraced task itself). corresponding exploit avenues
> abound.

I don't know if this one has a CVE yet.

> Greg, instead of witchhunting on vendor-sec you guys should sit down and decide what you want
> for your disclosure policy for real. the next Kernel Summit would be a good opportunity i
> think.

[no comment]

Ciao, Marcus
-- 
Working, but not speaking, for the following german company:
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)