FFMpeg XTU Analysis

FFMpeg without XTU versus FFMpeg with XTU

(Tested with Clang 4.0)

Summary

Bug numbers do not match those on the linked viewer. The reason behind this is that we used bug deduplication not yet committed into the CodeChecker codebase.

Analyzed project	All Non-CTU Findings (baseline)	All CTU Findings	New CTU findings	Disappeared findings	Successfully analyzed	Failed to analyze	Analysis Time (baseline)[s]	Analysis Time XTU (1st Phase + 2nd Phase)[s]	Median of bug path length (BPL) in baseline	Median of BPL CTU	Median of BPL of new findings	Median of BPL of disappeared findings
FFMpeg	339	399	101	41	1555 files	8 files	318	44+693	7	9	16	14

Checker ID	Number of new findings
core.CallAndMessage	5
core.DivideZero	5
core.NonNullParamChecker	12
core.NullDereference	18
core.UndefinedBinaryOperatorResult	21
core.uninitialized.Assign	11
core.uninitialized.Branch	6
unix.Malloc	23

✅ Most important true positives found with XTU

1. Called function pointer is null (core.callAndMessage) http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8766
2. Memory leak (unix.malloc) http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8906
3. Memory Leak (unix.malloc): http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8584
4. core.DivideZero http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8536
5. core.DivideZero http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8800
6. core.CallAndMessage http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8930
7. unix.malloc use of memory after freed http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8929
8. core.NullDereference http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=699

• If oformat->priv_data_size is 0, we deref. a proper nullptr at the assignment. ✔️

10. core.uninitialized.Branch -- multiple occurrences of the same error

• http://cc.inf.elte.hu:8080/#baseline=119&newcheck=120&report=11764
• http://cc.inf.elte.hu:8080/#baseline=119&newcheck=120&report=12012
• http://cc.inf.elte.hu:8080/#baseline=119&newcheck=120&report=12164
• The end: "destructor" path does not differentiate on how much "init" steps were successful and always call every "destructor", thus in this case, if no codec is found, the garbade &(AVFrame*) is passed.

11. core.DivisionByZero http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=607

❎ False positives

1. Memory leak http://cc.elte.hu:8080/#baseline=83&newcheck=84&report=8766 ??
2. core.NullDereference http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=774

• Unlikely to happen, as BugPath involves FFMpeg getting used with an unknown protocol.

3. core.DivisionByZero http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=528

• Analyser didn't enter av_mul_q

4. core.uninitialized.Branch http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=708 and http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=907

• Human code analysis reveals that the documentation indicates that the library user MUST set a certain variable to a certain value, after which the bug isn't relevant anymore, as threaded frames will properly be allocated.

5. core.uninitialized.Branch http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=907 ❎

• In line 2466, pb is initialised, after which this pb is contained in the ptr s->pb. avio_read() is called with this s->pb in line 2293 (which still exists and points to valid memory), though the checker says it (s in the function, which got s->pb as argument) is garbage.

6. core.DivisionByZero http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=572

• Assuming gcd is 0 is pretty much impossible for rational numbers.
• NOTE! av_gcd() has undefined behaviour if we query gcd( [<= 0], [<= 0]) but in this context, these are positive integers... (sampling ratios, frame-per-sec, etc.)