public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "slomo at coaxion dot net" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug string/31509] New: Invalid read in __wcpncpy_avx2() via wcsxfrm() Date: Tue, 19 Mar 2024 11:05:46 +0000 [thread overview] Message-ID: <bug-31509-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=31509 Bug ID: 31509 Summary: Invalid read in __wcpncpy_avx2() via wcsxfrm() Product: glibc Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: string Assignee: unassigned at sourceware dot org Reporter: slomo at coaxion dot net Target Milestone: --- 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) -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2024-03-19 11:05 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-19 11:05 slomo at coaxion dot net [this message] 2024-03-19 12:53 ` [Bug string/31509] " fweimer at redhat dot com 2024-03-19 14:06 ` schwab@linux-m68k.org 2024-03-19 14:12 ` slomo at coaxion dot net 2024-03-19 14:29 ` slomo at coaxion dot net 2024-03-19 14:54 ` fweimer at redhat dot com 2024-03-19 23:21 ` sam at gentoo dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-31509-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).