FFMpeg XTU Analysis

FFMpeg without XTU versus FFMpeg with XTU

(Tested with Clang 4.0)

Summary

|Analyzed project| New findings | Disappeared findings | Successfully analyzed | Failed to analyze | Analysis Time (NonXTU)|Analysis Time XTU|Average bug path length in baseline|Average bug path length XTU| |---|---|---|---|---|---|---|---|---|---| |FFMpeg| 151 (core.*(120), unix.malloc(31)| 55| 1409 files | 198 files |?|?|?|

✅ 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.elte.hu:8080/#baseline=1&newcheck=2&report=575
• http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=688
• http://cc.elte.hu:8080/#baseline=1&newcheck=2&report=797
• 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.)