This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/18096] null deref in wordexp/parse_dollars/parse_arith


https://sourceware.org/bugzilla/show_bug.cgi?id=18096

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Kostya Serebryany from comment #7)
> a related question: is wordexp() really supposed to call setenv()?
> It's not just an undocumented side effect, but it also introduces
> thread-unsafety
> (AFAICT, setenv is not expected to be thread-safe, but wordexp is)

It is documented.

The manual already list wordexp as MT-unsafe, see glibc/manual/pattern.texi:

@deftypefun int wordexp (const char *@var{words}, wordexp_t
*@var{word-vector-ptr}, int @var{flags})
@safety{@prelim{}@mtunsafe{@mtasurace{:utent} @mtasuconst{:@mtsenv{}} @mtsenv{}
@mtascusig{:ALRM} @mtascutimer{} @mtslocale{}}@asunsafe{@ascudlopen{}
@ascuplugin{} @ascuintl{} @ascuheap{} @asucorrupt{}
@asulock{}}@acunsafe{@acucorrupt{} @aculock{} @acsfd{} @acsmem{}}}

Which translates into:

Preliminary: | MT-Unsafe race:utent const:env env sig:ALRM timer locale | AS-
Unsafe dlopen plugin i18n heap corrupt lock | AC-Unsafe corrupt lock fd mem |
See Section 1.2.2.1 [POSIX Safety Concepts], page 2.

So some of the MT-safety issues can be mitigated, others can't.

It needs to call setenv() to correctly handle expansions that might use that
value. This is all again a QoI issues, it's likely the only safe way to handle
any this is in a child process, which solves the SIGFPE issue also. Keeping the
side-effects in the child process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]