Re: [Crash-utility] [PATCH] 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility