Bug 118285 - [i386] Segmentation fault in reloc_non_plt.
Summary: [i386] Segmentation fault in reloc_non_plt.
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: i386 (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-i386 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-27 14:40 UTC by Vasanth Rao Naik
Modified: 2017-12-31 22:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vasanth Rao Naik 2007-11-27 14:40:00 UTC
In reloc_non_plt(), find_symdef() sometimes returns invalid value in def
and a null in defobjout. This causes any binary to recieve a segmentation
fault and cores. The kernel code where segmentation happens is in
reloc_non_plt

    189             case R_386_GLOB_DAT:
    190                 {
    191                     const Elf_Sym *def;
    192                     const Obj_Entry *defobj;
    193
    194                     def = find_symdef(ELF_R_SYM(rel->r_info), obj, &defobj,
    195                       false, cache);
    196                     if (def == NULL)
    197                         goto done;
    198
    199                     *where = (Elf_Addr) (defobj->relocbase + def->st_value);
[vasanth] this is the point where we access defobj (NULL) and causes segmentation fault.
    200                 }
    201                 break;
 


I have received a core for rcp because of this issue. This issue was also
been raised by someothers in the list.

http://lists.freebsd.org/pipermail/freebsd-current/2004-February/021698.html

The following kernel messages were thrown when problem happened

Nov 12 21:16:50  marx1 login: LOGIN_INFORMATION: User regress logged in from
host 192.168.64.68 on device ttyp0 Nov 12 21:16:50  marx1 su: regress to root on
/dev/ttyp0 Nov 12 21:16:51  marx1 /kernel: BAD_PAGE_FAULT: pid 3484 (df), uid 0:
pc 0x88100ea0 got a read fault at 0xc75aa65, x86 fault flags = 0x4 Nov 12
21:16:51  marx1 /kernel: Trapframe Register Dump:
Nov 12 21:16:51  marx1 /kernel: eax: 88143000	ecx: 0c75aa65	edx: 00000005	ebx:
8810f574
Nov 12 21:16:51  marx1 /kernel: esp: bfbfe930	ebp: bfbfe958	esi: 00000005	edi:
0c75aa55
Nov 12 21:16:51  marx1 /kernel: eip: 88100ea0	eflags: 00010206
Nov 12 21:16:51  marx1 /kernel: cs: 001f	ss: 002f	ds: 002f	es: 002f
Nov 12 21:16:51  marx1 /kernel: fs: 002f	trapno: 0000000c	err: 00000004
Nov 12 21:16:51  marx1 /kernel: Page table info for PC address 0x88100ea0: PDE =
0xbb94067, PTE = 28aad425 Nov 12 21:16:51  marx1 /kernel: Dumping 16 bytes
starting at PC address 0x88100ea0:
Nov 12 21:16:51  marx1 /kernel: 83 7f 10 00 75 08 83 c1 04 83 39 00 74 f8 ba 01

Fix: 

Please provide the Fix for this issue.
How-To-Repeat: This problem is not always reproducible.
Comment 1 Remko Lodder 2007-11-27 15:02:40 UTC
Hello Vasanth,

You mention that this happends on 4.11, does this also happen on
-supported- freebsd releases? If not, I'll need to close the ticket since
we are no longer supporting the 4.x branch nor do we intend to (there are
individuals who are looking into this, but that is outside the scope of
the official FreeBSD team).

Thanks,
remko

-- 
/"\   Best regards,                      | remko@FreeBSD.org
\ /   Remko Lodder                       | remko@EFnet
 X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News
Comment 2 Vasanth Rao Naik 2007-11-28 05:24:25 UTC
Hello Remko,

This issue which i am talking has been actually seen in freeBSD 6.1
release. There has been not much difference in find_symdef() code so i
assumed it is happening from 4.11. Could you take a look at the issue.

Thanks,
Vasanth
Comment 3 Remko Lodder freebsd_committer freebsd_triage 2010-07-14 07:45:27 UTC
Responsible Changed
From-To: freebsd-i386->jhb

Hello John, would you like to have a look at this please? 

The submitter mentionst hat the following line causes a segfault when 
defobj is NULL. 

*where = (Elf_Addr) (defobj->relocbase + def->st_value); 

Could we add something liket the following to see whether we hit a NULL 
and stop processing the bits and get back to the previous loop? 

if(defobj->relocbase == NULL) 
break;
Comment 4 John Baldwin freebsd_committer freebsd_triage 2010-10-11 19:13:32 UTC
I've cc'd kan@ and kib@ who are probably more familiar with the kernel linker 
bits than I am.

-- 
John Baldwin
Comment 5 Kostik Belousov 2010-10-11 21:03:29 UTC
I do not remember such issue, and do not remember a commit that could
be related to it.

If you can reproduce the problem at will, add assertions to rtld code,
checking that defobj is not NULL when def is not NULL. After you find
the suspect, look how it could happen, possibly inserting similar
assertions to the function that was called immediately before assert,
and so on.
Comment 6 John Baldwin freebsd_committer freebsd_triage 2011-07-07 19:59:59 UTC
Responsible Changed
From-To: jhb->freebsd-bugs

Toss this back into the public pool.
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:29 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped