[CVE-2011-4324] BUG statement in default case of encode_share_access

Stefan Bader stefan.bader at canonical.com
Mon Feb 13 11:09:05 UTC 2012


On 10.02.2012 14:17, Tim Gardner wrote:
> On 02/10/2012 03:14 AM, Stefan Bader wrote:
>> CVE-2011-4324:
>>    User can cause BUG on NFS4 mounted FS via mknod
>>
>> Fix has hit Lucid and later via mainline. The upstream patch
>> for that is a bigger rewrite replacing access modes by the
>> fmode_t which was not present before 2.6.28.
>>
>> Suggesting a minimal backport for Hardy.
>>
>> ---
>>
>>  From af41fdc3d7c5d68ec75845d15f9ef4c77b31d110 Mon Sep 17 00:00:00 2001
>> From: Stefan Bader<stefan.bader at canonical.com>
>> Date: Fri, 10 Feb 2012 11:00:49 +0100
>> Subject: [hardy CVE] UBUNTU: SAUCE: Return deny all as default in
>>   encode_share_access
>>
>> This used to be catched by BUG() which is not only unnecessary.
>> It was changed as part of a bigger rewrite that depends on a
>> typedef which does not exist before 2.6.28.
>>
>> CVE-2011-4324
>> BugLink: http://bugs.launchpad.net/bugs/917829
>>
>> (very loosely backported from dc0b027dfadfcb8a5504f7d8052754bf8d501ab9)
>> Signed-off-by: Stefan Bader<stefan.bader at canonical.com>
>> ---
>>   fs/nfs/nfs4xdr.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
>> index 51dd380..cc66519 100644
>> --- a/fs/nfs/nfs4xdr.c
>> +++ b/fs/nfs/nfs4xdr.c
>> @@ -967,7 +967,7 @@ static void encode_share_access(struct xdr_stream *xdr,
>> int open_flags)
>>               WRITE32(NFS4_SHARE_ACCESS_BOTH);
>>               break;
>>           default:
>> -            BUG();
>> +            WRITE32(0);
>>       }
>>       WRITE32(0);        /* for linux, share_deny = 0 always */
>>   }
> 
> Why not WRITE32(NFS4_SHARE_DENY_BOTH) ?
> 
> Is this testable ?
> 

I found a reproducer (which is included in the bug report now). The oops does
happen on an unpatched kernel. Tried with the suggested patch and it does not
happen. In that case the file is not created (but it would have no rights
anyway).

-Stefan



More information about the kernel-team mailing list