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 02-04-2011, 10:10 AM
Petr Tesarik
 
Default Fix segmentation violation in symbol_search

Subject: Fix segmentation violation in symbol_search

Fix a possible segmentation violation in crash if a module name
is not NUL-terminated. Although store_module_symbols_v2 complains
about an overly long module name, there are several problems
with the current approach:

1. The maximum size is hard-wired in defs.h and the current
constant doesn't even match struct module's name field size
on any architecture.

2. If the string is too long, it is probably not NUL-terminated,
so we can't use strlen() on it.

3. Even though only the first MAX_MOD_NAME-1 bytes are copied
to struct load_module, the _MODULE_* pseudo-symbol names are
generated from the unabridged module name. As a consequence,
they are not found further on in the loop at the end of
store_module_symbols_v2, so lm->mod_symtable remains NULL
for that module. The symbol_search() function is not
prepared for that situation and tries to dereference that
NULL pointer here:

sp = lm->mod_symtable;
sp_end = lm->mod_symend;

for ( ; sp <= sp_end; sp++) {
if (!pseudos && MODULE_PSEUDO_SYMBOL(sp))
^^^^

Regards,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-08-2011, 01:18 PM
Dave Anderson
 
Default Fix segmentation violation in symbol_search

----- Original Message -----
> Subject: Fix segmentation violation in symbol_search
>
> Fix a possible segmentation violation in crash if a module name
> is not NUL-terminated. Although store_module_symbols_v2 complains
> about an overly long module name, there are several problems
> with the current approach:
>
> 1. The maximum size is hard-wired in defs.h and the current
> constant doesn't even match struct module's name field size
> on any architecture.

The hardwired value of 64 is based upon the kernel's MODULE_NAME_LEN,
which is either 56 bytes on a 64-bit machine, or 60 bytes on a 32-bit
machine -- (64 - sizeof(unsigned long)) -- so the crash utility's
hardwired "MAX_MOD_NAME" value of 64 was used as a safe value and
to guarantee a NULL terminator. So I don't understand how there can
be an overrun issue in store_module_symbols_v2()?

On earlier 2.4 era kernels, the module.name was a pointer to a
variable length name string, but that is handled differently by
store_module_symbols_v1(). So maybe the pseudo-symbol name creation
patch should be done there instead of in store_module_symbols_v2()?

Maybe I'm missing something...

Dave

> 2. If the string is too long, it is probably not NUL-terminated,
> so we can't use strlen() on it.
>
> 3. Even though only the first MAX_MOD_NAME-1 bytes are copied
> to struct load_module, the _MODULE_* pseudo-symbol names are
> generated from the unabridged module name. As a consequence,
> they are not found further on in the loop at the end of
> store_module_symbols_v2, so lm->mod_symtable remains NULL
> for that module. The symbol_search() function is not
> prepared for that situation and tries to dereference that
> NULL pointer here:
>
> sp = lm->mod_symtable;
> sp_end = lm->mod_symend;
>
> for ( ; sp <= sp_end; sp++) {
> if (!pseudos && MODULE_PSEUDO_SYMBOL(sp))
> ^^^^
>
> Regards,
> Petr Tesarik
>
> --
> 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 10:12 PM.

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