oss-security - Re: CVE request: kernel: memory disclosure in SO

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [month] [year] [list]

Date: Wed, 04 Mar 2009 23:07:07 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: memory disclosure in 	SO_BSDCOMPAT gsopt

* Eugene Teo:

> Eugene Teo wrote:
>> On Tue, Mar 3, 2009 at 6:49 AM, Steven M. Christey
>> <coley@...us.mitre.org> wrote:
>>> On Wed, 25 Feb 2009, Eugene Teo wrote:
>>>
>>>> Eugene Teo wrote:
>>>>> [...]
>>>>> The fix for CVE-2009-0676 (upstream commit df0bca04) is incomplete. Note
>>>>> that the same problem of leaking kernel memory will reappear if someone
>>>>> on some architecture uses struct timeval with some internal padding (for
>>>>> example tv_sec 64-bit and tv_usec 32-bit) --- then, you are going to
>>>>> leak the padded bytes to userspace.
>>> Is this going to require a separate CVE identifier?  If a new minor
>>> version of the kernel wasn't released yet, then I'd consider the fix to be
>>> little more than a couple patch-discussion messages in a single Bugzilla
>>> entry.
>>
>> No, it shouldn't. Please use the same CVE name. Thanks.
>
> But you might want to add the link to the new CVE-2009-0676 patch in:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0676

BTW, the reproducer I saw in your bug tracker doesn't initialize the
len field.  It only worked for me after I fixed that.

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