Bug 31509 - Invalid read in __wcpncpy_avx2() via wcsxfrm()
Summary: Invalid read in __wcpncpy_avx2() via wcsxfrm()
Status: RESOLVED MOVED
Alias: None
Product: glibc
Classification: Unclassified
Component: string (show other bugs)
Version: 2.38
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-19 11:05 UTC by Sebastian Dröge
Modified: 2024-03-19 23:21 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Dröge 2024-03-19 11:05:46 UTC
The following code reliably results in invalid reads when running under valgrind. This is with glibc 2.38 from Fedora 39.

Whether an invalid read happens or not seems to depend on the alignment of the input buffer or something else that I couldn't figure out completely yet. In the code below it always happens on the last call, i.e. with the second malloc'd buffer.

It seems like __wcpncpy_avx2() wrongly assumes under certain conditions that at least 32 bytes (i.e. one AVX register) of input data is available.

--------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <wchar.h>

int main() {

  const wchar_t in[] = {L'a', L'b', L'c', 0};
  wchar_t out[3+1] = {0, };

  printf("%p %p\n", in, out);
  size_t res = wcsxfrm(out, in, 3);
  printf("%lu\n", res);

  wchar_t *in2 = malloc(sizeof(wchar_t) * 4);
  memcpy(in2, in, sizeof(in));
  printf("%p %p\n", in2, out);
  res = wcsxfrm(out, in2, 3);
  printf("%lu\n", res);
  free(in2);

  wchar_t *in3 = malloc(sizeof(wchar_t) * 4);
  memcpy(in3, in, sizeof(in));
  printf("%p %p\n", in3, out);
  res = wcsxfrm(out, in3, 3);
  printf("%lu\n", res);
  free(in3);
}

--------

==139735== Memcheck, a memory error detector
==139735== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==139735== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==139735== Command: ./test
==139735== 
0x1fff000330 0x1fff000320
3
0x4a5c480 0x1fff000320
3
0x4a5c4d0 0x1fff000320
==139735== Invalid read of size 32
==139735==    at 0x49DAA2E: __wcpncpy_avx2 (strncpy-avx2.S:85)
==139735==    by 0x493C560: wcsxfrm_l (strxfrm_l.c:679)
==139735==    by 0x4012A1: main (in /home/slomo/tmp/test/test)
==139735==  Address 0x4a5c4d0 is 0 bytes inside a block of size 16 alloc'd
==139735==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==139735==    by 0x401258: main (in /home/slomo/tmp/test/test)
==139735== 
3
==139735== 
==139735== HEAP SUMMARY:
==139735==     in use at exit: 0 bytes in 0 blocks
==139735==   total heap usage: 3 allocs, 3 frees, 1,056 bytes allocated
==139735== 
==139735== All heap blocks were freed -- no leaks are possible
==139735== 
==139735== For lists of detected and suppressed errors, rerun with: -s
==139735== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Comment 1 Florian Weimer 2024-03-19 12:53:32 UTC
(In reply to Sebastian Dröge from comment #0)
> ==139735== Invalid read of size 32
> ==139735==    at 0x49DAA2E: __wcpncpy_avx2 (strncpy-avx2.S:85)
> ==139735==    by 0x493C560: wcsxfrm_l (strxfrm_l.c:679)
> ==139735==    by 0x4012A1: main (in /home/slomo/tmp/test/test)
> ==139735==  Address 0x4a5c4d0 is 0 bytes inside a block of size 16 alloc'd
> ==139735==    at 0x484280F: malloc (vg_replace_malloc.c:442)
> ==139735==    by 0x401258: main (in /home/slomo/tmp/test/test)
> ==139735== 

This read does not case a page boundary, so overreading is harmless here. This seems more like a valgrind limitation.
Comment 2 Andreas Schwab 2024-03-19 14:06:20 UTC
Please report that to the valgrind project so that they can add that to their default suppression list.
Comment 3 Sebastian Dröge 2024-03-19 14:12:22 UTC
Will do, thanks. OOC, how does the function make sure that it won't read across a page boundary?
Comment 4 Sebastian Dröge 2024-03-19 14:29:17 UTC
Reported to valgrind at https://bugs.kde.org/show_bug.cgi?id=484002
Comment 5 Florian Weimer 2024-03-19 14:54:21 UTC
Moved per comment 4.