Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sd_loader: unchecked memset on .bss #32

Open
ashquarky opened this issue Jun 14, 2017 · 0 comments
Open

sd_loader: unchecked memset on .bss #32

ashquarky opened this issue Jun 14, 2017 · 0 comments

Comments

@ashquarky
Copy link

Heyo!

I've been tasked with diagnosing some ELF-specific crashes around some libretro cores I've been working on. After some confusion (turns out OSGetSymbolName is hopeless) I traced it back to this memset that clears out the .bss section for an ELF being loaded. As you can see, the size of the clear is taken from shdr[i].sh_size - a value loaded straight from the ELF! This is usually fine, but today I ended up with an ELF like this -

$ powerpc-eabi-readelf -S retroarch_wiiu.elf
There are 478 section headers, starting at offset 0x52b684:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .init             PROGBITS        00802000 002000 000024 00  AX  0   0  4
  [ 2] .text             PROGBITS        00802024 002024 305efc 00  AX  0   0  4
  [ 3] .fini             PROGBITS        00b07f20 307f20 000020 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        00b07f40 307f40 121334 00   A  0   0  8
  [ 5] .gcc_except_table PROGBITS        00c29274 429274 00000e 00   A  0   0  1

  ...many more gcc_except_tables...

  [456] .gcc_except_table PROGBITS        00c34971 434971 00000c 00   A  0   0  1
  [457] .data             PROGBITS        00c34a00 434a00 02a6c0 00  WA  0   0 256
  [458] .eh_frame         PROGBITS        00c5f0c0 45f0c0 028c74 00  WA  0   0  4
  [459] .ctors            PROGBITS        00c87d34 487d34 00008c 00  WA  0   0  4
  [460] .dtors            PROGBITS        00c87dc0 487dc0 000060 00  WA  0   0  4
  [461] .jcr              PROGBITS        00c87e20 487e20 000004 00  WA  0   0  4
  [462] .sdata            PROGBITS        00c87e28 487e28 000518 00  WA  0   0  8
  [463] .sbss             NOBITS          00c88340 488340 000740 00  WA  0   0  8
  [464] .bss              NOBITS          00c88a80 488a80 ad15a0 00  WA  0   0  8
  [465] .comment          PROGBITS        00000000 488340 00003e 01  MS  0   0  1
  [466] .gnu.attributes   LOOS+0xffffff5  00000000 48837e 000012 00      0   0  1
  [467] .debug_aranges    PROGBITS        00000000 488390 0003b0 00      0   0  1
  [468] .debug_info       PROGBITS        00000000 488740 01050c 00      0   0  1
  [469] .debug_abbrev     PROGBITS        00000000 498c4c 0020d3 00      0   0  1
  [470] .debug_line       PROGBITS        00000000 49ad1f 003081 00      0   0  1
  [471] .debug_frame      PROGBITS        00000000 49dda0 0010a0 00      0   0  4
  [472] .debug_str        PROGBITS        00000000 49ee40 0021f6 01  MS  0   0  1
  [473] .debug_loc        PROGBITS        00000000 4a1036 006dd6 00      0   0  1
  [474] .debug_ranges     PROGBITS        00000000 4a7e0c 000950 00      0   0  1
  [475] .shstrtab         STRTAB          00000000 52335c 008325 00      0   0  1
  [476] .symtab           SYMTAB          00000000 4a875c 02d4c0 10     477 4879  4
  [477] .strtab           STRTAB          00000000 4d5c1c 04d740 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

In case you missed it, here's the .bss:

  [Nr ] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [464] .bss              NOBITS          00c88a80 488a80 ad15a0 00  WA  0   0  8

As you can see, it's AD15A0 big and wants to be at address 00C88A80. One problem: 00C88A80 + AD15A0 = 0175A020 - well past the end of the HBL memory area. This causes it to get picked up by COS as a bad memory access and the console locks up with a black screen.

Since it doesn't fail gracefully, diagnosing when this happens can be quite tough - I initially thought this was something to do with function imports! I'll leave it with you to decide the best way to go about this, but I'd really appreciate it if you could have it fail nicely (like the existing "not enough memory" error for large ELF files).

Thanks tons!
-Ash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant