Summary: | regoff_t wrong has posix type | ||
---|---|---|---|
Product: | glibc | Reporter: | vIk34 <vik> |
Component: | regex | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | SUSPENDED --- | ||
Severity: | enhancement | CC: | bugdal, eggert, filbranden, fweimer, glibc-bugs-regex, glibc-bugs |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
vIk34
2008-03-16 14:01:07 UTC
This is known but obviously cannot easily be fixed. Suspended until somebody takes this serious to actually take a stab at a solution. You mean, it cannot be easily fixed because it breaks the ABI? (In reply to comment #2) > You mean, it cannot be easily fixed because it breaks the ABI? Yes. On bug-gnulib, the following suggestion was made by Bruno Haible:
> [glibc could] offer some preprocessor macro that makes regoff_t 64-bit wide -
> like it was done for off_t.
>
> Would glibc need to export additional symbols for this? Yes.
>
> Would a compiled glibc need to contain two copies of the regex code? No, the
> 32-bit version could be a thin wrapper around the 64-bit version.
I guess this would count as "somebody takes this serious to actually take a stab
at a solution". Would _REGEX_OFFSET_BITS be okay for you as a macro?
*** Bug 12900 has been marked as a duplicate of this bug. *** The original bug report is old, and POSIX has changed in the meantime: regoff_t is now required to be at least as large as ptrdiff_t and ssize_t. (Previously this was off_t and ssize_t.) See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/regex.h.html Yes, thanks for updating/clarifying that. Is there any chance of this ever getting fixed? I suspect there may even be obscure vulnerabilities related to this, if you can somehow pass a string longer than 4gb to regexec and cause the matches to get truncated, and thus for the caller to either dereference memory at a negative offset, exposing data it should not, or treating non-matching data early in the string as a match. Obviously these could be closed by making the interface even more non-conforming and rejecting offsets that would overflow, but I think the proper solution is to add a versioned symbol and fix the type. |