20977 2009-08-06 19:48:29 +0400 Buffer overflow on volume access 2013-06-24 10:47:39 +0400 1 1 4 Development Sisyphus glusterfs unstable all Linux CLOSED FIXED P3 major --- 1 naf lakostis kas lakostis lav ldv qa-sisyphus oldest_to_newest 95815 0 naf 2009-08-06 19:48:29 +0400 В текущей версии 2.0.4-alt1.git20090715 при обращении к тому происходит переполнение буфера. Система - текущий Sisyphus, проверялось на i586 и x86_64. При обращении (ls) к смонтированному тому клиент glusterfs прекращает работу с сообщением: -------8<------ *** buffer overflow detected ***: glusterfs terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x40)[0xb7faef30] /lib/libc.so.6[0xb7fad180] /lib/libc.so.6(__strcpy_chk+0x44)[0xb7fac4f4] /usr/lib/glusterfs/2.1.0git/xlator/protocol/client.so(client_lookup+0x1bd)[0xb7679a4d] /usr/lib/glusterfs/2.1.0git/xlator/mount/fuse.so(fuse_root_lookup+0x179)[0xb7663149] /usr/lib/glusterfs/2.1.0git/xlator/mount/fuse.so[0xb7663466] /lib/libpthread.so.0[0xb8024480] /lib/libc.so.6(clone+0x5e)[0xb7f9937e] -------8<------ Конфигурация сервера: volume test-storage type storage/posix option directory /mnt/test end-volume volume test-server type protocol/server option transport-type tcp subvolumes test-storage option auth.addr.test-storage.allow 192.168.1.* end-volume Конфигурация клиента: volume test type protocol/client option transport-type tcp option remote-host 192.168.1.254 option remote-subvolume test-storage end-volume Предыдущая версия 2.0.1-alt1.git20090522 (на клиенте и сервере) работает, клиент 2.0.1 с сервером 2.0.4 не работает (не может смонтировать том), клиент 2.0.4 с сервером 2.0.1 падает с вышеприведённым сообщением. 95818 1 lakostis 2009-08-06 22:53:42 +0400 А версии ядер и fuse на этих машинах одинаковые? 95839 2 naf 2009-08-07 12:26:54 +0400 (В ответ на комментарий №1) > А версии ядер и fuse на этих машинах одинаковые? Везде fuse-2.7.3-alt3, glibc-core-2.10.1-alt4, ядро 2.6.27-ovz-smp-alt7. При откате на 2.0.1-alt1.git20090522 обе пары (с x86_64 и с i586) работают нормально. На машину с i586 могу дать доступ. 95920 3 lakostis 2009-08-08 13:34:12 +0400 да, похоже пока gluster в GIT сломан и придется откатываться на стабильный 2.0.4. 95969 4 lakostis 2009-08-09 16:58:33 +0400 (В ответ на комментарий №3) > да, похоже пока gluster в GIT сломан и придется откатываться на стабильный > 2.0.4. http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=197 bug submitted to upstream. 96007 5 lakostis 2009-08-10 11:37:22 +0400 см. комментарий upstream'а и http://osdir.com/ml/wine-patches/2009-07/msg00793.html 96291 6 lakostis 2009-08-12 23:00:32 +0400 ping 96297 7 ldv 2009-08-13 02:03:29 +0400 Unless proven explicitly, I presume that gcc (which does boundary calculations) and glibc (which enables appropriate boundary checks via _FORTIFY_SOURCE switch) does their job properly, and aforementioned links confirm my suppose. There are lot of projects with strcpy() calls which does buffer overflows recognized by glibc/gcc, either indeliberate or intended (see e.g. thread starting at http://lists.altlinux.org/pipermail/devel/2009-July/172997.html). I have examples of intended buffer overflows (see e.g. http://lists.gnu.org/archive/html/bug-tar/2009-07/msg00001.html or http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john/src/charset.c?r1=1.8#rev1.8), and I usually suggest to fix the code to avoid them instead of disabling boundary checks. There are few cases (like gnupg, see http://lists.altlinux.org/pipermail/devel/2009-July/173072.html) where intended buffer overflows are not so easy to fix, though. That is, I suggest to find the glusterfs code which results to buffer overflow detected by strcpy check, analize it and either fix the code or prove that gcc or glibc contains a bug in buffer boundary check. In the unlikely second case, please reassign the bug back to glibc/gcc. P.S. Please do not raise bug priority to critical value unless you really think that I should break my vacation and respond to the bug asap. Thanx in advance. 96301 8 lakostis 2009-08-13 03:24:45 +0400 Dmitry, Thanks for code samples, useful links and your patience. Have a nice vacation! 97478 9 repository-robot 2009-08-28 00:50:45 +0400 glusterfs-2.0.6-alt1.git20090817 -> sisyphus: * Thu Aug 27 2009 L.A. Kostis <lakostis@altlinux> 2.0.6-alt1.git20090817 - switch to GIT v2.0.6-13-g86f2f04. - add hack to disable FORTIFY_SOURCE=2 optimisation due unpredictable logic in gcc (closes #20977). 103118 10 kas 2009-11-14 03:15:37 +0300 In this case we definitely have false positive on strcpy(). typedef struct { uint64_t ino; /* NOTE: used only in case of 'root' lookup */ uint64_t par; uint32_t flags; uint32_t dictlen; char path[0]; char bname[0]; char dict[0]; } __attribute__((packed)) gf_fop_lookup_req_t; gluster tries to put NULL-terminated strings into field path and bname using strcpy() and put some data into dict using memcpy(). http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00419.html 103119 11 kas 2009-11-14 03:32:11 +0300 <Continue previous comment...> __builtin_object_size has been improved recently: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00419.html It's grate feature, but it gives false positive if we have more then one flexible array at the end of a structure. In this case we have three flexible array. It's quite tricky, but it's valid, I guess. I think the best way to fix it in GCC. As workaround you can use memcpy() instead strcpy(), but you have to review usage of all structures in gluster which have more than one flexible array. Other workaround is -D_FORTIFY_SOURCE=1. 103120 12 4061 kas 2009-11-14 03:33:44 +0300 Created attachment 4061 Reduced testcase 103131 13 lakostis 2009-11-14 14:59:40 +0300 JFYI - glusterfs-2.0.8-alt1 в сизифе опять сломан из-за этой проблемы. 103132 14 kas 2009-11-14 15:42:09 +0300 > It's quite tricky, but it's valid, I guess. According to C99 only the last element for struct can be a flexible array. See 6.7.2.1.16. But gluster use pre-C99 syntax for flexible arrays. Currently, I'm not sure if GCC is right place to fix it. One more link: http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html 114834 15 kas 2010-11-04 22:21:52 +0300 насколько я знаю, в апстриме glusterfs это пофиксили. 141110 16 lav 2013-06-24 10:47:39 +0400 На текущей версии проблем не замечено. glusterfs3-3.3.1-alt1 4061 2009-11-14 03:33:44 +0300 2009-11-14 03:33:44 +0300 Reduced testcase 1.c text/plain 557 kas I2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRpby5o PgoKc3RydWN0IHRlc3QgewoJY2hhciBhMVswXTsKCWNoYXIgYTJbMF07Cn0gX19hdHRyaWJ1dGVf XyAoKF9fcGFja2VkX18pKTsKCmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewoJc3Ry dWN0IHRlc3QgKnRlc3Q7CglpbnQgbGVuMSwgbGVuMjsKCglpZiAoYXJnYyA8IDMpCgkJcmV0dXJu IDE7CgoJbGVuMSA9IHN0cmxlbihhcmd2WzFdKSArIDE7CglsZW4yID0gc3RybGVuKGFyZ3ZbMl0p ICsgMTsKCgl0ZXN0ID0gbWFsbG9jKHNpemVvZigqdGVzdCkgKyBsZW4xICsgbGVuMik7CgojaWYg MQoJc3RyY3B5KHRlc3QtPmExLCBhcmd2WzFdKTsKCXN0cmNweSh0ZXN0LT5hMiArIGxlbjEsIGFy Z3ZbMl0pOwojZWxzZQoJbWVtY3B5KHRlc3QtPmExLCBhcmd2WzFdLCBsZW4xKTsKCW1lbWNweSh0 ZXN0LT5hMiArIGxlbjEsIGFyZ3ZbMl0sIGxlbjIpOwojZW5kaWYKCglwcmludGYoIiVzOiVzXG4i LCB0ZXN0LT5hMSwgdGVzdC0+YTIgKyBsZW4xKTsKCglyZXR1cm4gMDsKfQo=