Skip to content

[pull] master from FFmpeg:master#695

Merged
pull[bot] merged 7 commits intoMu-L:masterfrom
FFmpeg:master
Feb 19, 2021
Merged

[pull] master from FFmpeg:master#695
pull[bot] merged 7 commits intoMu-L:masterfrom
FFmpeg:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Feb 19, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

This patch also fixes a -Wtautological-constant-out-of-range-compare
warning from Clang and a -Wtype-limits warning from GCC on systems
where size_t is 64bits and unsigned 32bits. The reason for this seems
to be that variable (whose value derives from sizeof() and can therefore
be known at compile-time) is used instead of using sizeof() directly in
the comparison.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MPEG-PS muxer uses a custom queue of custom packets. To keep track
of it, it has a pointer (named predecode_packet) to the head of the
queue and a pointer to where the next packet is to be added (it points
to the next-pointer of the last element of the queue); furthermore,
there is also a pointer that points into the queue (called premux_packet).

The exact behaviour was as follows: If premux_packet was NULL when a
packet is received, it is taken to mean that the old queue is empty and
a new queue is started. premux_packet will point to the head of said
queue and the next_packet-pointer points to its next pointer. If
predecode_packet is NULL, it will also made to point to the newly
allocated element.

But if premux_packet is NULL and predecode_packet is not, then there
will be two queues with head elements premux_packet and
predecode_packet. Yet only elements reachable from predecode_packet are
ever freed, so the premux_packet queue leaks.
Worse yet, when the predecode_packet queue will be eventually exhausted,
predecode_packet will be made to point into the other queue and when
predecode_packet will be freed, the next pointer of the preceding
element of the queue will still point to the element just freed. This
element might very well be still reachable from premux_packet which
leads to use-after-frees lateron. This happened in the tickets mentioned
below.

Fix this by never creating two queues in the first place by checking for
predecode_packet to know whether the queue is empty. If premux_packet is
NULL, then it is set to the newly allocated element of the queue.

Fixes tickets #6887, #8188 and #8266.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by moving the check before the allocation.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Inside a function a superfluous ';' is just a null-statement; yet
outside it is invalid, even though compilers happen to accept them.
They (at least GCC and Clang) only warn about this when on -pedantic.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
@pull pull bot added the ⤵️ pull label Feb 19, 2021
@pull pull bot merged commit 14dc28e into Mu-L:master Feb 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant