Whilst auditing some code for insecure uses of temporary files I spotted a potential area of concern in GNU readline. (via an embedded copy of the same inside the Debian source of GDB.) The code in question comes from readline 6.x and is contained in util.c: int _rl_tropen () { char fnbuf[128]; if (_rl_tracefp) fclose (_rl_tracefp); sprintf (fnbuf, "/var/tmp/rltrace.%ld", getpid()); unlink(fnbuf); _rl_tracefp = fopen (fnbuf, "w+"); return _rl_tracefp != 0; } _rl_tropen is invoked from _rl_trace, which is a debugging aid, and it is implied that the function is private, because it is defined in rlprivate.h: /* rlprivate.h -- functions and variables global to the readline library, but not intended for use by applications. */ That said the function _is_ available for using/linking, as a trivial test program would demonstrate: http://pastebin.com/T0XimKED Given how widely used this library is potentially many applications are unknowingly vulnerable to a classic race-condition. I'm throwing this out there for two reasons: * In theory this is exploitable, and should be fixed. * In practice I cannot find an application which invokes _rl_trace, although there are tantalising clues such as this page of commits which refers to a snapshot of GNU Bash: https://gitlab.com/bminor/bash/commit/b0c16657b4514191b4f6c328615d162726758247 Feel free to allocate an identifier, or even scan some of your projects that have readline dependencies ;) This is the first announcement of this issue I've made, I can imagine some more paranoid distributions might wish to update, but equally this seems so low-risk that I didn't consider it worthy of vendor-sec. Steve -- http://tweaked.io/