OpenAFS Master Repository branch, openafs-stable-1_8_x, updated. openafs-stable-1_8_10-3-g6fc1d81

Gerrit Code Review
Thu, 17 Aug 2023 13:08:57 -0400

The following commit has been merged in the openafs-stable-1_8_x branch:
commit 6fc1d81eb7f8c06f5fea54403419b30b4d95fb97
Author: Cheyenne Wills <>
Date:   Mon Jul 3 13:14:52 2023 -0600

    gcc: Avoid false positive use-after-free in crypto
    Due to a bug in gcc-12 and gcc-13, several warnings are generated for a
    use-after-free in crypto.c, which leads to a build failure with
      src/external/heimdal/krb5/crypto.c:1157:9: error: pointer ‘p’ may be
          used after ‘realloc’ [-Werror=use-after-free]
       1157 |         free(p);
            |         ^~~~~~~
      src/external/heimdal/krb5/crypto.c:1155:20: note: call to ‘realloc’
       1155 |     result->data = realloc(p, sz);
            |                    ^~~~~~~~~~~~~~
    However, reviewing the code around these warnings shows that the
    use-after-free warnings are incorrectly generated (false positive). The
    documentation for realloc states that realloc will return a NULL and not
    alter the storage passed if there was an error allocating and the size
    passed is non-zero.
    There is a possible work-around for the false positive. One can use a
    variable that is not a member of a structure to hold and test the value
    returned from realloc, then update the structure member from that
    However, the code that is producing the message is in a heimdal external
    file, so we cannot modify the source.  So just use the compiler flag
    -Wno-use-after-free to avoid the warning/error.
    Update configure to add tests for the -Wno-use-after-free flag, update
    the Makefile to add the flag for CFLAGS.crypto.lo, and update CODING
    for the new exception.
    Because this is an important check, only disable the warning if the
    compiler exhibits this specific bug.  We do this by adding specific
    configure tests for the compiler bug and conditionally set a CFLAG
    variable if the bug is present.
    NOTE: The false positive and work-around can be demonstrated with the
    following code using gcc-12 (with -O0) or gcc-13 (not sensitive to the
    optimization level):
        somestruct->somepointer = realloc(ptr, somesize);
        if (somestruct->somepointer == NULL && somesize != 0) {
            free(ptr);   << gets flagged as use-after-free
            handle enomem...
    However the following doesn't get flagged:
        char *tmpptr = realloc(ptr, somesize);
        if (tmpptr == NULL && somesize != 0) {
            handle enomem...
        somestruct->somepointer = tmpptr;
    The GCC ticket
    has been marked as confirmed.
    Reviewed-by: Benjamin Kaduk <>
    Tested-by: BuildBot <>
    Reviewed-by: Andrew Deason <>
    (cherry picked from commit f2003ed68c2fecf679d0b04146427258d39369ea)
    Change-Id: Ib7ae86c66f0ef1fc12d4ff4b796b712dc97e2e13
    Tested-by: BuildBot <>
    Reviewed-by: Michael Meffie <>
    Reviewed-by: Andrew Deason <>
    Reviewed-by: Mark Vitale <>
    Reviewed-by: Stephan Wiesand <>

 CODING                         |  2 ++
 src/cf/gcc.m4                  | 51 ++++++++++++++++++++++++++++++++++++++++++
 src/cf/osconf.m4               |  1 +
 src/crypto/rfc3961/ |  1 +
 4 files changed, 55 insertions(+)

OpenAFS Master Repository