Perpare for the next release

[eustas]

Checklist:

• Channel Coupling #69
• wait 7 days after last fixed fuzzer bug (21.08.2023); NB: does not include "fixed" codepath issues

[fabiangreffrath]

• Distorted sound in AAC stream #67
• Channel Coupling #69

Do you have plans for these?

[eustas]

Sure.

[eustas]

Coverage is roughly 100% =) Woo-hoo

[drew-512]

Love it @eustas -- thanks so much for all your hard work on this!

I'm a Unity and Go dev for many years now. I once shipped an audio engine many years back using iOS CoreAudio Units, so I highly appreciate devs who know how important high performing and reliable realtime AV code is.

I'm not using faad2 yet, but my upcoming worklist is to add AAC support for my FMOD projects using faad2 (using the FMOD codec plugin). One decision I'm still weighing if the plan to use CMake etc or to use Cgo and contribute a Go wrapper/bindings for faad2. Or perhaps someone has already done the heavy lifting to plug faad2 into FMOD?

[eustas]

I also was thinking about adding Bazel build. With that it will be easy to have all the things (library itself, cgo/java/etc wrappers) compiled and tested in one move.
On the other hand, CMake seems to be current golden standard for shipping (native) projects...

[fabiangreffrath]

Indeed. I think, if we need to touch the build system, it should be cmake.

[eustas]

Currently there are 9 open issues for "fixed point" decoding. Likely there are less root causes. None look dangerous. Hopefully will deal with those this / next week.

[drew-512]

Currently there are 9 open issues for "fixed point" decoding. Likely there are less root causes. None look dangerous. Hopefully will deal with those this / next week.

Nice, way to go!

[eustas]

5 issues at the moment (again, all in fixed)

[fabiangreffrath]

@eustas how are things going?

[eustas]

Last month was busy with other projects. Hope to get back to FAAD and resolve the remaining issues in mid-August. Sorry for the delays...

[fabiangreffrath]

@eustas Sorry to bug you again. But, is there anything in the making that would make sense waiting for? Or are we fine to tag the current state of the source as the 2.11 release?

[eustas]

As it was discussed earlier, it is fine to cut 2.11 release (if there are any fixed-point users... well, they should be aware that such build is not flawless, but will become better one day =))

[fabiangreffrath]

I see, thanks! One last thing. Could you please help me and summarize the most important changes that you introduced during this cycle, so I have a bit more that I could add to the changelog than "@eustas fixed an overflow, and then another one, and then some undefined behaviour, and then another one, ..." 😉

[eustas]

Sure. Will try to prepare it tomorrow.

[eustas]

NB: perhaps we should look into patches used by embedders, e.g. VLC; sometimes they fix real problems, sometimes we could make their live easier by adding more compilation options (== ifdefs).

[fabiangreffrath]

Definitely! I think they even contributed some of their patches back during the previous release cycle.

https://code.videolan.org/videolan/vlc/-/tree/master/contrib/src/faad2?ref_type=heads

[fabiangreffrath]

Sure. Will try to prepare it tomorrow.

It doesn't have to be exhaustive. Just help me summarize what you have changed since the last release, please.

[eustas]

Sorry, fallen off my radar. Will try to do it today / tomorrow.

[eustas]

CI/CD, build, etc

• setup GitHub workflows; test build under MSVC, OSX, MSYS2, Linux
• add CMake build system
• additionally add Bazel build
• remove automake and MSVC project files
• add fuzzers that cover almost all decoder code
• setup fuzzing for various builds: (no-)FIXED_POINT / (no-)DRM
• remove dead code
• address differes compilers warnings
• move version to distingished place that different build systems can read

"Safe" bugs

"Safe" means that it is unlikely to be exploited; those affect the decoded
result for (most likely) extreme inputs. Some fixes are useful only for
"FIXED_POINT" build, since it has more restrictions on intermediate values.

• "negative range" in estimate_current_envelope
• integer overflow in channel downmixing
• integer overflow in estimate_envelope
• integer overflows caused by "practical infinite" gain
• integer overflows in HF adjustment code
• several "left shift of negative value"
• priming RNG to avoid using values that does not look random at all
• do not drop the first frame of output; other decoders don't do this
• touching uninitialized values in lt_update_state
• touching uninitialized values in bit-reader buffers

"Almost Safe" bugs

"Almost safe" means that those are unlinkly to be exploited; if those surface
depends on build options / environment.

• division by zero in HF (noise?) generator and scale factor adjustment
• division by zero gen_rand_vector

"Unsafe" bugs

"Unsafe" means that those can cause crash, or could somehow else be exploited.

• CLI: accessing unallocated memory in mp4info (corrupted / zero-samples input)
• CLI: out-of-bounds when parsing mp4 header
• CLI: crash because of wrong mp4 frame offset calculation
• error handling rvlc_decode_scale_factors (CPU bomb?)
• null pointer dereference (in DRM + PS build)
• index-out-of-bounds / stack-buffer-overflow in decode_sce_lfe
  (for streams with PCE)
• stack-buffer-overflow in pns_decode
• null pointer derefernce (when channels change their type in the middle
  of the stream)
• infinite loop on currupted stream
• add practial limits for scale factors; otherwise calculated NaN/Inf values
  could confuse further logic, resulting in access-out-of-bounds
• check sf_index in window_grouping_info to avoid access-out-of-bounds
• clamp bs_pointer values to avoid access-out-of-bounds
• infinite loop in fill_element
• sanitize input values in ps_mix_phase to avoid access-out-of-bounds
• fix internal decoder buffer size calculation to avoid heap-out-of-bounds
• calculate channel length multiplier even if main channel is already allocated
  to avoid heap-out-of-bounds
• reserve enough slots for channels in decode_sce_lfe
  to avoid heap-out-of-bounds

[fabiangreffrath]

Perfect, thank you so much! Could you please bring the CVEs into context as well, then that'd be it for me.

[eustas]

Sure. Will look for them today, or on Monday morning.

[eustas]

There seem to be just 2 reported:

• A heap-buffer-overflow vulnerability found in mp4read.c:449:63 #171 CVE-2023-38857
• A SEGV vulnerability found in faad2 #173 CVE-2023-38858

https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&isCpeNameSearch=true&seach_type=all&query=cpe:2.3:a:faad2_project:faad2:2.10.1:::::::*

[drew-512]

Keep up the great work gents!

If it's any motivation, ready here to test as a codec ext for FMOD on macOS, windows, android, and iOS.

[fabiangreffrath]

Yes, these were the two CVEs.

[fabiangreffrath]

So, which of the changelog entries do the CVE ids apply to?

[eustas]

CVE-2023-38857 is fixed by "CLI: crash because of wrong mp4 frame offset calculation"

CVE-2023-38857 is fixed by "CLI: accessing unallocated memory in mp4info"