From: busybox
> Sent: 26 February 2022 18:53
>
> While investigating a sporadic crash issue relating to variable substitution
> in
> Alpine Linux, we managed to get a reliable crash when building BusyBox with
> ASan,
> due to the source and destination overlapping for mempcpy, which resulted in
> sporadic data corruption outside ASan.
>
> Per POSIX, memcpy is not allowed to overlap source and destination, as mempcpy
> is a GNU-specific extension to mempcpy, the same semantics can be assumed.
> Accordingly, we use memmove instead, which does not have this limitation.
>
> v2: Forgot to emulate mempcpy's dest+size return value, fixed.
>
> Signed-off-by: Ariadne Conill <[email protected]>
> ---
> shell/ash.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/shell/ash.c b/shell/ash.c
> index adb0f223a..056954059 100644
> --- a/shell/ash.c
> +++ b/shell/ash.c
> @@ -7187,7 +7187,7 @@ subevalvar(char *start, char *str, int strloc,
> len = orig_len - pos;
>
> if (!quotes) {
> - loc = mempcpy(startp, startp + pos, len);
> + loc = memmove(startp, startp + pos, len) + len;
I'd just not rely on the return value at all.
Juat add:
loc = startp + len;
before of after the call.
I'm actually intrigued that ash has picked up a glibc function
I thought it was portable?
The 'best' ash bug (which might now be fixed in the main sources)
was running on the beginning of an on-stack buffer when removing
the '\n' from the end of long $(....) substitutions.
It usually just failed to remove a '\n', but it could remove an
extra character - most likely on BE systems.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
