An exploitable use-after-free vulnerability exists in WebKitGTK browser version 2.30.3 x64. A specially crafted HTML web page can cause a use-after-free condition, resulting in remote code execution. The victim needs to visit a malicious web site to trigger the vulnerability.

CVE-2021-21806: TALOS-2020-1214 || Cisco Talos Intelligence Group

It was discovered that the get_pid_info() function in data/apport did not properly parse the /proc/pid/status file from the kernel.

Vulnerabilities in Apport in ubuntu 20.04/18.04

\=======\=======\=======\=======\=======\=======\======

Author information

\------------------

Itai Greenhut(@Gr33nh4t)

Aleph Research by HCL Appscan

<email address hidden>

SUMMARY

\-------

We found several vulnerabilities in apport program which work on default installations of ubuntu 20.04/18.04.

We were able to chain those vulnerabilities together to get local privilege escalation to root from an unprivileged user.

Issue 1: Bypass drop\_privileges and set Uid and Gid to arbitrary value

\-------\-------\-------\-------\-------\-------\-------\-------\------

real\_uid and real\_gid are set by reading /proc/pid/status file and parsing its content.

"get\_pid\_info" function will iterate through each line and if a line starts with "Uid:" or "Gid:" it takes the first argument in that line and puts it into real\_uid and real\_gid variables.

We were able to bypass this by crashing a process with a file name set to "a\\rUid: 0\\rGid: 0".

When the process crashed, we "injected" those values to /proc/pid/status file (in the Name field), causing apport to never really drop privileges in the function drop\_privileges( real\_uid now is 0 and real\_gid is also 0).

By having full control over real\_uid and real\_gid we were able to bypass the suid check on "write\_user\_coredump" function.

Issue 2: Bypass get\_process\_startime check

\-------\-------\-------\-------\-------\-------\-------\-------\-

Apport checks if the process was replaced after the crash by comparing between apport\_start and process\_start.

process\_start gets the start time of the process by parsing the content of /proc/pid/stat file.

The start time is extracted from the 22 column of the /proc/pid/stat file.

We were able to bypass this check by recycle the pid with a process with " "(space) in its filename, causing get\_process\_starttime to return the wrong value (which is smaller than apport\_start).

Issue 3: delay apport get\_pid\_info by 30 seconds and recycle pid to suid process

\-------\-------\-------\-------\-------\-------\-------\-------\-------\-------\-------\----

We were able to delay apport get\_pid by 30 seconds from the process creation by acquiring the lock file of apport.

We were able to lock the file by creating a fifo file with a predictable name file crash in /var/log, and then create a new instance of apport.

Now when we create another apport instance it will then be locked for 30 seconds before getting a timeout.

We can release the lock file of the first instance by writing to the fifo file.

Exploitation:

\-------\-------\-------\-------\-------\-------\-------\-------\-

Our main goal in the exploitation is to write core file owned by root with our content to an arbitrary directory.

Apport creates a core file in the current directory of the crashed process.

As seen before on other apport exploits, we will create a core file in /etc/logrotate.d/ directory and execute a root shell.

In order to exploit those issues to gain local privilege escalation we need to perform the following steps:

1\. Create unpackaged=true configuration in ~/.conf/apport/settings

2\. mkfifo a predictable file of a decoy process.

3\. Run the decoy process causing the first apport instance to "hang".

4\. Create a symlink to /usr/bin/sudo with the name "a\\rUid: 0\\rGid: 0"

5\. chdir to desired directory.

6\. Create the crash program.

7\. Fork lots of new processes to make the pid wrap to crash\_program\_pid - 1.

8\. Send SIGSEGV to crash the program and trigger an additional apport instance.

9\. Send SIGKILL to terminate the program and release crash\_program\_pid.

10\. Create new process with fork and execve("a/rUid: 0\\rGid: 0"). (The crafted file name)

11\. Release the first process by writing to the fifo file.

The second apport instance will continue with execution and create a core dump in the current directory of the new suid process.

Now we have a root owned core file in desired directory, we can exploit this by having a valid configuration for logrotate inside the core dump and place the core dump inside /etc/logrotate.d/ directory.

CREDITS

\-------\-------\-------\-------\-------\-------\-------\-------\-

Please credit "Itai Greenhut(@Gr33nh4t) from Aleph Research by HCL Appscan" for those issues.

