[Bug string/16004] memcpy/strcpy: detect memory overlap and crash when error is detected

["slyfox at inbox dot ru" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16004

--- Comment #7 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Paul Pluzhnikov from comment #5)
> FWIW, overlapping memcpy()ies are very common, and not always a "real" bug.
> E.g.
> 
>     void *p = allocate_and_init (10);
>     ...
>     void *q = realloc(p, 20);  // q may or may not == p.
>     memcpy(q, p, 10);

This one looks like a scary use-after-free. I'd expect multithreaded programs
to occasionally  get garbage data in q from p reused by other thread. Or a
SIGSEGGV
if 16-byte bucket containing only p gets munmap()ed.

> I've seen examples of "not a real bug" where p!=q as well.

Can you share an example if it's not too complex? Does it have something to do
with
struct assignment?

> While in theory these all should be fixed, in practice end users may not be
> in a position to do so (e.g. prebuilt 3rd party library where the 3rd party
> doesn't exist anymore, or isn't willing or able to provide a fixed version).

I agree some (almost) correct users might be broken. If there will be too many
broken users then changing glibc would make more harm and would have to be
reverted.

I'd like a checking variant of memcpy() on my dev machines though.

If those prebuilt 3rdparty components are dynamic libraries/binaries then old
memcpy@GLIBC_2.2.5 / @GLIBC_2.14 symver should save them. If those
are static libraries user (dev) would have to pin to older memcpy symversion.
Or patch a binary to call memmove().

Having done such things in the past i'd say it's acceptable if very rare.

-- 
You are receiving this mail because:
You are on the CC list for the bug.