https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123877

            Bug ID: 123877
           Summary: Sanitizers fails to intercept deprecated symbols
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kirelagin at gmail dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Due to a recent change in glibc (I did not bisect, but my guess is it was the
fix of https://sourceware.org/bugzilla/show_bug.cgi?id=14932 in glibc 2.36),
libasan is no longer able to intercept deprecated symbols.

```shell_session
(glibc 2.28) $ ./dlsym
dlsym(RTLD_DEFAULT, xdrstdio_create)  => (nil)
dlsym(RTLD_NEXT, xdrstdio_create)  => 0x7ffff7965180
dlvsym(RTLD_DEFAULT, xdrstdio_create) => 0x7ffff7965180
dlvsym(RTLD_NEXT, xdrstdio_create) => 0x7ffff7965180

(glibc 2.40) $ ./dlsym
dlsym(RTLD_DEFAULT, xdrstdio_create)  => (nil)
dlsym(RTLD_NEXT, xdrstdio_create)  => (nil)
dlvsym(RTLD_DEFAULT, xdrstdio_create) => 0x7ffff7f1c330
dlvsym(RTLD_NEXT, xdrstdio_create) => 0x7ffff7f1c330
```

The problem is that, if a symbol was deprecated (i.e. it is now hidden aka has
no default version), `dlsym` will not return it. If a legacy binary that links
to this symbol tries to call it, the corresponding interceptor will have
nullptr recorded as the real symbol and will crash trying to call nullptr
(similar to #123874).

The only affected symbol in current GCC master, as far as I can tell, is:

* pthread_mutexattr_getrobust_np@GLIBC_2.4

However, there used to be other interceptors, which got removed, and,
undoubtedly, there will eventually be more deprecated symbols in glibc, so this
is not just about this one symbol.

I think, the best fix would be to switch the interceptor to
`COMMON_INTERCEPT_FUNCTION_VER` with the specific version, as long as the build
is targeting glibc, or maybe even intercept both to have the same binary be
compatible with both glibc and non-glibc.

(Note: however, it is very important to only use versioned interceptors for
functions that have been deprecated for removal, not merely being moved to a
separate library.)

Reply via email to