Please note that we follow the community standard of 90 days before public disclosure please coordinate your patch release date with us.

Attaching poc of the exploit, run as follows:  
1\. tar zxvfm exploit.tar.gz  
2\. cd exploit  
3\. ./exploit.sh

Best regards,  
Itai Greenhut  
Aleph Research by HCL Appscan

CVE-2021-25682: Bug #1912326 “Privilege escalation to root with core file dump” : Bugs : apport package : Ubuntu

A null pointer dereference was discovered lzo_decompress_buf in stream.c in Irzip 0.621 which allows an attacker to cause a denial of service (DOS) via a crafted compressed file.

Bug #1893641 reported by Doudou Huang on 2020-08-31

This bug affects 1 person

Affects

Status

Importance

Assigned to

Milestone

lrzip (Ubuntu)

Confirmed

Undecided

Unassigned

**Bug Description**

Hi, there.

There is invalid memory access in lzo\_decompress\_buf, stream.c 589 in the lrzip version 0.621 (newest branch 597be1f).  
According to the trace, it seems to be an incomplete fix of CVE-2017-8845 and CVE-2019-10654.  
System:

DISTRIB\_ID=Ubuntu  
DISTRIB\_RELEASE=16.04  
DISTRIB\_CODENAME=xenial  
DISTRIB\_DESCRIPTION="Ubuntu 16.04.6 LTS"

To reproduce, run:

lrzip -t seg-stream589

This is the output from the terminal:

Decompressing...  
Segmentation fault  
This is the trace reported by ASAN:

\==177389==ERROR: AddressSanitizer: SEGV on unknown address 0x606000010000 (pc 0x7f19986a0144 bp 0x62100001cd54 sp 0x7f1994afed60 T1)  
    #0 0x7f19986a0143 in lzo1x\_decompress (/lib/x86\_64-linux-gnu/liblzo2.so.2+0x13143)  
    #1 0x43faff in lzo\_decompress\_buf ../stream.c:589  
    #2 0x43faff in ucompthread ../stream.c:1529  
    #3 0x7f199804d6b9 in start\_thread (/lib/x86\_64-linux-gnu/libpthread.so.0+0x76b9)  
    #4 0x7f199747f41c in clone (/lib/x86\_64-linux-gnu/libc.so.6+0x10741c)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV ??:0 lzo1x\_decompress  
Thread T1 created by T0 here:  
    #0 0x7f19988e51e3 in pthread\_create (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x361e3)  
    #1 0x451505 in create\_pthread ../stream.c:133  
    #2 0x451505 in fill\_buffer ../stream.c:1694  
    #3 0x451505 in read\_stream ../stream.c:1781  
    #4 0x18 (<unknown module>)

\==177389==ABORTING

CVE-2020-25467: Bug #1893641 “segmentation fault in lzo_decompress_buf, stream.c...” : Bugs : lrzip package : Ubuntu

An issue was discovered in the Linux kernel before 5.0.19. The XFRM subsystem has a use-after-free, related to an xfrm_state_fini panic, aka CID-dbb2483b2a46.

CVE-2019-25045

SOGo 2.x before 2.4.1 and 3.x through 5.x before 5.1.1 does not validate the signatures of any SAML assertions it receives. Any actor with network access to the deployment could impersonate users when SAML is the authentication method. (Only versions after 2.0.5a are affected.)

CVE-2021-33054: sogo/CHANGELOG.md at master · inverse-inc/sogo

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the av_dict_set function in dict.c.

**#8315 closed defect (fixed)**

Reported by:

Owned by:

Priority:

minor

Component:

ffmpeg

Version:

git-master

Keywords:

leak

Cc:

Blocked By:

Blocking:

Reproduced by developer:

no

Analyzed by developer:

no

Summary of the bug:  
There're memory leaks detected in av\_dict\_set()  
How to reproduce:  

% ffmpeg\_g -y -i $PoC1 -i $PoC2 -filter\_complex acompressor -target dvd -loglevel 0 -c pcm\_s24le tmp.dnxhd

ffmpeg version N-95464-g7056ddc0e0 Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 6.0.0-1ubuntu2 (tags/RELEASE\_600/final)
configuration: --cc=clang --cxx=clang++ --ld=clang --enable-debug

