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