Bug 140954
| Summary: | bad elf check in module-verify.c | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yannick Heneault <yheneaul> |
| Component: | kernel | Assignee: | David Howells <dhowells> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | adam, bugzilla.redhat.com, dhowells, dravet, okapi, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-08-30 19:06:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 167126 | ||
Out of interest, what does that relocate against? The zeroth element is meant to be a "NULL" symbol isn't it? I'm not saying you're wrong, but how do you deal with it? What does it mean? I wonder if the kernel's relocator will get it right... David OIC... When calculating a relocation, symbol #0 is explicitly defined to be zero by the standard. Any good elf loader, like the one in the kernel, will simply ignore them. These are useless relocation unit that are kept by the linker. In our case, it happens when we inline a function in multiple .o files. The linker will keep only one copy of the code by selecting one the of the object files and will use its sections if the inline functions need relocation (like a reference to the .rodata segment by a switch statement). In the other .o files that declared the inlined function, the relocation units are conserved but are not used anymore since they are not referenced, (i.e. the function was removed). Has this been fixed in any of the errata kernels? (In reply to comment #5) > Has this been fixed in any of the errata kernels? Looks like it is fixed in kernel-2.6.9-1.724_FC3.src.rpm diff kernel-2.6.9-1.681_FC3.src/linux-2.6.7-modsign-core.patch kernel-2.6.9-1.724_FC3.src/linux-2.6.7-modsign-core.patch 114c114 < @@ -0,0 +1,341 @@ --- > @@ -0,0 +1,340 @@ 400d399 < + relcheck(ELF_R_SYM(rel->r_info) > 0); There seems to be a new bug here, possibly/probably triggered by the new
glibc-2.3.5-10.3.
I've been getting "Verify ELF error (assertion 110)" on all modules compiled
recently, on i386 and x86_64. This results in rpmbuild --rebuild
kernel...src.rpm producing an unusable kernel.
Lines 109--110 of module-verify.c is:
tmp = (size_t) hdr->e_shentsize * (size_t) hdr->e_shnum;
elfcheck(tmp < size - hdr->e_shoff);
Shouldn't that be
elfcheck(tmp <= size - hdr->e_shoff);
~~~~
instead?
With readelf -h on a module compiled a few days ago, I get this:
Start of section headers: 455448 (bytes into file)
Size of section headers: 40 (bytes)
Number of section headers: 25
(file size 665312)
Section headers (40*25=1000 bytes) < file size (665312) - section header offset
(455448 bytes), and it verifies.
Here is the same module newly compiled:
Start of section headers: 667532 (bytes into file)
Size of section headers: 40 (bytes)
Number of section headers: 25
(file size 668532)
Section headers (40*25=1000 bytes) = file size (668532) - section header offset
(667532 bytes), which should be valid, but isn't, since less than is used in the
kernel. This should be less than or equal to.
|
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko) Description of problem: The patch linux-2.6.7-modsign-core.patch that is part of the kernel srpms contain a false check. At line 286 in kernel/module-verify.c: relcheck(ELF_R_SYM(rel->r_info) > 0); introduce a false check. According to the elf specification, it is possible the set the symbol index of the relocation table to 0. We are in a situation were our gcc toolchains generates this case. This prevent us to modprobe our module on a system with fc3 installed. If someone can remove this line for the next update it will be appreciated. In fact, the loader of the kernel is already able to deal with this case (=0), so there is no need for this check. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Additional info: