[LU-3048] lfs getstripe heap corruption with MOUNT_2=y

Related — Tue, 23 Apr 2013 14:01:55 +0000

To reproduce:

# MOUNT_2=y llmount.sh 
...
# cd /mnt/lustre
# lfs setstripe -c2 LOLWUT
# lfs getstripe LOLWUT
# lfs getstripe LOLWUT
LOLWUT
lmm_stripe_count:   2
lmm_stripe_size:    1048576
lmm_layout_gen:     0
lmm_stripe_offset:  0
	obdidx		 objid		 objid		 group
	     0	             1	          0x1	             0
	     1	             1	          0x1	             0

*** glibc detected *** lfs: free(): invalid next size (normal): 
...
# MALLOC_CHECK_=1 lfs getstripe LOLWUT
LOLWUT
lmm_stripe_count:   2
lmm_stripe_size:    1048576
lmm_layout_gen:     0
lmm_stripe_offset:  0
	obdidx		 objid		 objid		 group
	     0	             1	          0x1	             0
	     1	             1	          0x1	             0

*** glibc detected *** lfs: free(): invalid pointer: 0x0000000001d1f1a0 ***
*** glibc detected *** lfs: free(): invalid pointer: 0x0000000001d1f270 ***
# ls /proc/fs/lustre/llite/*/max_easize
/proc/fs/lustre/llite/lustre-ffff88015536fc00/max_easize
/proc/fs/lustre/llite/lustre-ffff880173af2800/max_easize
# cat /proc/fs/lustre/llite/*/max_easize
48
128

get_mds_md_size() may be reading the max_easize from the file corresponding to /mnt/lustre2, in which it's allocating a 48 byte lum to recieve the stripe info. Since this uses IOC_MDC_GETFILESTRIPE the kernel cannot infer the size of the userspace buffer, but it write 128 bytes of stripe info. Hence the kernel in copy_to_user() is corruption the heap.

liblustreapi could be fixed to locate the correct max_easize file. But this still leaves us with a TOCTTOU issue as the max_easize can change at any time from userspace's POV.

Whamcloud Community JIRA

[LU-3048] lfs getstripe heap corruption with MOUNT_2=y