This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/17495] New: strcmp strncmp over-reads, may cause SIGSEGV


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

            Bug ID: 17495
           Summary: strcmp strncmp over-reads, may cause SIGSEGV
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: tstark at gmail dot com
                CC: drepper.fsp at gmail dot com

Created attachment 7838
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7838&action=edit
Test case

Hi,

This is my first bug report. I know there are similar duplicates on this, they
are marked as fixed and I want to re-escalate this.

OS: Linux x86 64
glibc: Verified on 2.11.3 and most recent 2.20, probably also on anything in
between.
       Verified not to occur on 2.4.

Summary - 
Using strcmp() and strncmp() may cause buffer over-read, and even a page-fault
and crash if the over-read crosses a page into an un-mapped page.

Description -
This was first experienced with malloc, though the problem is obviously
reproducible with mmap as well.

There is a buffer alignment that may cause the following assembly instruction
over-read 16B after the end of a buffer (even with strncmp!) -
sysdeps/x86_64/strcmp.S : __strncmp_sse42 : movdqa (%rdi, %rcx), %xmm2

Let's assume we have two strings, str1 and str2.
Under my configuration, str1 ends (terminating null byte) at the end of a 64B
block. i.e. ( str1 + str1_length ) % 64 = 0.
str2 begins at some byte, which is not aligned to 16B, i.e. str2 % 16 != 0.
This configuration is not uncommon when looking for sub-strings manually.

Let's assume both strings are equal, therefore strcmp should return true after
reading the last byte of str1.
What happens is that the above movdqa instruction reads the next 16B after the
last byte of str1. This could be on a different page and cause a segfault.
If no segfault happens, strcmp returns that the strings are equal and
everything is ok, even though we over-read the data.

I've attached a simple example with malloc (over-reads but no segfault) and
then with mmap (which is set to cause a segfault).

If I missed anything relevant or need to supply any extra information I'd be
happy to supply.

Thank you,

Tomer

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]