11883 2010-08-05 05:04:00 +0000 fnmatch() alloca() abuse, with security consequence 2010-08-10 04:27:18 +0000 1 1 1 Unclassified glibc libc 2.9 All All RESOLVED FIXED P2 normal --- 1 scarybeasts drepper.fsp glibc-bugs oldest_to_newest 44417 0 scarybeasts 2010-08-05 05:04:39 +0000 Demo: #include <err.h> #include <fnmatch.h> #include <locale.h> #include <stdlib.h> #include <string.h> int main(int argc, const char* argv[]) { size_t num_as; char* p; setlocale(LC_ALL, "en_US.UTF8"); if (argc < 2) { errx(1, "Missing argument."); } num_as = atoi(argv[1]); if (num_as < 5) { errx(1, "Need 5."); } p = malloc(num_as); if (!p) { errx(1, "malloc() failed."); } memset(p, 'A', num_as); p[num_as - 1] = '\0'; p[0] = 'f'; p[1] = 'o'; p[2] = 'o'; p[3] = '.'; fnmatch("*.anim[1-9j]", p, 0); return 0; } ./a.out 3000000 Segmentation fault (If your default max stack size is greater than the default 8MB then you may need a larger number) I chatted to some people and they suggested that there's probably a missing __libc_use_alloca() somewhere. This was the source of a nasty Chromium bug which was worked around for now. [Random aside: I can't seem to find the default value for __libc_alloca_cutoff but if it is > PAGE_SIZE then that in of itself would cause serious issues since most people don't compile glibc with -fstack-check, combined with the fact that pthread stacks by default are separated with a single guard page] 44498 1 drepper.fsp 2010-08-10 04:27:18 +0000 I cannot reproduce any problem. I did check in changes to keep the alloca use limited.