Fixes: p6PbEwU20LjP
Fixes: AISLE-2026-0150-00017
Fixes: use after free
Use after free Replicated through UnModified FFmpeg
Found-by: Joshua Rogers (AISLE)
The report suggested moving the old decoder and surfaces into a cleanup
object referenced by the outstanding frames, as the close path does.
mjpegdec releases a picture left over from a failed packet before
ff_get_format() tears down the VA context and the device the callback needs.
Fixes: vMMlgSzb6MuU
Fixes: AISLE-2026-0150-00741
Fixes: memleak
Memleak Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
The report suggested a free_frame_priv callback that destroys the still
tracked parameter and slice buffers.
The frame can hold the last reference to the frames context and with it to
the device context the hwaccel's free_frame_priv callback receives. vvc,
mpegvideo and the mjpeg close path released the frame first, and the av1,
vp8, vp9 and h264 picture replacement replaced it first; the other
decoders already release the private data first.
Found during triage/review of the security report AISLE-2026-R0043
Fixes: pzezUDNFoag5
Fixes: AISLE-2026-0150-00646
Fixes: memleak
Memleak Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
The report suggested a free_frame_priv callback that frees
bitstream_buffers.
Fixes: KICdwlv5dwyY
Fixes: AISLE-2026-0150-00792
Fixes: use after free
Use after free Replicated through Modified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
The report suggested clearing raw_image_buffer per packet and rejecting a
SOF that is not preceded by a SOI.
This was missed when the hwaccel_picture_private was made a buffer.
Fixes: YMGIFa63VNkS
Fixes: AISLE-2026-0150-00681
Fixes: memleak
Memleak Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
Cherry-picked from https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24652 where
the commit is part of the Vulkan MJPEG hwaccel. The Fixes, replication and
Found-by lines were added when applying it for the security report; the
start_frame() call keeps passing NULL as the preceding commits of that pull
request are not included.
Fixes: I8tidri5usIx
Fixes: AISLE-2026-0150-00880
Fixes: use after free
Use after free Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
GCC 14.4.0 and 16.2.1 report -Wstringop-overflow in angular prediction.
Unchecked block sizes and derived filter lengths could exceed the local
reference buffer. Require a power-of-two size from 4 to 64 and bound the
weak and bilinear filter lengths before writing. Prediction is unchanged
for sizes and lengths within those bounds.
Signed-off-by: lusoris <lusoris@proton.me>
The VP5/VP6 headers install new dimensions before vp56_size_changed() allocates the arrays for them. If resizing fails, leave the dimensions cleared so following frames cannot use the missing arrays, and preserve the allocation error for the caller.
Fixes: 24187
Assisted-by: Fairy
Convert the last MMX (mmx/mmxext) IDCT functions, idct8_dc_add_8,
idct_add8_422_8 (plus its plane and DC helpers) and
idct_dc_add_10, to SSE2. The DC_ADD macros are renamed to
DC_ADD_SSE2 (pshuflw, movq traffic) and shared with the
pre-existing sse2/avx IDCT_XMM path. The mmxext DC helper
tail-called from SSE2 functions is now XMM, which also removes
the MMX-state handoff without emms. Dispatch moves from
EXTERNAL_MMX/MMXEXT to EXTERNAL_SSE2.
checkasm h264dsp passes. identical performances.
A DTS:X stream in the standard presentation is DTS-HD Master Audio with a 7.1
bed and an extension at the end of every XLL frame, behind the syncword the
decoder already recognises (DCA_SYNCWORD_XLL_X). The extension is a 22-byte
header followed by a regular XLL channel set: four channels, every one coded
in full (no residual against the core), no speaker mask, its own NAVI table
with the frame's segment geometry, then a two-byte trailer. Its channels are
the front and rear height pairs, and the encoder folds each of them into the
bed speaker below it (L, R, Lsr, Rsr) at -3 dB, gain code 23170/32768, so the
7.1 bed plays them on players that ignore the extension.
The decoder now parses that channel set with the existing channel set code,
outputs 7.1.4 (TFL, TFR, TBL, TBR), and removes the fold from the bed at
output resolution. A "downmix" request for 7.1 keeps the bed as coded, heights
folded in, which is what the decoder output before; the requests for 5.1 and
stereo skip the extension as well, so their output is unchanged. Streams
without the extension are not affected. A frame whose extension does not
decode keeps the 7.1.4 layout with silent heights and the bed as coded, and
the frame still ends where it did before. The alternate presentations, which
carry objects behind DCA_SYNCWORD_XLL_X_IMAX, are not touched.
The format facts (header size, channel order, the fold) come from the public
analysis in harletty-bridge's dca crate and kristofferR's SpatialAudioBridge;
this is an implementation on FFmpeg's own XLL code, not a translation.
Signed-off-by: Vincent Herbst <superuser404@tuta.com>
ac3_decode_flush() clears every field from frame_type to the end of
AC3DecodeContext with a single memset. Several fields backing AVOptions
(drc_scale, heavy_compression, target_level and
consistent_noise_generation, plus the exported downmix fields) were
located in that range, so avcodec_flush_buffers() silently zeroed them.
For drc_scale that does not even restore the default of 1.0,
effectively disabling dynamic range compression after any flush, e.g.
on seek.
Move all AVOption fields above the start of the flushable fields, next
to downmix_layout which was already kept there, so that flush only
resets actual decoding state. The exported downmix fields are written
from the frame header for every frame, so preserving them across flush
does not change decoding.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/25430
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Copy the dts of the decoded packet to the frame. decode.c does this only
for decoders with the decode callback, so it got lost when 084b67f6e3
moved the decoder to the receive_frame API, and frames decoded from
packets that carry only a dts have had no timestamp since.
Fixes: 084b67f6e3
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Copy the dts of the decoded packet to the frame. decode.c does this only
for decoders with the decode callback, so it got lost when 6287ad1f9b
moved the decoder to the receive_frame API, and frames decoded from
packets that carry only a dts have had no timestamp since.
Fixes: 6287ad1f9b
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: xf78sw1plZNy
Fixes: AISLE-2026-0150-00556
Fixes: out of array write
Out of array write Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
The check is the one given in the report's recommendation; analysis,
testcase and verification by Michael Niedermayer.
Fixes: j1Bk4Efn73Vz
Fixes: AISLE-2026-0150-00765
Fixes: out of array read
Out of array read Replicated through UnModified FFmpeg with ASAN
Found-by: Joshua Rogers (AISLE)
The report suggested ordered subtraction checks.
Fixes: bmXNoLIHNO2l
Fixes: AISLE-2026-0150-00467
Fixes: memleak
Memleak Replicated through UnModified FFmpeg with ASAN
Regression since: c0bf1382a7
Found-by: Joshua Rogers (AISLE)
The report suggested routing these returns through the fail label.
Fixes: 28PPo4pFl31u
Fixes: AISLE-2026-0150-00699
Fixes: assertion failure
Assertion failure Replicated through UnModified FFmpeg with an ASAN build
Found-by: Joshua Rogers (AISLE)
The report suggested counting 0xff bytes only after the scan header.
hevc_nvenc stops the encode with "Failed locking bitstream buffer: out
of memory" once the SEI of a picture are large: nvEncLockBitstream()
returns NV_ENC_ERR_OUT_OF_MEMORY. With driver 615.78.08 at 1920x1080 a
single user data unregistered payload of up to 898 bytes passes on an
IDR picture and up to 999 on a P picture, 672 and 747 when the payload
is all zero bytes after the UUID. h264_nvenc carried 8192 bytes.
Count the payload bytes of the A/53, timecode and user data unregistered
SEI of an hevc_nvenc picture in order and drop a SEI that would take the
total above 512 bytes, with a warning for the first one and verbose
messages after that.
Measured on an RTX 4090 with that driver, 1920x1080, five frames, one
user data unregistered SEI on the IDR or on a P picture: payloads up to
512 bytes give output byte-identical to the unpatched encoder, payloads
of 513, 898, 999 and 1000 bytes are dropped with the warning and all
five frames encode, and h264_nvenc output is unchanged.
Signed-off-by: lusoris <lusoris@proton.me>
This is not a security issue.
Fixes: Qzx1V8a6y8DL
Fixes: swarm-Out-of-bounds-reads-on-coefs-shift-bits-when-min_prediction_order-is-0-0468ca
Found-by: zhang xingxing <2388969553@qq.com>
The report suggested ensuring min_order >= 1.
Out of array write Replicated through UnModified FFmpeg with ASAN
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The parsing logic for this already existed in libavcodec, but was unused
until now. This commit adds the APP2 extraction logic and the necessary
scaffolding to make this metadata survive the decoder.
Since the base layer of a JPEG Ultra HDR image also contains a stub
copy of the same gain map params struct, we ignore that one here. (It's
only useful for the demuxer, not the decoder)
Signed-off-by: Niklas Haas <git@haasn.dev>
AV_PKT_DATA_SKIP_SAMPLES gives the samples to skip at the start of a
frame and the padding to discard at its end. When both apply to the same
frame and overlap, the padding was compared with what was left after the
skip, found too large, and ignored, so the padding was output.
Check the padding against the whole frame, then discard what is left of
it after the skip.
The overlapping case of the api-skip-samples test now outputs nothing
instead of the padding.
AAC decoding overlaps each frame with the previous one, so the first
frame decoded after a seek is only reliable once the frame before it has
been decoded. Opus declares its pre-roll in AVCodecParameters.seek_preroll,
AAC did not.
Have the decoder export its pre-roll, as it knows the frame length: 1024
or 960 samples, half of it for LD and ELD, and 1024 or 768 for USAC.
ELD needs three frames, as its low delay filterbank uses a window four
frames long. SBR keeps the state of the frame before, in its
filterbanks, its high-frequency generator and its gain smoothing, and
codes its envelopes and noise floors relative to the frame before, so
it needs one more frame, of twice as many output samples when it
doubles the sample rate. Without it, the first 256 samples decoded
after a seek into HE-AAC differ from continuous decoding by -36.6 dB
with one frame of pre-roll, and not at all with two.
Implicit SBR is only known once found in a frame, so the pre-roll is
raised then, as it is for USAC, whose frame length depends on its SBR
ratio. Demuxers get it through the stream probing, whatever the
container. A larger pre-roll declared by the container is kept, and the
documentation of AVCodecContext.seek_preroll now says a decoder may
raise it.
The output of an AAC-LC stream decoded after a seek has an error of
-9.5 dB in the first 1024 samples, against -85 dB elsewhere, which one
frame of pre-roll removes.
The pre-roll tests now show the declared value, for AAC in every
container, 4096 samples for HE-AAC, explicit or implicit, 2048 for SBR
that does not double the sample rate, and 1536 for ELD.
avcodec_parameters_to_context() copied AVCodecParameters.initial_padding
into both AVCodecContext.initial_padding and AVCodecContext.delay. Since
ff98352c3d, avcodec_open2() sets skip_samples from AVCodecContext.delay
for every decoder, so a decoder opened on a stream with container
priming, such as AAC in MP4, started out with that many samples pending
to be discarded.
The two are different things. initial_padding is the encoder priming at
the start of the stream, which the demuxer already attaches to the first
packet as skip-samples side data. delay is a property of the decoder
instance, which only decoders that know their own delay export in init.
Applying the container's value at open discards it from whatever the
first decoded packet turns out to be, so seeking before the first
decode drops real samples. For a mono 44.1 kHz AAC-LC file with 2048
priming, ffmpeg -ss 530 -t 10 -i in.m4a returned 439152 instead of
441000 samples, with the audio starting 1848 samples late.
Stop copying initial_padding into delay. Decoders that export a delay,
such as libopus, native opus, wma, lc3, ape and mpegh, set it
themselves and are unaffected, and decoding from the start of a stream
is unchanged since the side data carries the priming. The documentation
of AVCodecContext.delay now says it is discarded when the decoder is
opened, and points to seek_preroll for seeking.
The seek tests of AAC in MP4 and CAF now start at the requested time
instead of late by the container's priming.
Add a filter that removes side data of the given types from packets and from
the stream, or keeps only the packets carrying side data of any of the given
types, as the select mode of the sidedata frame filter does for frames, but
with a list of types. The types are named by their handle, as option
constants joined with '+'.
Walk all the side data types: each one has to have a handle, which has to
find the type again and not be shared. The handles are compared with the
reference, so that a new type fails the test until it gets one and a
released handle cannot change unnoticed.
Add a list that gives each side data type a short handle made of lower case
letters, digits and underscores, so that a filter can let its user name a
type in an option.
The side_data_prefer_packet option of decoders now takes its constants from
this list, which gives the list the names that option has already released.
The option thus accepts every type, with the flags of the option itself
rather than audio only. A decoder warns about a type that has no frame side
data counterpart, as it ignores it.
Each handle is written out rather than derived from the name that
av_packet_side_data_name() returns, as that one is meant for people and may
be reworded.
The eight positions of the eight-row window are the same walk for every
vertical tail, and calc_all already carries it. The wider weighted tails stay
as they are: calc_all2 fixes its window to v16..v31, so handing them over means
moving their accumulators and weight vectors out of that range first.
No functional changes.
The unweighted step macros in this file let a post-indexed load walk the
intermediate plane, while these weighted steps loaded a row and then advanced
sp with a separate add. Fold the advance into the load.
The step macro now names its row register without a width letter, which is
what the next change needs in order to drive these tails from calc_all.
A queued display entry holds a decode surface index, not a copy of its
pixels. Parsing another packet can reuse that surface before the entry
is mapped, associating a later image with the queued timestamp. The
queue occupancy check does not protect individual surface lifetimes.
Consume queued output before fetching another packet. In particular,
this drains both deinterlaced fields before submitting further input.
A generated 120-frame interlaced H.264 stream decoded with -deint bob
produces 157 incorrect images out of 240 on an RTX 5090. With this guard,
all 240 images match the software-decoded, spatially constant source
frames, and diagnostic logging no longer observes queued surface reuse.
Based on the candidate fix provided by hayateppp in issue #25210.
The original report's private inputs remain untested here.
Assisted-by: Fairy
When the bottom-left (or top-right) reference samples cross the picture
edge, the part outside the picture was filled from the last in-picture
sample before the constrained_intra_pred substitution, which only runs up
to the picture edge. If that sample belongs to an inter CU, its raw value
stayed in the out-of-picture part instead of the substituted one
(8.4.4.2.2), and the prediction no longer matched the encoder or HM.
Seen with x265 at 1080p, 64x64 CTBs and constrained intra prediction:
TUs in the partial bottom CTB row next to inter CUs mismatch from there
on.
Nellymoser expects the caller to set the samplerate, as it
doesn't read it from the bitstream. However the generic check
for this is bypassed as it has the AV_CODEC_CAP_CHANNEL_CONF
capability because it does set the channel configuration,
however that cap also bypasses the generic samplerate check.
This is mostly harmless as nellymoser doesn't care about the
samplerate, but since f566032bfd it would cause an AVERROR_BUG
to be returned to the caller, so better reject it outright in
the decoder.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Widths 4 to 64 at 8 bit, with the height a runtime argument as in the
C code. Factoring 2^min(logw,logh) out of the numerator keeps the whole
kernel in words: the largest intermediate is 32704, when max(w,h) is 64.
The term that is linear in y is carried as a running accumulator, so a
row costs one pmullw and three shifts per column group. Widths 32 and 64
run two column groups per pass and write a row with a single 32 byte
store.
checkasm --bench on a Core Ultra 7 155H:
vvc_pred_planar_4x4_8_c: 63.0
vvc_pred_planar_4x4_8_avx2: 20.3 ( 3.10x)
vvc_pred_planar_8x8_8_c: 216.7
vvc_pred_planar_8x8_8_avx2: 35.6 ( 6.09x)
vvc_pred_planar_16x16_8_c: 966.4
vvc_pred_planar_16x16_8_avx2: 80.3 (12.03x)
vvc_pred_planar_32x32_8_c: 3032.7
vvc_pred_planar_32x32_8_avx2: 251.5 (12.06x)
vvc_pred_planar_64x64_8_c: 10389.9
vvc_pred_planar_64x64_8_avx2: 967.1 (10.74x)
set_sps() with a NULL SPS released s->vps before returning, also when only
a non-base layer was cleared while the base layer keeps decoding. The next
base-layer frame then dereferenced the NULL VPS in ff_hevc_is_alpha_video().
Release s->vps only when a new SPS is installed alongside it.
Assisted-by: Fairy
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
During USAC decoding (ff_aac_usac_decode_frame), configuration elements
can be mapped and instantiated via che_configure(). For newly allocated
ChannelElement structs, che_configure calls sbr_ctx_alloc_init() which
dynamically allocates ac->che[type][id]. However, che_configure did not
subsequently map the output pointer of the nested SingleChannelElement
elements back to their statically-sized internal ret_buf arrays, causing
a null pointer dereference during IMDCT windowing.
The fix explicitly initializes these pointers following allocation.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The weighted narrowing after the horizontal filter was repeated at every
width. Sharing one stage at a time rather than a whole block at a time
keeps the serial sqxtn/sqxtn2/sqxtun chain of a block from stalling an
in-order core.
Michael Niedermayer