Re: [PATCH] Fix segmentation violation in symbol_search

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility

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


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux