summaryrefslogtreecommitdiff
path: root/libc/signal/Makefile.in
diff options
context:
space:
mode:
authorMarcus Haehnel <marcus.haehnel@kernkonzept.com>2023-11-09 14:18:46 +0100
committerWaldemar Brodkorb <wbx@openadk.org>2023-11-10 16:14:20 +0100
commitbfd61a8043511696de226e647951d09deaa95689 (patch)
treed32a45791de13ed73a3a5ec45edc5458c4c2812a /libc/signal/Makefile.in
parent1762b04103e9b2c409649de1857a39867f15718f (diff)
fnmatch: fix possible access beyond of parameter string
In certain cases, fnmatch() could access the next byte beyond the end of he passed pattern. A triggering pattern to match is the following invocation: fnmatch("[A-Z[.", "F", 0) The normal A-Z group match gets us to fnmatch_loop.c:421 and then to fnmatch_loop:599. The F in the filaname matches this expression and we end up in fnmatch_loop:867 which handles skipping the rest of a bracked expression that already matched. Here we enter the case where the next chars to parse are a collating symbol starting with "[." (fnmatch_loop:918). Currently the p pointer is then advanced by one, moving it beyond the "." and to the \0 byte of the pattern string (fnmatch_loop:920). Inside the while loop the pointer is then incremented again and immediately dereferenced, reaching beyond the end of the pattern string. The increment before the while loop must be removed, because only inside the while loop (after the other increment) a check for the end of the string is performend. This is sufficient and the check of the end of the collating symbol is only performed if p[1] is at most the terminating \0 byte. Signed-Off-By: Frank Mehnert <frank.mehnert@kernkonzept.com>
Diffstat (limited to 'libc/signal/Makefile.in')
0 files changed, 0 insertions, 0 deletions