Description of problem: Some of the signed kernel modules with debug infomation can't be inserted to kernel with EPERM error. Version-Release number of selected component (if applicable): rhel 5.3 How reproducible: Compile a kernel module with -g option to gcc. Sign the module. Insert the module using insmod command. Then permission denied occured. Steps to Reproduce: 1. Extract the attachement to a temp folder. 2. make 3. gcc -o mod-exract mod-exract.c 4. mkdir key 5. Copy the secret key kernel.sec and public key kernel.pub to the key folder. 6. ./modsign.sh moduleTest.ko 7. insmod moduleTest.ko.signed Actual results: permission denied returned from insmod Expected results: The module can be inserted to kernel succussfully. Additional info: The bug is caused by not cleaning the memory area pointer by mvdata->nsects before reusing it(kernel/module-verify-sig.c L149). Here is the patch: --- a/kernel/module-verify-sig.c 2009-02-12 10:31:00.000000000 +0800 +++ b/kernel/module-verify-sig.c 2009-02-12 10:21:42.000000000 +0800 @@ -125,6 +125,8 @@ mvdata->xcsum = 0; #endif + memset(mvdata->canonlist, 0, sizeof(int) * mvdata->nsects); + /* load data from each relevant section into the digest */ for (i = 1; i < mvdata->nsects; i++) { unsigned long sh_type = sechdrs[i].sh_type; I have solved this bug using the patch aboved.
Created attachment 331648 [details] patch and test case
More precisely, kernel/module-verify-sig.c L149: if (mvdata->canonlist[sh_info]) the memory area pointer by mvdata->nsects is not cleaned before use. The first "canon" elements pointer by mvdata->nsects is initialized in function module_verify_canonicalise() (kernel/module-verify-sig.c L228), and modified by kernel/module-verify-sig.c L196: mvdata->canonlist[i] = 1; when sechdrs[i].sh_type contains SHF_ALLOC flag. But the left "mvdata->nsects - canon" elements is not initialized, because kernel/module-verify-sig.c L235: mvdata->canonlist = kmalloc(sizeof(int) * mvdata->nsects * 2, GFP_KERNEL); dosn't return a cleaned memory. In other word, memset() isn't used after kmalloc. So, when "sh_info" is greater than "canon", value of mvdata->canonlist[sh_info] is not determained, and then bug occured.
I apologize that this bug seems to have gone unanswered because it was miss-assigned to me on error. I am happy to help, even now. Are you still having some issues with module signing in RHEL5?
For the source code didn't change for rhel 5.4, this bug still exists.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.6 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Patch(es) available in kernel-2.6.18-294.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Verified in 2.6.18-294.el5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0150.html