Here's Valgrind log  

\==36149== HEAP SUMMARY:
==36149==     in use at exit: 1,046 bytes in 61 blocks
==36149==   total heap usage: 643 allocs, 582 frees, 2,630,129 bytes allocated
==36149== 
==36149== 54 (16 direct, 38 indirect) bytes in 1 blocks are definitely lost in loss record 40 of 44
==36149==    at 0x9FE3E76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==36149==    by 0x9FE3F91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==36149==    by 0x592F079: av\_malloc (mem.c:87)
==36149==    by 0x592F079: av\_mallocz (mem.c:238)
==36149==    by 0x58EA3CC: av\_dict\_set (dict.c:89)
==36149==    by 0x45D36E: new\_output\_stream (ffmpeg\_opt.c:1554)
==36149==    by 0x455A25: new\_audio\_stream (ffmpeg\_opt.c:1860)
==36149==    by 0x4508EC: init\_output\_filter (ffmpeg\_opt.c:2062)
==36149==    by 0x43481F: open\_output\_file (ffmpeg\_opt.c:2187)
==36149==    by 0x42DE5E: open\_files (ffmpeg\_opt.c:3283)
==36149==    by 0x42DC06: ffmpeg\_parse\_options (ffmpeg\_opt.c:3337)
==36149==    by 0x487BB3: main (ffmpeg.c:4862)
==36149== 
==36149== LEAK SUMMARY:
==36149==    definitely lost: 16 bytes in 1 blocks
==36149==    indirectly lost: 38 bytes in 3 blocks
==36149==      possibly lost: 0 bytes in 0 blocks
==36149==    still reachable: 992 bytes in 57 blocks
==36149==         suppressed: 0 bytes in 0 blocks
==36149== Reachable blocks (those to which a pointer was found) are not shown.
==36149== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==36149== 
==36149== For counts of detected and suppressed errors, rerun with: -v
==36149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Please confirm.  
Thanks

CVE-2020-22054: #8315 (memory leaks in av_dict_set()) – FFmpeg

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the wtvfile_open_sector function in wtvdec.c.

**#8314 closed defect (fixed)**

Reported by:

Owned by:

Priority:

normal

Component:

avformat

Version:

git-master

Keywords:

wtv leak

Cc:

Blocked By:

Blocking:

Reproduced by developer:

yes

Analyzed by developer:

no

Summary of the bug:  
There're memory leaks detected in wtvfile\_open\_sector()  
How to reproduce:  

% ffmpeg\_g -i $PoC tmp.lxf

ffmpeg version N-95464-g7056ddc0e0 Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 6.0.0-1ubuntu2 (tags/RELEASE\_600/final)
configuration: --cc=clang --cxx=clang++ --ld=clang --enable-debug

Here's Valgrind log  

