[Bug binutils/29647] New: [Infinite Loop]: objdump(version 2.39.50.20221003, commit e1fc9bcf)

[chkunq at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29647

            Bug ID: 29647
           Summary: [Infinite Loop]: objdump(version 2.39.50.20221003,
                    commit e1fc9bcf)
           Product: binutils
           Version: 2.40 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: chkunq at gmail dot com
  Target Milestone: ---

Created attachment 14374
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14374&action=edit
An input file that triggers an infinite loop in objdump.

# Crash Inputs
The file that triggers the bug is attached in attachment.

# Bug Description

When the given file is used as input, `objdump` cannot finish execution within
600s. 

Via debugging, I eventually confirm that the given input file triggered an
infinite loop in `objdump`.

```
(gdb) bt
#0  print_line (p=0x724f40, linenum=175019134) at ./objdump.c:2074
#1  0x00000000004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
#2  0x000000000041114a in show_line (abfd=0x707690, section=0x70a998,
addr_offset=258) at ./objdump.c:2292
#3  0x000000000040f1d2 in disassemble_bytes (inf=0x7fffffffdd58,
disassemble_fn=0x467200 <print_insn_i386>, insns=true, data=0x721250
"\363\017\036\372\061\355I\211\321^H\211\342H\203\344\360PTI\307\300\300\030@",
start_offset=240, stop_offset=336, rel_offset=0, 
    relppp=0x7fffffffdc38, relppend=0x0) at ./objdump.c:3314
#4  0x000000000040c9b3 in disassemble_section (abfd=0x707690, section=0x70a998,
inf=0x7fffffffdd58) at ./objdump.c:4007
#5  0x00000000004b2b37 in bfd_map_over_sections (abfd=0x707690,
operation=0x40bbb0 <disassemble_section>, user_storage=0x7fffffffdd58) at
section.c:1373
#6  0x0000000000408d21 in disassemble_data (abfd=0x707690) at ./objdump.c:4151
#7  0x000000000040715e in dump_bfd (abfd=0x707690, is_mainfile=true) at
./objdump.c:5563
#8  0x0000000000406a29 in display_object_bfd (abfd=0x707690) at
./objdump.c:5626
#9  0x00000000004069e3 in display_any_bfd (file=0x707690, level=0) at
./objdump.c:5712
#10 0x000000000040624e in display_file (filename=0x7fffffffe3d4
"./objdump/hangs-600/hangs/000", target=0x0, last_file=true) at
./objdump.c:5733
#11 0x0000000000404e43 in main (argc=3, argv=0x7fffffffe118) at
./objdump.c:6129
(gdb) f 1
#1  0x00000000004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
2093          print_line (p, start);
(gdb) list
2088    {
2089      if (p->map == NULL)
2090        return;
2091      while (start <= end)
2092        {
2093          print_line (p, start);
2094          start++;
2095        }
2096    }
2097
(gdb) p end == -1
$1 = 1
```

As the type of `end` is u32, the looping could not terminate if `end`== -1 ==
0xffffffff (INTEGER OVERFLOW).
After backtracing the call stack, I found that the value of `end` comes from
`u32 linenumber` in function `show_line(...) :objdump.c:2106`, and the value of
`linenumber` is defined in function `bfd_find_nearest_line_discriminator(...,
&linenumber,...) :objdump.c:2155`. Although the value comes from from library
`bfd`, I think it is still necessary to check the value of the linenumber after
getting it.

`assert( linenumber != 0xffffffff && "linenumber cannot be -1.")`

# How to Reproduce
The aforementioned bug can be stably reproduced in version 2.39.50 (commit id
db0f0fcb.
1. Download the binutils-gdb source code with the [official
link](https://gitlab.com/libtiff/libtiff).
2. Build binutils-gdb with clang/clang++ (10.0.0-4ubuntu1),.
3. Execute objdump with the provided input files.
    - eg: `/data/program/binutils-gdb/orig/bin/objdump -S <input-file> `

-- 
You are receiving this mail because:
You are on the CC list for the bug.