|
Sources Bugzilla – Full Text Bug Listing |
| Summary: | fnmatch() alloca() abuse, with security consequence | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Chris Evans <scarybeasts> |
| Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | glibc-bugs |
| Priority: | P2 | ||
| Version: | 2.9 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
I cannot reproduce any problem. I did check in changes to keep the alloca use limited. |
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]