The changes were derived from what has been committed to NetBSD, with
modifications. These are:
1. Preserve the existsing GLOB_LIMIT behaviour by including the number
of matches to the set of parameters to limit.
2. Change some of the limits to avoid impacting normal use cases:
GLOB_LIMIT_STRING - change from 65536 to ARG_MAX so that glob(3)
can still provide a full command line of expanded names.
GLOB_LIMIT_STAT - change from 128 to 1024 for no other reason than
that 128 feels too low (it's not a limit that impacts the
behaviour of the test program listed in CVE-2010-2632).
GLOB_LIMIT_PATH - change from 1024 to 65536 so that glob(3) can
still provide a fill command line of expanded names.
3. Protect against buffer overruns when we hit the GLOB_LIMIT_STAT or
GLOB_LIMIT_READDIR limits. We append SEP and EOS to pathend in
those cases. Return GLOB_ABORTED instead of GLOB_NOSPACE when we
would otherwise overrun the buffer.
This change also modifies the existing behaviour of glob(3) in case
GLOB_LIMIT is specifies by limiting the *new* matches and not all
matches. This is an important distinction when GLOB_APPEND is set or
when the caller uses a non-zero gl_offs. Previously pre-existing
matches or the value of gl_offs would be counted in the number of
matches even though the man page states that glob(3) would return
GLOB_NOSPACE when gl_matchc or more matches were found.
The limits that cannot be circumvented are GLOB_LIMIT_STRING and
GLOB_LIMIT_PATH all others can be crossed by simply calling glob(3)
again and with GLOB_APPEND set.
The entire description above applies only when GLOB_LIMIT has been
specified of course. No limits apply when this flag isn't set!
Obtained from: Juniper Networks, Inc
daab0b01ed