1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
From a54018b72d75abf2e74bf36016702da06399c1d9 Mon Sep 17 00:00:00 2001
From: Alan Modra <amodra@gmail.com>
Date: Tue, 26 Sep 2017 09:38:26 +0930
Subject: [PATCH] PR22205, .debug_line file table NULL filename
The PR22200 fuzzer testcase found one way to put NULLs into .debug_line
file tables. PR22205 finds another. This patch gives up on trying to
prevent NULL files in the file table and instead just copes with them.
Arguably, this is better than giving up and showing no info from
.debug_line. I've also fixed a case where the fairly recent DWARF5
support in handling broken DWARG could result in uninitialized memory
reads, and made a small tidy.
PR 22205
* dwarf2.c (concat_filename): Return "<unknown>" on NULL filename.
(read_formatted_entries): Init "fe".
(decode_line_info <DW_LNE_define_file>): Use line_info_add_file_name.
Upstream-Status: Backport
Affects: <= 2.29.1
CVE: CVE-2017-15939
Signed-off-by: Armin Kuster <akuster@mvista.com>
---
bfd/ChangeLog | 7 +++++++
bfd/dwarf2.c | 35 +++++++++++++----------------------
2 files changed, 20 insertions(+), 22 deletions(-)
Index: git/bfd/dwarf2.c
===================================================================
--- git.orig/bfd/dwarf2.c
+++ git/bfd/dwarf2.c
@@ -1597,6 +1597,8 @@ concat_filename (struct line_info_table
}
filename = table->files[file - 1].name;
+ if (filename == NULL)
+ return strdup ("<unknown>");
if (!IS_ABSOLUTE_PATH (filename))
{
@@ -1956,6 +1958,7 @@ read_formatted_entries (struct comp_unit
bfd_byte *format = format_header_data;
struct fileinfo fe;
+ memset (&fe, 0, sizeof fe);
for (formati = 0; formati < format_count; formati++)
{
bfd_vma content_type, form;
@@ -2256,6 +2259,7 @@ decode_line_info (struct comp_unit *unit
unsigned int discriminator = 0;
int is_stmt = lh.default_is_stmt;
int end_sequence = 0;
+ unsigned int dir, xtime, size;
/* eraxxon@alumni.rice.edu: Against the DWARF2 specs, some
compilers generate address sequences that are wildly out of
order using DW_LNE_set_address (e.g. Intel C++ 6.0 compiler
@@ -2330,31 +2334,18 @@ decode_line_info (struct comp_unit *unit
case DW_LNE_define_file:
cur_file = read_string (abfd, line_ptr, line_end, &bytes_read);
line_ptr += bytes_read;
- if ((table->num_files % FILE_ALLOC_CHUNK) == 0)
- {
- struct fileinfo *tmp;
-
- amt = table->num_files + FILE_ALLOC_CHUNK;
- amt *= sizeof (struct fileinfo);
- tmp = (struct fileinfo *) bfd_realloc (table->files, amt);
- if (tmp == NULL)
- goto line_fail;
- table->files = tmp;
- }
- table->files[table->num_files].name = cur_file;
- table->files[table->num_files].dir =
- _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
- FALSE, line_end);
+ dir = _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
+ FALSE, line_end);
line_ptr += bytes_read;
- table->files[table->num_files].time =
- _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
- FALSE, line_end);
+ xtime = _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
+ FALSE, line_end);
line_ptr += bytes_read;
- table->files[table->num_files].size =
- _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
- FALSE, line_end);
+ size = _bfd_safe_read_leb128 (abfd, line_ptr, &bytes_read,
+ FALSE, line_end);
line_ptr += bytes_read;
- table->num_files++;
+ if (!line_info_add_file_name (table, cur_file, dir,
+ xtime, size))
+ goto line_fail;
break;
case DW_LNE_set_discriminator:
discriminator =
Index: git/bfd/ChangeLog
===================================================================
--- git.orig/bfd/ChangeLog
+++ git/bfd/ChangeLog
@@ -1,3 +1,10 @@
+2017-09-26 Alan Modra <amodra@gmail.com>
+
+ PR 22205
+ * dwarf2.c (concat_filename): Return "<unknown>" on NULL filename.
+ (read_formatted_entries): Init "fe".
+ (decode_line_info <DW_LNE_define_file>): Use line_info_add_file_name.
+
2017-10-09 Alan Modra <amodra@gmail.com>
PR 22212
|