\==10445== HEAP SUMMARY:
==10445==     in use at exit: 5,236 bytes in 38 blocks
==10445==   total heap usage: 102 allocs, 64 frees, 79,475 bytes allocated
==10445== 
==10445== 4,412 (264 direct, 4,148 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33
==10445==    at 0x9FE3E76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==10445==    by 0x9FE3F91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==10445==    by 0x592EC7D: av\_malloc (mem.c:87)
==10445==    by 0x14731F6: avio\_alloc\_context (aviobuf.c:140)
==10445==    by 0x1AB7BA6: wtvfile\_open\_sector (wtvdec.c:238)
==10445==    by 0x1AB7BA6: wtvfile\_open2 (wtvdec.c:289)
==10445==    by 0x1AB3355: read\_header (wtvdec.c:989)
==10445==    by 0x1A145FC: avformat\_open\_input (utils.c:633)
==10445==    by 0x42FFF7: open\_input\_file (ffmpeg\_opt.c:1105)
==10445==    by 0x42DE5E: open\_files (ffmpeg\_opt.c:3283)
==10445==    by 0x42DB4F: ffmpeg\_parse\_options (ffmpeg\_opt.c:3323)
==10445==    by 0x487BB3: main (ffmpeg.c:4862)
==10445== 
==10445== LEAK SUMMARY:
==10445==    definitely lost: 264 bytes in 1 blocks
==10445==    indirectly lost: 4,148 bytes in 3 blocks
==10445==      possibly lost: 0 bytes in 0 blocks
==10445==    still reachable: 824 bytes in 34 blocks
==10445==         suppressed: 0 bytes in 0 blocks
==10445== Reachable blocks (those to which a pointer was found) are not shown.
==10445== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10445== 
==10445== For counts of detected and suppressed errors, rerun with: -v
==10445== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Please confirm.  
Thanks

CVE-2020-22049: #8314 (memory leaks in wtvfile_open_sector()) – FFmpeg

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the ff_frame_pool_get function in framepool.c.

**#8303 closed defect (fixed)**

Reported by:

Owned by:

Priority:

important

Component:

undetermined

Version:

git-master

Keywords:

Cc:

Blocked By:

Blocking:

Reproduced by developer:

no

Analyzed by developer:

no

Summary of the bug:  
There are memory leaks in ff\_frame\_pool\_get()  
How to reproduce:  

% ffmpeg\_g -t 3 -y -i $PoC -filter\_complex colorspace -target dvd -loglevel 0 tmp.ads

ffmpeg version N-95441-g0ae6fb276b Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 6.0.0-1ubuntu2 (tags/RELEASE\_600/final)
configuration: --cc=clang --cxx=clang++ --ld=clang --enable-debug

Here's Valgrind log  

\==6446== HEAP SUMMARY:
==6446==     in use at exit: 100,746 bytes in 33 blocks
==6446==   total heap usage: 3,265 allocs, 3,232 frees, 2,295,813 bytes allocated
==6446== 
==6446== 50,357 (536 direct, 49,821 indirect) bytes in 1 blocks are definitely lost in loss record 12 of 13
==6446==    at 0x9FE2E76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==6446==    by 0x9FE2F91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==6446==    by 0x592E949: av\_malloc (mem.c:87)
==6446==    by 0x592E949: av\_mallocz (mem.c:238)
==6446==    by 0x5902ADD: av\_frame\_alloc (frame.c:191)
==6446==    by 0x64FBD5: ff\_frame\_pool\_get (framepool.c:201)
==6446==    by 0xFB8A9C: ff\_default\_get\_video\_buffer (video.c:90)
==6446==    by 0xD20033: scale\_frame (vf\_scale.c:460)
==6446==    by 0xD1F24C: filter\_frame (vf\_scale.c:549)
==6446==    by 0x5CFE9C: ff\_filter\_frame\_framed (avfilter.c:1084)
==6446==    by 0x5CFE9C: ff\_filter\_frame\_to\_filter (avfilter.c:1232)
==6446==    by 0x5CFE9C: ff\_filter\_activate\_default (avfilter.c:1281)
==6446==    by 0x5CFE9C: ff\_filter\_activate (avfilter.c:1443)
==6446==    by 0x5F42A4: push\_frame (buffersrc.c:187)
==6446==    by 0x5F42A4: av\_buffersrc\_add\_frame\_internal (buffersrc.c:261)
==6446==    by 0x5F2E7D: av\_buffersrc\_add\_frame\_flags (buffersrc.c:170)
==6446==    by 0x4CAD5F: ifilter\_send\_frame (ffmpeg.c:2186)
==6446==    by 0x4CAD5F: send\_frame\_to\_filters (ffmpeg.c:2260)
==6446== 
==6446== 50,357 (536 direct, 49,821 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 13
==6446==    at 0x9FE2E76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==6446==    by 0x9FE2F91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==6446==    by 0x592E949: av\_malloc (mem.c:87)
==6446==    by 0x592E949: av\_mallocz (mem.c:238)
==6446==    by 0x5902ADD: av\_frame\_alloc (frame.c:191)
==6446==    by 0x64FBD5: ff\_frame\_pool\_get (framepool.c:201)
==6446==    by 0xFB8A9C: ff\_default\_get\_video\_buffer (video.c:90)
==6446==    by 0x7FD3D4: filter\_frame (vf\_colorspace.c:770)
==6446==    by 0x5CFE9C: ff\_filter\_frame\_framed (avfilter.c:1084)
==6446==    by 0x5CFE9C: ff\_filter\_frame\_to\_filter (avfilter.c:1232)
==6446==    by 0x5CFE9C: ff\_filter\_activate\_default (avfilter.c:1281)
==6446==    by 0x5CFE9C: ff\_filter\_activate (avfilter.c:1443)
==6446==    by 0x5F42BE: push\_frame (buffersrc.c:187)
==6446==    by 0x5F42BE: av\_buffersrc\_add\_frame\_internal (buffersrc.c:261)
==6446==    by 0x5F2E7D: av\_buffersrc\_add\_frame\_flags (buffersrc.c:170)
==6446==    by 0x4CAD5F: ifilter\_send\_frame (ffmpeg.c:2186)
==6446==    by 0x4CAD5F: send\_frame\_to\_filters (ffmpeg.c:2260)
==6446==    by 0x4A07BB: decode\_video (ffmpeg.c:2459)
==6446==    by 0x4A07BB: process\_input\_packet (ffmpeg.c:2613)
==6446== 
==6446== LEAK SUMMARY:
==6446==    definitely lost: 1,072 bytes in 2 blocks
==6446==    indirectly lost: 99,642 bytes in 30 blocks
==6446==      possibly lost: 0 bytes in 0 blocks
==6446==    still reachable: 32 bytes in 1 blocks
==6446==         suppressed: 0 bytes in 0 blocks
==6446== Reachable blocks (those to which a pointer was found) are not shown.
==6446== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6446== 
==6446== For counts of detected and suppressed errors, rerun with: -v
==6446== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Please confirm.  
Thanks

CVE-2020-22048: #8303 (memory leaks in ff_frame_pool_get()) – FFmpeg

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the avpriv_float_dsp_allocl function in libavutil/float_dsp.c.

**#8294 closed defect (fixed)**

Reported by:

Owned by:

Priority:

important

Component:

undetermined

Version:

git-master

Keywords:

Cc:

Blocked By:

Blocking:

Reproduced by developer:

no

Analyzed by developer:

no

Summary of the bug:  
There are memory leaks in avpriv\_float\_dsp\_alloc()  
How to reproduce:  

% ffmpeg\_g -y  -i $PoC -loglevel 0 -psnr tmp.eac3

ffmpeg version N-95425-g1e35519fe0 Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 6.0.0-1ubuntu2 (tags/RELEASE\_600/final)
configuration: --cc=clang --cxx=clang++ --ld=clang --enable-debug

Here's Valgrind log  

\==16402== HEAP SUMMARY:
==16402==     in use at exit: 120 bytes in 2 blocks
==16402==   total heap usage: 889 allocs, 887 frees, 2,885,023 bytes allocated
==16402== 
==16402== 88 bytes in 1 blocks are definitely lost in loss record 2 of 2
==16402==    at 0x9FDFE76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==16402==    by 0x9FDFF91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==16402==    by 0x592C189: av\_malloc (mem.c:87)
==16402==    by 0x592C189: av\_mallocz (mem.c:238)
==16402==    by 0x58FC61E: avpriv\_float\_dsp\_alloc (float\_dsp.c:137)
==16402==    by 0x44EB76E: ff\_ac3\_float\_encode\_init (ac3enc\_float.c:135)
==16402==    by 0x346DC34: avcodec\_open2 (utils.c:946)
==16402==    by 0x4A6841: init\_output\_stream (ffmpeg.c:3507)
==16402==    by 0x4BFFE5: reap\_filters (ffmpeg.c:1442)
==16402==    by 0x48D661: transcode\_step (ffmpeg.c:4638)
==16402==    by 0x48D661: transcode (ffmpeg.c:4682)
==16402==    by 0x487DA3: main (ffmpeg.c:4884)
==16402== 
==16402== LEAK SUMMARY:
==16402==    definitely lost: 88 bytes in 1 blocks
==16402==    indirectly lost: 0 bytes in 0 blocks
==16402==      possibly lost: 0 bytes in 0 blocks
==16402==    still reachable: 32 bytes in 1 blocks
==16402==         suppressed: 0 bytes in 0 blocks
==16402== Reachable blocks (those to which a pointer was found) are not shown.
==16402== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16402== 
==16402== For counts of detected and suppressed errors, rerun with: -v
==16402== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

ASAN log.  

\=================================================================
==33197==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 88 byte(s) in 1 object(s) allocated from:
    #0 0x4de9e8 in posix\_memalign (ffmpeg\_usan+0x4de9e8)
    #1 0x85c2178 in av\_malloc ffmpeg/libavutil/mem.c:87:9
    #2 0x85c2178 in av\_mallocz ffmpeg/libavutil/mem.c:238
    #3 0x85651c0 in avpriv\_float\_dsp\_alloc ffmpeg/libavutil/float\_dsp.c:137:31

SUMMARY: AddressSanitizer: 88 byte(s) leaked in 1 allocation(s).

Please confirm.  
Thanks

CVE-2020-22046: #8294 (memory leaks in avpriv_float_dsp_alloc()) – FFmpeg

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the url_open_dyn_buf_internal function in libavformat/aviobuf.c.

**#8295 closed defect (fixed)**

Reported by:

Owned by:

Priority:

important

Component:

avformat

Version:

git-master

Keywords:

Cc:

Blocked By:

Blocking:

Reproduced by developer:

no

Analyzed by developer:

no

Summary of the bug:  
There are memory leaks in url\_open\_dyn\_buf\_internal()  
How to reproduce:  

% ffmpeg\_g -y -i $PoC tmp.nut

ffmpeg version N-95425-g1e35519fe0 Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 6.0.0-1ubuntu2 (tags/RELEASE\_600/final)
configuration: --cc=clang --cxx=clang++ --ld=clang --enable-debug

Here's Valgrind log  

\==38914== HEAP SUMMARY:
==38914==     in use at exit: 1,352 bytes in 3 blocks
==38914==   total heap usage: 4,302 allocs, 4,299 frees, 12,611,962 bytes allocated
==38914== 
==38914== 1,320 (264 direct, 1,056 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==38914==    at 0x9FDFE76: memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==38914==    by 0x9FDFF91: posix\_memalign (in /usr/lib/valgrind/vgpreload\_memcheck-amd64-linux.so)
==38914==    by 0x592BD8D: av\_malloc (mem.c:87)
==38914==    by 0x147F261: avio\_alloc\_context (aviobuf.c:140)
==38914==    by 0x147F261: url\_open\_dyn\_buf\_internal (aviobuf.c:1419)
==38914==    by 0x186E4AD: nut\_write\_trailer (nutenc.c:1173)
==38914==    by 0x17EBB33: av\_write\_trailer (mux.c:1283)
==38914==    by 0x48FF5B: transcode (ffmpeg.c:4716)
==38914==    by 0x487DA3: main (ffmpeg.c:4884)
==38914== 
==38914== LEAK SUMMARY:
==38914==    definitely lost: 264 bytes in 1 blocks
==38914==    indirectly lost: 1,056 bytes in 1 blocks
==38914==      possibly lost: 0 bytes in 0 blocks
==38914==    still reachable: 32 bytes in 1 blocks
==38914==         suppressed: 0 bytes in 0 blocks
==38914== Reachable blocks (those to which a pointer was found) are not shown.
==38914== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==38914== 
==38914== For counts of detected and suppressed errors, rerun with: -v
==38914== ERROR SUMMARY: 82534 errors from 137 contexts (suppressed: 0 from 0)

ASAN log.  

\=================================================================
==21625==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 264 byte(s) in 1 object(s) allocated from:
    #0 0x4de9e8 in posix\_memalign (ffmpeg\_usan+0x4de9e8)
    #1 0x85c1021 in av\_malloc ffmpeg/libavutil/mem.c:87:9
    #2 0x1cdb48f in avio\_alloc\_context ffmpeg/libavformat/aviobuf.c:140:22
    #3 0x1cdb48f in url\_open\_dyn\_buf\_internal ffmpeg/libavformat/aviobuf.c:1419

Indirect leak of 1056 byte(s) in 1 object(s) allocated from:
    #0 0x4de9e8 in posix\_memalign (ffmpeg\_usan+0x4de9e8)
    #1 0x85c2178 in av\_malloc ffmpeg/libavutil/mem.c:87:9
    #2 0x85c2178 in av\_mallocz ffmpeg/libavutil/mem.c:238
    #3 0x1cdb3af in url\_open\_dyn\_buf\_internal ffmpeg/libavformat/aviobuf.c:1415:9
    #4 0x8a78fcd in \_fini (ffmpeg\_usan+0x8a78fcd)

SUMMARY: AddressSanitizer: 1320 byte(s) leaked in 2 allocation(s).

Please confirm.  
Thanks

Tag

#ubuntu