FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 03-19-2012, 08:56 AM
Toshikazu Nakayama
 
Default avoid read_string() for no terminated buf.

Hi Dave,

I met stack smashing detection by glibc at read_string()
then this patch is proposal.

*** stack smashing detected ***: crash terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x4c)[0xfe12380]
/lib/libc.so.6(__fortify_fail+0x0)[0xfe12334]
./crash[0x10147bf0]
./crash(display_sys_stats+0xcf8)[0x1011cd74]
./crash(main_loop+0x300)[0x10068960]
./crash(current_interp_command_loop+0x48)[0x1021ac2c]
./crash[0x1021bcc4]
./crash(catch_errors+0x84)[0x1021a0c4]
./crash[0x1021d37c]
./crash(catch_errors+0x84)[0x1021a0c4]
./crash(gdb_main+0x58)[0x1021d3e8]
./crash(gdb_main_entry+0x6c)[0x1021d490]
./crash(gdb_main_loop+0x3b4)[0x10130e5c]
./crash(main+0x38c0)[0x10068650]
/lib/libc.so.6(+0x1f568)[0xfd36568]
/lib/libc.so.6(+0x1f728)[0xfd36728]

An failed vmalloc() including non terminated with NULLCHAR is root cause,
but I think it is better to keep other utilities without killed.

Thanks,
Toshi
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 03-22-2012, 08:32 AM
Toshikazu Nakayama
 
Default avoid read_string() for no terminated buf.

(2012/03/22 4:18), Dave Anderson wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> Hi Dave,
>>>
>>> I met stack smashing detection by glibc at read_string()
>>> then this patch is proposal.
>>>
>>> *** stack smashing detected ***: crash terminated
>>> ======= Backtrace: =========
>>> /lib/libc.so.6(__fortify_fail+0x4c)[0xfe12380]
>>> /lib/libc.so.6(__fortify_fail+0x0)[0xfe12334]
>>> ./crash[0x10147bf0]
>>> ./crash(display_sys_stats+0xcf8)[0x1011cd74]
>>> ./crash(main_loop+0x300)[0x10068960]
>>> ./crash(current_interp_command_loop+0x48)[0x1021ac2c]
>>> ./crash[0x1021bcc4]
>>> ./crash(catch_errors+0x84)[0x1021a0c4]
>>> ./crash[0x1021d37c]
>>> ./crash(catch_errors+0x84)[0x1021a0c4]
>>> ./crash(gdb_main+0x58)[0x1021d3e8]
>>> ./crash(gdb_main_entry+0x6c)[0x1021d490]
>>> ./crash(gdb_main_loop+0x3b4)[0x10130e5c]
>>> ./crash(main+0x38c0)[0x10068650]
>>> /lib/libc.so.6(+0x1f568)[0xfd36568]
>>> /lib/libc.so.6(+0x1f728)[0xfd36728]
>>>
>>> An failed vmalloc() including non terminated with NULLCHAR is root cause,
>>> but I think it is better to keep other utilities without killed.
>>
>> This patch changes the return value of read_string() in a
>> situation where the requested number of bytes does not include
>> a NULL terminator. Note that the function is described like
>> this:
>>
>> /*
>> * Try to read a string of non-NULL characters from a memory location,
>> * returning the number of characters read.
>> */
>> int
>> read_string(ulong kvaddr, char *buf, int maxlen)
>> {
>>
>> The "maxlen" parameter is there to handle case where the requested
>> memory read does not contain a NULL character. And there may be
>> other callers that use the function to read until a NULL *or* until
>> the maxlen is reached.
>>
>> That being said, there may be a bug in there somewhere, or it
>> could be written differently, but I don't want to change the
>> function's behavior (return value).
>>
>> You mention:
>>
>>> an failed vmalloc() including non terminated with NULLCHAR
>>> is the root cause".
>>
>> Can you elaborate on what you mean by that? I want to be able
>> to reproduce this, but I cannot.
>
> Hi Toshi,
>
> I'm still not clear on how you were able to make this happen in
> the "normal" course of events, but I was able to kludge up a test
> with more than a page-size of non-NULL characters, and did manage
> to force a segmentation violation.

Hi Dave,

Thanks for your support and I'm sorry that my previous analysis was very poor.

> There's really no reason for read_string() to buffer the data given
> that it has aways zeroed out the user buffer first. And there's also
> no reason for it to break up the request into per-page segments.

Yes, you're right and I've been mistaken about root cause.
(By skipping read_string(), true root cause was also skipped...)

I added debug messages in ppc_processor_speed() and found out
a direct tie to "*** stack smashing detected ***".
It's a ppc specific problem, and fixed with attached patch.

I'm not sure about strcasecmp() implementation or specification
but if "buflen - 1" size characters are passed,
looked to be detected as stack corruption.

Thanks a lots for your support,
Toshi

> So I'm just re-writing/simplifying the read_string() function to
> zero out and then try to read maxlen bytes into the user buffer, then
> zero out everything after the first NULL that it finds, and return
> the number of consecutive non-NULL characters from the starting
> address.
>
> Thanks,
> Dave
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 09:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org