А версии ядер и fuse на этих машинах одинаковые?

(В ответ на комментарий №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 могу дать доступ.

да, похоже пока gluster в GIT сломан и придется откатываться на стабильный 2.0.4.

(В ответ на комментарий №3)
> да, похоже пока gluster в GIT сломан и придется откатываться на стабильный
> 2.0.4.

http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=197 bug submitted to upstream.

см. комментарий upstream'а и http://osdir.com/ml/wine-patches/2009-07/msg00793.html

ping

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.

Dmitry,
Thanks for code samples, useful links and your patience. Have a nice vacation!

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).

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

<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.

Created attachment 4061 [details]
Reduced testcase

JFYI - glusterfs-2.0.8-alt1 в сизифе опять сломан из-за этой проблемы.

> 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

насколько я знаю, в апстриме glusterfs это пофиксили.

На текущей версии проблем не замечено.
glusterfs3-3.3.1-alt1