[Cluster-devel] cluster: RHEL6 - fsck.gfs2: Fix buffer overflow in get_lockproto_table

[Fabio M. Di Nitto <fdinitto@redhat.com>]

On 8/17/2012 11:57 AM, Andrew Price wrote:
> On 17/08/12 05:02, Fabio M. Di Nitto wrote:
>> On 08/16/2012 11:01 PM, Andrew Price wrote:
>>> Gitweb:       
>>> http://git.fedorahosted.org/git/?p=cluster.git;a=commitdiff;h=f796ee8752712e9e523e1516bb9165b274552753
>>>
>>> Commit:        f796ee8752712e9e523e1516bb9165b274552753
>>> Parent:        638deec0ccbf45862eee97294f09ba9d6b3f56d0
>>> Author:        Andrew Price <anprice@redhat.com>
>>> AuthorDate:    Sat Jul 7 22:03:24 2012 +0100
>>> Committer:     Andrew Price <anprice@redhat.com>
>>> CommitterDate: Thu Aug 16 21:54:56 2012 +0100
>>>
>>> fsck.gfs2: Fix buffer overflow in get_lockproto_table
>>>
>>> Coverity discovered a buffer overflow in this function where an overly
>>> long cluster name in cluster.conf could cause a crash while repairing
>>> the superblock. This patch fixes the bug by making sure the lock table
>>> is composed sensibly, limiting the fsname to 16 chars as documented, and
>>> only allowing the cluster name (which doesn't seem to have a documented
>>> max size) to use the remaining space in the locktable name string.
>>
>> cluster name is max 16 bytes too (including \0). It's actually verified
>> by cman at startup so it can't be longer than that.
> 
> OK, thanks for clearing that up. There are other places in gfs2-utils
> which we can tighten up now that we know that the cluster name has a
> solid limit so I'm going to push this patch (which fixes the overflow
> bug) and we'll address the limit issues separately.
> 
> BTW, now that cman has disappeared upstream is anything checking the
> length of the cluster name now?

I am not sure. I don?t think corosync enforces any limit, but best to
check with Jan.

Fabio