public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc/release/2.35/master] misc: Fix rare fortify crash on wchar funcs. [BZ 29030] Date: Mon, 25 Apr 2022 13:14:06 +0000 (GMT) [thread overview] Message-ID: <20220425131406.0CCAB3858C52@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c8ee1c85c07b3c9eaef46355cb1095300855e8fa commit c8ee1c85c07b3c9eaef46355cb1095300855e8fa Author: Joan Bruguera <joanbrugueram@gmail.com> Date: Mon Apr 11 19:49:56 2022 +0200 misc: Fix rare fortify crash on wchar funcs. [BZ 29030] If `__glibc_objsize (__o) == (size_t) -1` (i.e. `__o` is unknown size), fortify checks should pass, and `__whatever_alias` should be called. Previously, `__glibc_objsize (__o) == (size_t) -1` was explicitly checked, but on commit a643f60c53876b, this was moved into `__glibc_safe_or_unknown_len`. A comment says the -1 case should work as: "The -1 check is redundant because since it implies that __glibc_safe_len_cond is true.". But this fails when: * `__s > 1` * `__osz == -1` (i.e. unknown size at compile time) * `__l` is big enough * `__l * __s <= __osz` can be folded to a constant (I only found this to be true for `mbsrtowcs` and other functions in wchar2.h) In this case `__l * __s <= __osz` is false, and `__whatever_chk_warn` will be called by `__glibc_fortify` or `__glibc_fortify_n` and crash the program. This commit adds the explicit `__osz == -1` check again. moc crashes on startup due to this, see: https://bugs.archlinux.org/task/74041 Minimal test case (test.c): #include <wchar.h> int main (void) { const char *hw = "HelloWorld"; mbsrtowcs (NULL, &hw, (size_t)-1, NULL); return 0; } Build with: gcc -O2 -Wp,-D_FORTIFY_SOURCE=2 test.c -o test && ./test Output: *** buffer overflow detected ***: terminated Fixes: BZ #29030 Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 33e03f9cd2be4f2cd62f93fda539cc07d9c8130e) Diff: --- debug/tst-fortify.c | 5 +++++ misc/sys/cdefs.h | 12 ++++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/debug/tst-fortify.c b/debug/tst-fortify.c index d65a2fe6e1..03c9867714 100644 --- a/debug/tst-fortify.c +++ b/debug/tst-fortify.c @@ -1504,6 +1504,11 @@ do_test (void) CHK_FAIL_END #endif + /* Bug 29030 regresion check */ + cp = "HelloWorld"; + if (mbsrtowcs (NULL, &cp, (size_t)-1, &s) != 10) + FAIL (); + cp = "A"; if (mbstowcs (wenough, cp, 10) != 1 || wcscmp (wenough, L"A") != 0) diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index 44d3826bca..f1faf8292c 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -162,13 +162,13 @@ || (__builtin_constant_p (__l) && (__l) > 0)) /* Length is known to be safe at compile time if the __L * __S <= __OBJSZ - condition can be folded to a constant and if it is true. The -1 check is - redundant because since it implies that __glibc_safe_len_cond is true. */ + condition can be folded to a constant and if it is true, or unknown (-1) */ #define __glibc_safe_or_unknown_len(__l, __s, __osz) \ - (__glibc_unsigned_or_positive (__l) \ - && __builtin_constant_p (__glibc_safe_len_cond ((__SIZE_TYPE__) (__l), \ - __s, __osz)) \ - && __glibc_safe_len_cond ((__SIZE_TYPE__) (__l), __s, __osz)) + ((__osz) == (__SIZE_TYPE__) -1 \ + || (__glibc_unsigned_or_positive (__l) \ + && __builtin_constant_p (__glibc_safe_len_cond ((__SIZE_TYPE__) (__l), \ + (__s), (__osz))) \ + && __glibc_safe_len_cond ((__SIZE_TYPE__) (__l), (__s), (__osz)))) /* Conversely, we know at compile time that the length is unsafe if the __L * __S <= __OBJSZ condition can be folded to a constant and if it is
reply other threads:[~2022-04-25 13:14 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220425131406.0CCAB3858C52@sourceware.org \ --to=siddhesh@sourceware.org \ --cc=glibc-cvs@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).