bugGNU GRUB - Bugs: bug #38800, x86-64: overflowing relocation...


You are not allowed to post comments on this tracker with your current authentification level.

bug #38800: x86-64: overflowing relocation crashes GRUB

Submitted by:  <qwertial>
Submitted on:  Mon 22 Apr 2013 05:46:08 AM UTC  
Category: NoneSeverity: Major
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: ClosedRelease: 
Release: Bazaar - trunkReproducibility: Every Time
Planned Release: None

Sat 04 May 2013 09:26:49 PM UTC, comment #5:

/usr/lib/grub is ro to user while the sceript improperly assumes the module directory to be writable. It's a problem with script. As for ->mod I'm puzzled as to why it works on my system as-is.

Vladimir Serbinenko <phcoder>
Project Administrator
Sat 04 May 2013 07:11:12 PM UTC, comment #4:

Ugh, Savannah ate my comment. (Though it is readable in the mailing list.) Anyway, it's because of this change:


The module list (to which grub_dl_head points) used to be implemented by two structures. The above change moved the "->next" pointer directly into the grub_dl structure and eliminated the other one.

(Also, the auto-attach-to-QEMU commands might be removed, as they are actually counterproductive when debugging grub-emu, and maybe the /usr/lib/grub/platform path prepended to module paths in gdb_grub.in and gmodule.pl.in... but that is another story.)

Has the original issue been addressed (pardon the pun) well enough to close this? There are no more crashes, by default at least.

Tue 30 Apr 2013 02:43:21 AM UTC, comment #3:


Mon 29 Apr 2013 05:19:22 PM UTC, comment #2:

Why do you need to remove ->mod ?

Vladimir Serbinenko <phcoder>
Project Administrator
Mon 22 Apr 2013 06:06:44 PM UTC, comment #1:

Some other random things discovered by the way:

0. grub-core/gdb_grub needs a correction for 64-bit pointers and data structures change:

1. FOR_LIST_ELEMENTS_SAFE is not as safe as it says: it will dereference the final NULL pointer after assigning it to var. Which is mostly harmless without memory protection, but crashes grub-emu running the help command.

2. Speaking of which, running "help help" crashes because the help command was registered with a 0 pointer for the parser argument. The NULL check in grub_arg_show_help() happens too late. This does not seem to do much on real hardware, though it may access some bogus data.

Mon 22 Apr 2013 05:46:08 AM UTC, original submission:

The x86-64 version of grub_arch_dl_relocate_symbols() does not check whether an R_X86_64_PC32 relocation fits into 32 bits. This makes grub-emu-lite crash (with default compiler options) when trying to execute the module, since module code is loaded above 0x7ffff0000000, while grub-emu-lite code is loaded around 0x400000.

Possible solutions:

0. Add an overflow check to grub_arch_dl_relocate_symbols().
1. Try to allocate module code near core code.
2. Use the system's dlopen() and dlsym() calls for loading modules in grub-emu-lite instead of the built-in loader.
3. Compile with -mcmodel=large, which makes 32-bit relocations disappear.



No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by phcoder (Posted a comment)
  • -unavailable- added by qwertial (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 May 2013 09:26:49 PM UTCphcoderStatusNone=>Fixed

    Back to the top

    Powered by Savane 3.1-cleanup