Bug 838910 - fsck.gfs2: Buffer overflow when cluster name is too long
fsck.gfs2: Buffer overflow when cluster name is too long
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs2-utils (Show other bugs)
5.8
Unspecified Unspecified
low Severity low
: rc
: ---
Assigned To: Andrew Price
Cluster QE
:
Depends On:
Blocks: 838945
  Show dependency treegraph
 
Reported: 2012-07-10 08:27 EDT by Andrew Price
Modified: 2013-01-08 02:32 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 838945 (view as bug list)
Environment:
Last Closed: 2013-01-08 02:32:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducer (caution: it overwrites /etc/cluster/cluster.conf) (369 bytes, application/x-shellscript)
2012-07-10 08:27 EDT, Andrew Price
no flags Details
Patch, unchanged from upstream (2.88 KB, patch)
2012-07-16 09:26 EDT, Andrew Price
no flags Details | Diff
List of fixed issues according to Coverity scan difference (320 bytes, text/plain)
2012-08-16 04:20 EDT, Martin Bříza
no flags Details

  None (edit)
Description Andrew Price 2012-07-10 08:27:09 EDT
Created attachment 597326 [details]
Reproducer (caution: it overwrites /etc/cluster/cluster.conf)

Description of problem:

Coverity discovered a buffer overflow in fsck.gfs2 which can be triggered when the super block is corrupt and the cluster name in cluster.conf is too long.

Version-Release number of selected component (if applicable):

All versions from current RHEL5.8 to upstream.

How reproducible:

Every time.

Steps to Reproduce:

echo '<cluster name="12345678901234567890123456789012345678901234567890123456789012345678"' > /etc/cluster/cluster.conf
dd if=/dev/null of=disk.img bs=1 count=0 seek=130M
mkfs.gfs2 -O -p lock_nolock disk.img
#Corrupt the superblock's mh_type field
dd if=/dev/zero of=disk.img bs=1 count=1 seek=65543 conv=notrunc
fsck.gfs2 -y disk.img

  
Actual results:

In RHEL5 packages aren't compiled with _FORTIFY_SOURCE checks so fsck.gfs2 doesn't crash, but it appears to hang for some time before exiting with failure. Presumably the block size is overwritten in the sbd and fsck.gfs2's state becomes inconsistent so it starts reading the device sequentially.

Expected results:

fsck.gfs2 detects the overly long cluster name and chooses a sensible locktable name when rebuilding the sb.
Comment 1 RHEL Product and Program Management 2012-07-10 09:57:24 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 2 Andrew Price 2012-07-16 09:26:31 EDT
Created attachment 598450 [details]
Patch, unchanged from upstream

The upstream patch for this bug applies cleanly to the RHEL59 branch unchanged.
Comment 3 Andrew Price 2012-07-16 09:48:51 EDT
Pushed to cluster.git/RHEL59
Comment 4 Andrew Price 2012-07-16 13:55:01 EDT
Built in gfs2-utils-0.1.62-35.el5 - https://brewweb.devel.redhat.com/buildinfo?buildID=220694

Test output using the attached reproducer:

[root@dell-pe1855-02 ~]# rpm -q gfs2-utils
gfs2-utils-0.1.62-35.el5
[root@dell-pe1855-02 ~]# ./overflow.sh 
0+0 records in
0+0 records out
0 bytes (0 B) copied, 4.5e-05 seconds, 0.0 kB/s
Device:                    disk.img
Blocksize:                 4096
Device Size                0.13 GB (33280 blocks)
Filesystem Size:           0.13 GB (33280 blocks)
Journals:                  1
Resource Groups:           1
Locking Protocol:          "lock_nolock"
Lock Table:                ""
UUID:                      D8BC5F53-061E-0B6A-925A-586AC0D185B4

1+0 records in
1+0 records out
1 byte (1 B) copied, 0.00011 seconds, 9.1 kB/s
Initializing fsck
Either the super block is corrupted, or this is not a GFS2 filesystem
Gathering information to repair the gfs2 superblock.  This may take some time.
Block size determined to be: 4096
Found system jindex file at: 0x16
Found system per_node directory at: 0x8059
From per_node's '..' I backtracked the master directory to: 0x15
Found system statfs file at: 0x805b
Found system inum file at: 0x815d
Found system rindex file at: 0x815f
Found system quota file at: 0x8160
Lock protocol assumed to be: lock_dlm
Lock table determined to be: 123456789012345678901234567890123456789012345678901234:repaired
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Starting pass1
Pass1 complete      
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete      
Starting pass3
Pass3 complete      
Starting pass4
Pass4 complete      
Starting pass5
Pass5 complete      
Writing changes to disk
gfs2_fsck complete
Comment 8 Justin Payne 2012-08-06 16:04:14 EDT
Verified in gfs2-utils-0.1.62-35.el5:

Before:

[root@dash-03 ~]# rpm -q gfs2-utils
gfs2-utils-0.1.62-34.el5
[root@dash-03 ~]# time ./overflow.sh 
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.6e-05 seconds, 0.0 kB/s
Device:                    disk.img
Blocksize:                 4096
Device Size                0.13 GB (33280 blocks)
Filesystem Size:           0.13 GB (33280 blocks)
Journals:                  1
Resource Groups:           1
Locking Protocol:          "lock_nolock"
Lock Table:                ""
UUID:                      EC9928FC-1D6E-2A03-79ED-F1A1E4D274C2

1+0 records in
1+0 records out
1 byte (1 B) copied, 4.7e-05 seconds, 21.3 kB/s
Initializing fsck
Either the super block is corrupted, or this is not a GFS2 filesystem
Gathering information to repair the gfs2 superblock.  This may take some time.
Block size determined to be: 4096
Found system jindex file at: 0x16
Found system per_node directory at: 0x8059
From per_node's '..' I backtracked the master directory to: 0x15
Found system statfs file at: 0x805b
Found system inum file at: 0x815d
Found system rindex file at: 0x815f
Found system quota file at: 0x8160
Lock protocol assumed to be: lock_dlm
Lock table determined to be: 12345678901234567890123456789012345678901234567890123456789012345678:repaired
The system master directory seems to be destroyed.
Trying to rebuild the master directory.
Master directory rebuilt.
Unable to allocate journal index
Unable to read in jindex inode.

real    6m50.756s
user    0m8.513s
sys     1m26.817s

After:

[root@dash-03 ~]# rpm -q gfs2-utils
gfs2-utils-0.1.62-35.el5
[root@dash-03 ~]# time ./overflow.sh 
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.6e-05 seconds, 0.0 kB/s
Device:                    disk.img
Blocksize:                 4096
Device Size                0.13 GB (33280 blocks)
Filesystem Size:           0.13 GB (33280 blocks)
Journals:                  1
Resource Groups:           1
Locking Protocol:          "lock_nolock"
Lock Table:                ""
UUID:                      732F1EAB-C33F-BFA4-32ED-B350822FB27B

1+0 records in
1+0 records out
1 byte (1 B) copied, 5e-05 seconds, 20 kB/s
Initializing fsck
Either the super block is corrupted, or this is not a GFS2 filesystem
Gathering information to repair the gfs2 superblock.  This may take some time.
Block size determined to be: 4096
Found system jindex file at: 0x16
Found system per_node directory at: 0x8059
From per_node's '..' I backtracked the master directory to: 0x15
Found system statfs file at: 0x805b
Found system inum file at: 0x815d
Found system rindex file at: 0x815f
Found system quota file at: 0x8160
Lock protocol assumed to be: lock_dlm
Lock table determined to be: 123456789012345678901234567890123456789012345678901234:repaired
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Starting pass1
Pass1 complete      
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete      
Starting pass3
Pass3 complete      
Starting pass4
Pass4 complete      
Starting pass5
Pass5 complete      
Writing changes to disk
gfs2_fsck complete    

real    0m11.003s
user    0m4.810s
sys     0m3.705s
Comment 9 Martin Bříza 2012-08-16 04:20:28 EDT
Created attachment 604813 [details]
List of fixed issues according to Coverity scan difference

According to Coverity scan for defects difference in RHEL 5.8 -> 5.9 update, this issue was fixed, i.e. does no longer appears in the results.
Comment 12 errata-xmlrpc 2013-01-08 02:32:17 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0079.html

Note You need to log in before you can comment on or make changes to this bug.