alpine 3.8
race weakness #32


Weakness Breakdown


A race condition exists when parallel code accesses shared data without proper coordination. An attack that uses a race-condition weakness takes advantage of the unsafe data access to manipulate how one of the parallel sections of code reacts. Even though each process runs as intended, the outcome is unexpected. For example, consider a bank service that depends on an encryption key that it reads from a known location. An independent cryptography service is responsible for generating the key and placing it where the bank is expected to read it in a timely manner. If the bank and cryptography services do not coordinate with each other, then the bank may read a blank encryption key before cryptography writes the key to the location. This can effectively turn off all encryption for the bank without either service, or the administrator, knowing that something has gone wrong.

Warning code(s):

This accepts filename arguments; if an attacker can move those files, a race condition results..

File Name:



The highlighted line of code below is the trigger point of this particular Alpine 3.8 race weakness.


Interface RawFileIO::interface() const { return RawFileIO_iface; }

    Workaround for opening a file for write when permissions don't allow.
    Since the kernel has already checked permissions, we can assume it is ok to
    provide access.  So force it by changing permissions temporarily.  Should
    be called with a lock around it so that there won't be a race condition
    with calls to lstat picking up the wrong permissions.

    This works around the problem described in
    Without this, "umask 0777 ; echo foo > bar" fails.

    Sets errno when -1 is returned.
static int open_readonly_workaround(const char *path, int flags) {
  int fd = -1;
  struct stat stbuf;
  memset(&stbuf, 0, sizeof(struct stat));
  if (lstat(path, &stbuf) != -1) {
    // make sure user has read/write permission..
    if (chmod(path, stbuf.st_mode | 0600) != -1) {
      fd = ::open(path, flags);
      chmod(path, stbuf.st_mode);
  return fd;

    We shouldn't have to support all possible open flags, so untaint the flags
    argument by only taking ones we understand and accept.
    -  Since the kernel has already done permission tests before calling us, we
       shouldn't have to worry about access control.
    -  Basically we just need to distinguish between read and write flags
    -  Also keep the O_LARGEFILE flag, in case the underlying filesystem needs
int RawFileIO::open(int flags) {
  bool requestWrite = (((flags & O_RDWR) != 0) || ((flags & O_WRONLY) != 0));
  VLOG(1) << "open call, requestWrite = " << requestWrite;

  // if we have a descriptor and it is writable, or we don't need writable..
  if ((fd >= 0) && (canWrite || !requestWrite)) {
    VLOG(1) << "using existing file descriptor";
    return fd;  // success

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark on a world­wide basis.