Bug 158974

Description of problem:
If a module that is signed with a key that is not installed in the kernel
keyring in insmodded/modprobed, the kernel will crash

Version-Release number of selected component (if applicable):
2.6.x

How reproducible:
Customer reports always

Steps to Reproduce:
1.build a module 
2.sign the module with a key not known to the kernel
3.insmod/modprobe the module
  
Actual results:
The following oops:
Backtrace is shown below:
PID: 2391   TASK: e0000040c1228000  CPU: 3   COMMAND: "modprobe"
#0 [BSP:e0000040c12293f0] start_disk_dump at a000000200370b10
#1 [BSP:e0000040c12293d0] try_crashdump at a0000001000a6a90
#2 [BSP:e0000040c1229390] die at a00000010003c980
#3 [BSP:e0000040c1229328] ia64_do_page_fault at a00000010005db10
#4 [BSP:e0000040c1229328] ia64_leave_kernel at a00000010000f480
#5 [BSP:e0000040c1229310] mpi_normalize at a000000100214bb0
#6 [BSP:e0000040c12292e0] mpi_cmp at a000000100216aa0
#7 [BSP:e0000040c1229260] DSA_verify at a000000100211ac0
#8 [BSP:e0000040c1229200] ksign_verify_signature at a00000010020e900
#9 [BSP:e0000040c12290a8] module_verify_signature at a0000001000b29c0
#10 [BSP:e0000040c1229008] module_verify at a0000001000b1750
#11 [BSP:e0000040c1228ed0] load_module at a0000001000ac7d0
#12 [BSP:e0000040c1228e60] sys_init_module at a0000001000af230
#13 [BSP:e0000040c1228e60] ia64_ret_from_syscall at a00000010000f320
#14 [BSP:e0000040c1228e60] __kernel_syscall_via_break at a000000000010640

Expected results:
An error message regarding the unknown nature of the key, and a failure to
install the module

Additional info:
This appears to be a problem in ksign_get_public_key.  When this function goes
to search for the key to match the signature of the module, a failed search will
result in the return of a pointer to the list head structure.  The calling
function expects a failed search to return NULL.  Since the list head of the
keyring has no surrounding ksign_public_key structure the calling function may
access unallocated memory, which can result in an oops.  Since we need to cross
a page boundary into an unallocated page to force this oops to happen, its
presentation is dependent on the linkers placement of the list head strucutre in
the kernel address space.  As such this may not present on all arches.  It was
origionally reported by Fujitsu on ia64 in Issue Tracker number 72903