Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libmad: apply patches from debian for CVE-2017-8372 and CVE-2017-8373 #7

Merged
merged 2 commits into from
Oct 5, 2018
Merged

Conversation

sezero
Copy link
Collaborator

@sezero sezero commented Oct 5, 2018

No description provided.

…-8373

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.
…E-2017-8373

From: Kurt Roeckx <kurt@roeckx.be>
Date: Sun, 28 Jan 2018 19:26:36 +0100
Subject: Check the size before reading with mad_bit_read

There are various cases where it attemps to read past the end of the buffer
using mad_bit_read(). Most functions didn't even know the size of the buffer
they were reading from.
@sezero sezero mentioned this pull request Oct 5, 2018
@Wohlstand
Copy link
Member

Oh, nice! 🦊 👍

@Wohlstand Wohlstand merged commit da76e8d into WohlSoft:master Oct 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants