Skip to content

Improper use of strerror_r in native/dispatch.c #215

@LionelCons

Description

@LionelCons

In native/dispatch.c, we have:

#define STR_ERROR(CODE,BUF,LEN) (strerror_r(CODE, BUF, LEN), BUF)

and then later:

  if (error) {
    char emsg[1024];
    snprintf(msg, sizeof(msg), "[%d]%s", error, STR_ERROR(error, emsg, sizeof(emsg)));
    throw_type = ELastError;
    throw_msg = msg;
  }

However, strerror_r exists in two very different flavors: XSI and GNU, see for instance http://unixhelp.ed.ac.uk/CGI/man-cgi?strerror.

When the GNU flavor is used, the emsg buffer will maybe not be written to and the code will therefore use uninitialized data. This is exactly what we see in practice in our Java code on Linux 32-bits with errors like:

rename(x1, x2): [2]<?L
mkdir(d1): [17]?*??_?�x?

FWIW, the Linux man page contains:

   The XSI-compliant version of strerror_r() is provided if:
   (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
   Otherwise, the GNU-specific version is provided.

So either the code should force the use of the XSI version of strerror_r or it should conditionally define STR_ERROR to work in both cases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions