|
Message-ID: <OF30417C6F.7ADF7028-ON87257591.006804C9-86257591.0068772E@us.ibm.com> Date: Tue, 7 Apr 2009 13:59:25 -0500 From: Steven French <sfrench@...ibm.com> To: Eugene Teo <eugene@...hat.com> Cc: Marcus Meissner <meissner@...e.de>, oss-security@...ts.openwall.com, security@...nel.org Subject: Re: CVE request? buffer overflow in CIFS in 2.6.* Yes - the NativeFileSystem field is part of a server generated response and is typically tiny ("NTFS" for example). As soon as Suresh (or his coworkers at Novell) have a patch - we (Jeff and I etc.) will review it. I think fixing these conversions to be cleaner is important, although the risk of exploitable overflow is small in practice. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com Eugene Teo <eugene@...hat.com> 04/07/2009 12:41 AM To Marcus Meissner <meissner@...e.de> cc oss-security@...ts.openwall.com, security@...nel.org, Steven French/Austin/IBM@...US Subject Re: [oss-security] CVE request? buffer overflow in CIFS in 2.6.* Hi Marcus, Marcus Meissner wrote: > Fixes a kmalloc area overflow in CIFS, number of overwritten bytes > is depending on the codepage converted to. > > The data seems to come from a remote generated reply blob even, correct > me if I am wrong. :/ Looks like it's part of the session setup. The NativeFileSystem field is part of the Tree Connect response (TCon for short). > And I wonder if "len*2" is sufficient, can't a UCS -> UTF8 conversion > generate more than 2 byte utf-8 characters for 1 ucs character? I understand that someone from your side is working on a better patch for this. Do keep us updated when it goes upstream. 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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.