I am also seeing a buffer overflow with `lfs getstripe` on a SLES12SP3 client running 2.10.59
# lfs setstripe -c -1 all_ost # lfs getstripe all_ost *** buffer overflow detected ***: lfs terminated ======= Backtrace: ========= /lib64/libc.so.6(+0x721af)[0x7f0dbfecb1af] /lib64/libc.so.6(__fortify_fail+0x37)[0x7f0dbff52dc7] /lib64/libc.so.6(+0xf8050)[0x7f0dbff51050] /lib64/libc.so.6(+0xf77bb)[0x7f0dbff507bb] /lib64/libc.so.6(__snprintf_chk+0x78)[0x7f0dbff506d8] /usr/lib64/liblustreapi.so.1(+0xfce4)[0x7f0dc0b5ece4] /usr/lib64/liblustreapi.so.1(+0x7e7c)[0x7f0dc0b56e7c] /usr/lib64/liblustreapi.so.1(+0xa354)[0x7f0dc0b59354] lfs[0x413958] /usr/lib64/liblustreapi.so.1(Parser_execarg+0x51)[0x7f0dc0b69511] lfs[0x40478e] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f0dbfe796e5] lfs[0x404809] ======= Memory map: ======== 00400000-00421000 r-xp 00000000 07:02 8959 /usr/bin/lfs 00620000-00621000 r--p 00020000 07:02 8959 /usr/bin/lfs 00621000-00622000 rw-p 00021000 07:02 8959 /usr/bin/lfs 00622000-00643000 rw-p 00000000 00:00 0 [heap] 7f0dbfc42000-7f0dbfc58000 r-xp 00000000 07:02 3849 /lib64/libgcc_s.so.1 7f0dbfc58000-7f0dbfe57000 ---p 00016000 07:02 3849 /lib64/libgcc_s.so.1 7f0dbfe57000-7f0dbfe58000 r--p 00015000 07:02 3849 /lib64/libgcc_s.so.1 7f0dbfe58000-7f0dbfe59000 rw-p 00016000 07:02 3849 /lib64/libgcc_s.so.1 7f0dbfe59000-7f0dbfff2000 r-xp 00000000 00:17 49292 /lib64/libc-2.22.so 7f0dbfff2000-7f0dc01f2000 ---p 00199000 00:17 49292 /lib64/libc-2.22.so 7f0dc01f2000-7f0dc01f6000 r--p 00199000 00:17 49292 /lib64/libc-2.22.so 7f0dc01f6000-7f0dc01f8000 rw-p 0019d000 00:17 49292 /lib64/libc-2.22.so 7f0dc01f8000-7f0dc01fc000 rw-p 00000000 00:00 0 7f0dc01fc000-7f0dc02f8000 r-xp 00000000 00:17 64019 /lib64/libm-2.22.so 7f0dc02f8000-7f0dc04f7000 ---p 000fc000 00:17 64019 /lib64/libm-2.22.so 7f0dc04f7000-7f0dc04f8000 r--p 000fb000 00:17 64019 /lib64/libm-2.22.so 7f0dc04f8000-7f0dc04f9000 rw-p 000fc000 00:17 64019 /lib64/libm-2.22.so 7f0dc04f9000-7f0dc0518000 r-xp 00000000 07:02 47076 /usr/lib64/libyaml-0.so.2.0.4 7f0dc0518000-7f0dc0717000 ---p 0001f000 07:02 47076 /usr/lib64/libyaml-0.so.2.0.4 7f0dc0717000-7f0dc0718000 r--p 0001e000 07:02 47076 /usr/lib64/libyaml-0.so.2.0.4 7f0dc0718000-7f0dc0719000 rw-p 0001f000 07:02 47076 /usr/lib64/libyaml-0.so.2.0.4 7f0dc0719000-7f0dc0730000 r-xp 00000000 07:02 46012 /usr/lib64/liblnetconfig.so.4.0.0 7f0dc0730000-7f0dc092f000 ---p 00017000 07:02 46012 /usr/lib64/liblnetconfig.so.4.0.0 7f0dc092f000-7f0dc0930000 r--p 00016000 07:02 46012 /usr/lib64/liblnetconfig.so.4.0.0 7f0dc0930000-7f0dc0931000 rw-p 00017000 07:02 46012 /usr/lib64/liblnetconfig.so.4.0.0 7f0dc0931000-7f0dc0939000 rw-p 00000000 00:00 0 7f0dc0939000-7f0dc094e000 r-xp 00000000 00:17 64023 /lib64/libz.so.1.2.8 7f0dc094e000-7f0dc0b4d000 ---p 00015000 00:17 64023 /lib64/libz.so.1.2.8 7f0dc0b4d000-7f0dc0b4e000 r--p 00014000 00:17 64023 /lib64/libz.so.1.2.8 7f0dc0b4e000-7f0dc0b4f000 rw-p 00015000 00:17 64023 /lib64/libz.so.1.2.8 7f0dc0b4f000-7f0dc0b72000 r-xp 00000000 07:02 46051 /usr/lib64/liblustreapi.so.1.0.0 7f0dc0b72000-7f0dc0d71000 ---p 00023000 07:02 46051 /usr/lib64/liblustreapi.so.1.0.0 7f0dc0d71000-7f0dc0d72000 r--p 00022000 07:02 46051 /usr/lib64/liblustreapi.so.1.0.0 7f0dc0d72000-7f0dc0d73000 rw-p 00023000 07:02 46051 /usr/lib64/liblustreapi.so.1.0.0 7f0dc0d73000-7f0dc0d7c000 rw-p 00000000 00:00 0 7f0dc0d7c000-7f0dc0d9d000 r-xp 00000000 00:17 63705 /lib64/ld-2.22.so 7f0dc0f3e000-7f0dc0f43000 rw-p 00000000 00:00 0 7f0dc0f9a000-7f0dc0f9c000 rw-p 00000000 00:00 0 7f0dc0f9c000-7f0dc0f9d000 r--p 00020000 00:17 63705 /lib64/ld-2.22.so 7f0dc0f9d000-7f0dc0f9e000 rw-p 00021000 00:17 63705 /lib64/ld-2.22.so 7f0dc0f9e000-7f0dc0f9f000 rw-p 00000000 00:00 0 7ffdfacaf000-7ffdfacd7000 rw-p 00000000 00:00 0 [stack] 7ffdface7000-7ffdfacea000 r--p 00000000 00:00 0 [vvar] 7ffdfacea000-7ffdfacec000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
jmiller, are you able to run this under gdb or with ltrace to get proper debugging symbols (may need -debug RPM installed)? That should make it more obvious what is going wrong, and hopefully get a fix more quickly.
Thanks for the suggestion, Andreas.
Justin and I dug in to it using gdb + glibc debug, and I see what's wrong in cb_getstripe. It is unpleasantly subtle.
snprintf((char *)¶m->fp_lmd->lmd_lmm, param->fp_lum_size, "%s", fname);
In this snprintf command, fp_lum_size is 4097 (path_max + 1).
lmd_lmm is a struct 32 bytes in size.
The snprintf check code in glibc checks this struct size against the string max passed in to snprintf, and, understandably, fails.
The actual code works because fp_lmd is defined as:
struct lov_user_mds_data_v1 {
lstat_t lmd_st; /* MDS stat struct */
struct lov_user_md_v1 lmd_lmm; /* LOV EA V1 user data */
} __attribute__((packed));
(or _v3 - for this case, it doesn't matter which)
And the allocation for it uses:
"sizeof(lstat_t) + param->fp_lum_size"
for the size (fp_lum_size is the same value as earlier - 4097)
So there is a buffer of sufficient size, and we're writing in to the middle of it. So the code will operate correctly, but the runtime check is understandably angry.
We're writing to the address of a struct and using it as an arbitrary buffer. We should be explicit about the buffer.
I see two ways to make this saner, either of which would - I think? - placate the fortify checks:
1. Use an explicit offset, ie, (pseudo code here) :
((char *)¶m->fp_lmd) + offsetof(struct lov_user_mds_data.lmd_lmm))
2. Make a union in lov_user_mds_data_v{1,3}, roughly like this:
struct lov_user_mds_data_v1 {
lstat_t lmd_st; /* MDS stat struct */
union {
struct lov_user_md_v1 lmd_lmm; /* LOV EA V1 user data */
char *path; /* Explicit pointer for file path */
};
} __attribute__((packed));
Then
snprintf((param->fp_lmd->path, param->fp_lum_size, "%s", fname);
The second seems better to me. Note I haven't tried either of these.
Got my pointer magic wrong, this looks to be correct. (This problem can be reproduced on rhel7 if you use D_FORTIFY_SOURCE)
diff --git a/lustre/include/uapi/linux/lustre/lustre_user.h b/lustre/include/uapi/linux/lustre/lustre_user.h index 59956dc..56e8b4a 100644 --- a/lustre/include/uapi/linux/lustre/lustre_user.h +++ b/lustre/include/uapi/linux/lustre/lustre_user.h @@ -676,12 +676,18 @@ static inline __u32 lov_user_md_size(__u16 stripes, __u32 lmm_magic) #define lov_user_mds_data lov_user_mds_data_v1 struct lov_user_mds_data_v1 { lstat_t lmd_st; /* MDS stat struct */ - struct lov_user_md_v1 lmd_lmm; /* LOV EA V1 user data */ + union { + struct lov_user_md_v1 lmd_lmm; /* LOV EA V1 user data */ + char path[0]; /* Explicit pointer for file path */ + }; } __attribute__((packed)); struct lov_user_mds_data_v3 { lstat_t lmd_st; /* MDS stat struct */ - struct lov_user_md_v3 lmd_lmm; /* LOV EA V3 user data */ + union { + struct lov_user_md_v3 lmd_lmm; /* LOV EA V1 user data */ + char path[0]; /* Explicit pointer for file path */ + }; } __attribute__((packed)); #endifdiff --git a/lustre/utils/liblustreapi.c b/lustre/utils/liblustreapi.c index 2c23a1a501..f46674ab8d 100644 --- a/lustre/utils/liblustreapi.c +++ b/lustre/utils/liblustreapi.c @@ -4507,8 +4507,7 @@ static int cb_getstripe(char *path, DIR *parent, DIR **dirp, void *data, char *fname = strrchr(path, '/'); fname = (fname == NULL ? path : fname + 1);- snprintf((char *)¶m->fp_lmd->lmd_lmm, param->fp_lum_size, - "%s", fname); + snprintf(param->fp_lmd->path, param->fp_lum_size, "%s", fname); ret = ioctl(dirfd(parent), IOC_MDC_GETFILESTRIPE, (void *)¶m->fp_lmd->lmd_lmm);
There was a typo in the Jira reference in the commit message which was why this was not added automatically 
Ah, oops.
Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: https://review.whamcloud.com/31822
Subject: LU-10822 utils: quiet warnings about buffer overflow
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 8219624af9b62468347bf81a18cd35219c3f2a7c
John L. Hammond (john.hammond@intel.com) uploaded a new patch: https://review.whamcloud.com/31838
Subject: LU-10822 utils: don't strip debian utils
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 03e3fbd3feee68932437a2077f618d54692785f4
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31822/
Subject: LU-10822 utils: stop bogus buffer overflow errors
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 7de178ba4afcf8c50c5430b861c9d0eeb84f800f
The spurious stack overflows have been resolved.