aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorThomas Schmitt <scdbackup@gmx.net>2013-04-02 20:42:08 -0700
committerH. Peter Anvin <hpa@zytor.com>2013-04-02 20:42:08 -0700
commit44a33fd5e9dbc7d3a789ac9ec912b7a873adaab0 (patch)
treec78710b3a02097d62488b60a873f6237a1fd956e
parent556ccf02efe3eae833bcc82c4764179580ba6361 (diff)
downloadsyslinux-44a33fd5e9dbc7d3a789ac9ec912b7a873adaab0.tar.gz
syslinux-44a33fd5e9dbc7d3a789ac9ec912b7a873adaab0.tar.xz
syslinux-44a33fd5e9dbc7d3a789ac9ec912b7a873adaab0.zip
iso9660: Avoid arbitrarily large malloc()s
After explaining the slightly wasteful usage of malloc()/memcpy() with multi-block CE entries, i noticed that i did not install a safety cap on the malloc size. I could not challenge this in practice but only by gdb manipulation. My most CE-happy test image has 3 occasions of multi-block CE. All three only span over 2 blocks each.
-rw-r--r--core/fs/iso9660/susp_rr.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/core/fs/iso9660/susp_rr.c b/core/fs/iso9660/susp_rr.c
index f609f7ff..3d99b749 100644
--- a/core/fs/iso9660/susp_rr.c
+++ b/core/fs/iso9660/susp_rr.c
@@ -201,6 +201,10 @@ static int susp_rr_switch_to_ca(struct susp_rr_iter *iter)
iter->ce_allocated = 0;
if (num_blocks > 1) {
/* The blocks are expected contiguously. Need to consolidate them. */
+ if (num_blocks > 50) {
+ dprintf("susp_rr.c: More than 100 KB claimed by a CE entry.\n");
+ return -1;
+ }
iter->ce_data = malloc(num_blocks * 2048);
if (susp_rr_is_out_of_mem(iter->ce_data))
return -1;