Perpare for the next release about faad2 HOT 27 CLOSED

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.

from faad2.

Sure.

from faad2.

Coverage is roughly 100% =) Woo-hoo

from faad2.

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...

from faad2.

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

from faad2.

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...

from faad2.

Sure. Will try to prepare it tomorrow.

from faad2.

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

from faad2.

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"

from faad2.

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

Do you have plans for these?

from faad2.

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?

from faad2.

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!

from faad2.

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

from faad2.

@eustas how are things going?

from faad2.

@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?

from faad2.

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 =))

from faad2.

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, ..." 😉

from faad2.

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).

from faad2.

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

from faad2.

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.

from faad2.

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

from faad2.

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

from faad2.

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

from faad2.

There seem to be just 2 reported:

• #171 CVE-2023-38857
• #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:::::::*

from faad2.

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.

from faad2.

Yes, these were the two CVEs.

from faad2.

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

from faad2.