blob: 6834cabda0d6f5cef8d71a4eb17e0ee70bac714a (
about) (
plain)
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
|
Fix CVE-2018-1000880:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909
https://github.com/libarchive/libarchive/pull/1105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000880
https://security-tracker.debian.org/tracker/CVE-2018-1000880
Patch copied from upstream source repository:
https://github.com/libarchive/libarchive/commit/9c84b7426660c09c18cc349f6d70b5f8168b5680
From 9c84b7426660c09c18cc349f6d70b5f8168b5680 Mon Sep 17 00:00:00 2001
From: Daniel Axtens <dja@axtens.net>
Date: Tue, 4 Dec 2018 16:33:42 +1100
Subject: [PATCH] warc: consume data once read
The warc decoder only used read ahead, it wouldn't actually consume
data that had previously been printed. This means that if you specify
an invalid content length, it will just reprint the same data over
and over and over again until it hits the desired length.
This means that a WARC resource with e.g.
Content-Length: 666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666665
but only a few hundred bytes of data, causes a quasi-infinite loop.
Consume data in subsequent calls to _warc_read.
Found with an AFL + afl-rb + qsym setup.
---
libarchive/archive_read_support_format_warc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/libarchive/archive_read_support_format_warc.c b/libarchive/archive_read_support_format_warc.c
index e8753853..e8fc8428 100644
--- a/libarchive/archive_read_support_format_warc.c
+++ b/libarchive/archive_read_support_format_warc.c
@@ -386,6 +386,11 @@ _warc_read(struct archive_read *a, const void **buf, size_t *bsz, int64_t *off)
return (ARCHIVE_EOF);
}
+ if (w->unconsumed) {
+ __archive_read_consume(a, w->unconsumed);
+ w->unconsumed = 0U;
+ }
+
rab = __archive_read_ahead(a, 1U, &nrd);
if (nrd < 0) {
*bsz = 0U;
--
2.20.1
|
