mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-08-01 21:23:51 -09:00
9c9c531d0b
The commit [1] introduced fixes for the following CVEs: - CVE-2017-8372: The mad_layer_III function in layer3.c in Underbit MAD libmad 0.15.1b, if NDEBUG is omitted, allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted audio file. - CVE-2017-8373: The mad_layer_III function in layer3.c in Underbit MAD libmad 0.15.1b allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted audio file. - CVE-2017-8374: The mad_bit_skip function in bit.c in Underbit MAD libmad 0.15.1b allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted audio file. In commit [2], the patches ended up not being applied anymore because the APPLY_PATCHES step was called before the patch content exists. This commit import the fixes in Buildroot. [1]858df3643fpackage/libmad: switch to debian to fix CVEs [2]b21184a877package/libmad: update the patches to be applied with fuzz 0 Signed-off-by: Thomas Perale <thomas.perale@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
64 lines
2.4 KiB
Diff
64 lines
2.4 KiB
Diff
From: Kurt Roeckx <kurt@roeckx.be>
|
|
Date: Sun, 28 Jan 2018 15:44:08 +0100
|
|
Subject: Check the size of the main data
|
|
|
|
The main data to decode a frame can come from the current frame and part of the
|
|
previous frame, the so called bit reservoir. si.main_data_begin is the part of
|
|
the previous frame we need for this frame. frame_space is the amount of main
|
|
data that can be in this frame, and next_md_begin is the part of this frame that
|
|
is going to be used for the next frame.
|
|
|
|
The maximum amount of data from a previous frame that the format allows is 511
|
|
bytes. The maximum frame size for the defined bitrates is at MPEG 2.5 layer 2
|
|
at 320 kbit/s and 8 kHz sample rate which gives 72 * (320000 / 8000) + 1 = 2881.
|
|
So those defines are not large enough:
|
|
# define MAD_BUFFER_GUARD 8
|
|
# define MAD_BUFFER_MDLEN (511 + 2048 + MAD_BUFFER_GUARD)
|
|
|
|
There is also support for a "free" bitrate which allows you to create any frame
|
|
size, which can be larger than the buffer.
|
|
|
|
Changing the defines is not an option since it's part of the ABI, so we check
|
|
that the main data fits in the bufer.
|
|
|
|
The previous frame data is stored in *stream->main_data and contains
|
|
stream->md_len bytes. If stream->md_len is larger than the data we
|
|
need from the previous frame (si.main_data_begin) it still wouldn't fit
|
|
in the buffer, so just keep the data that we need.
|
|
|
|
CVE: CVE-2017-8372
|
|
CVE: CVE-2017-8373
|
|
Upstream: http://snapshot.debian.org/archive/debian/20190310T213528Z/pool/main/libm/libmad/libmad_0.15.1b-10.diff.gz
|
|
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
|
|
|
|
Index: libmad-0.15.1b/layer3.c
|
|
===================================================================
|
|
--- libmad-0.15.1b.orig/layer3.c
|
|
+++ libmad-0.15.1b/layer3.c
|
|
@@ -2608,6 +2608,11 @@ int mad_layer_III(struct mad_stream *str
|
|
next_md_begin = 0;
|
|
|
|
md_len = si.main_data_begin + frame_space - next_md_begin;
|
|
+ if (md_len + MAD_BUFFER_GUARD > MAD_BUFFER_MDLEN) {
|
|
+ stream->error = MAD_ERROR_LOSTSYNC;
|
|
+ stream->sync = 0;
|
|
+ return -1;
|
|
+ }
|
|
|
|
frame_used = 0;
|
|
|
|
@@ -2625,8 +2630,11 @@ int mad_layer_III(struct mad_stream *str
|
|
}
|
|
}
|
|
else {
|
|
- mad_bit_init(&ptr,
|
|
- *stream->main_data + stream->md_len - si.main_data_begin);
|
|
+ memmove(stream->main_data,
|
|
+ *stream->main_data + stream->md_len - si.main_data_begin,
|
|
+ si.main_data_begin);
|
|
+ stream->md_len = si.main_data_begin;
|
|
+ mad_bit_init(&ptr, *stream->main_data);
|
|
|
|
if (md_len > si.main_data_begin) {
|
|
assert(stream->md_len + md_len -
|