Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 13 Jan 2010 14:45:25 -0500 (EST)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request - kernel: infoleak if
 print-fatal-signals=1

Please use CVE-2010-0003 for this.

Thanks.

-- 
    JB


----- "Eugene Teo" <eugene@...hat.com> wrote:

> Description from the upstream patch:
> When print-fatal-signals is enabled it's possible to dump any memory 
> reachable by the kernel to the log by simply jumping to that address 
> from user space.
> 
> Or crash the system if there's some hardware with read side effects.
> 
> The fatal signals handler will dump 16 bytes at the execution address,
> 
> which is fully controlled by ring 3.
> 
> In addition when something jumps to an unmapped address there will be
> up 
> to 16 additional useless page faults, which might be potentially slow
> 
> (and at least is not very efficient)
> 
> Fortunately this option is off by default and only there on i386.
> 
> But fix it by hecking for kernel addresses and also stopping when 
> there's a page fault.
> 
> References:
> http://patchwork.kernel.org/patch/69752/
> http://git.kernel.org/linus/b45c6e76bc2c72f6426c14bed64fdcbc9bf37cb0
> https://bugzilla.redhat.com/show_bug.cgi?id=554578
> 
> Thanks, Eugene
> -- 
> Eugene Teo / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