Bug 2059921 - SIGSEGV during the processing 7zip archive
Summary: SIGSEGV during the processing 7zip archive
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: p7zip
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Basto
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-02 10:34 UTC by Nils Bars
Modified: 2022-12-13 16:48 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-12-13 16:48:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
The crashing input alongside a script to automatically reproduce the bug. (6.62 KB, application/zip)
2022-03-02 10:34 UTC, Nils Bars
no flags Details

Description Nils Bars 2022-03-02 10:34:13 UTC
Created attachment 1863831 [details]
The crashing input alongside a script to automatically reproduce the bug.

SIGSEGV during the processing 7zip archive

# Description
During extraction of the attached 7zip archive via
```
/usr/libexec/p7zip/7za e -so -y /testcase
```
a nullpointer dereference is triggered and causes a segmentation fault (SIGSEGV).

This bug allows an attacker to perform a denial of service and possibly opens up
other attack vectors.

To reproduce the crash, we provide scripts alongside the crashing input:
- ./reproduce-ubi.sh: Reproduce crash via a Red Hat Universal Base Image 8 docker container
- ./reproduce-fedora.sh: Reproduce crash via a Fedora 35 docker container
- ./reproduce-ubuntu.sh: Reproduce crash via a Ubuntu 20.04 docker container

If you need further details, we are happy to assist where possible.


# yum info p7zip
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Last metadata expiration check: 0:15:47 ago on Wed Mar  2 10:06:29 2022.
Installed Packages
Name         : p7zip
Version      : 16.02
Release      : 20.el8
Architecture : x86_64
Size         : 1.9 M
Source       : p7zip-16.02-20.el8.src.rpm
Repository   : @System
From repo    : epel
Summary      : Very high compression ratio file archiver
URL          : http://p7zip.sourceforge.net/
License      : LGPLv2 and (LGPLv2+ or CPL)
Description  : p7zip is a port of 7za.exe for Unix. 7-Zip is a file archiver with a very high
             : compression ratio. The original version can be found at http://www.7-zip.org/.

# gdb ubi
[+] Running gdb -ex run -ex backtrace -ex c -ex quit -args /usr/libexec/p7zip/7za e -so -y /testcase
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-16.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/libexec/p7zip/7za...(no debugging symbols found)...done.
Starting program: /usr/libexec/p7zip/7za e -so -y /testcase
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
aaaaaaERROR: CRC Failed : testcase~
ERROR: Data Error : #0
ERROR: Unsupported Method : testcase~

Program received signal SIGSEGV, Segmentation fault.
0x00000000004558dd in ?? ()
#0  0x00000000004558dd in ?? ()
#1  0x000000000042e122 in ?? ()
#2  0x000000000043365a in ?? ()
#3  0x00000000004d6ed2 in ?? ()
#4  0x00000000004f9fb3 in ?? ()
#5  0x00000000004122b4 in ?? ()
#6  0x00007fc1f7500493 in __libc_start_main () from /lib64/libc.so.6
#7  0x00000000004124ce in ?? ()
Continuing.


# yum info p7zip
Last metadata expiration check: 0:25:49 ago on Wed Mar  2 09:55:34 2022.
Installed Packages
Name         : p7zip
Version      : 16.02
Release      : 21.fc35
Architecture : x86_64
Size         : 1.6 M
Source       : p7zip-16.02-21.fc35.src.rpm
Repository   : @System
From repo    : fedora
Summary      : Very high compression ratio file archiver
URL          : http://p7zip.sourceforge.net/
License      : LGPLv2 and (LGPLv2+ or CPL)
Description  : p7zip is a port of 7za.exe for Unix. 7-Zip is a file archiver with a very high
             : compression ratio. The original version can be found at http://www.7-zip.org/.

# valgrind fedora
[+] Running /usr/libexec/p7zip/7za e -so -y /testcase
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==1== Command: /usr/libexec/p7zip/7za e -so -y /testcase
==1== 
aaaaaaERROR: CRC Failed : testcase~
ERROR: Data Error : #0
ERROR: Unsupported Method : testcase~
==1== Invalid read of size 8
==1==    at 0x4537BD: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x42CDAA: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x434B4C: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4BB04A: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4D7A96: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x41235E: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4B9755F: (below main) (in /usr/lib64/libc.so.6)
==1==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1== 
==1== 
==1== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==1==  Access not within mapped region at address 0x0
==1==    at 0x4537BD: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x42CDAA: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x434B4C: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4BB04A: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4D7A96: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x41235E: ??? (in /usr/libexec/p7zip/7za)
==1==    by 0x4B9755F: (below main) (in /usr/lib64/libc.so.6)
==1==  If you believe this happened as a result of a stack
==1==  overflow in your program's main thread (unlikely but
==1==  possible), you can try to increase the size of the
==1==  main thread stack using the --main-stacksize= flag.
==1==  The main thread stack size used in this run was 8388608.
==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 84,069 bytes in 320 blocks
==1==   total heap usage: 1,147 allocs, 827 frees, 1,428,458 bytes allocated
==1== 
==1== LEAK SUMMARY:
==1==    definitely lost: 0 bytes in 0 blocks
==1==    indirectly lost: 0 bytes in 0 blocks
==1==      possibly lost: 0 bytes in 0 blocks
==1==    still reachable: 84,069 bytes in 320 blocks
==1==                       of which reachable via heuristic:
==1==                         newarray           : 1,296 bytes in 2 blocks
==1==         suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
==1== 
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

valgrind: the 'impossible' happened:
   main(): signal was supposed to be fatal

host stacktrace:
==1==    at 0x580428CA: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==1==    by 0x580429F7: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==1==    by 0x58042C60: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==1==    by 0x58042C90: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==1==    by 0x580B1C06: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==1==    by 0x580E42E3: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1



# apt show p7zip-full
Package: p7zip-full
Version: 16.02+dfsg-7build1
Priority: optional
Section: universe/utils
Source: p7zip
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss.com>
Original-Maintainer: Robert Luberda <robert>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 4887 kB
Depends: p7zip (= 16.02+dfsg-7build1), libc6 (>= 2.14), libgcc-s1 (>= 3.0), libstdc++6 (>= 5)
Suggests: p7zip-rar
Breaks: p7zip (<< 15.09+dfsg-3~)
Replaces: p7zip (<< 15.09+dfsg-3~)
Homepage: http://p7zip.sourceforge.net/
Task: kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop
Download-Size: 1187 kB
APT-Manual-Installed: no
APT-Sources: http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
Description: 7z and 7za file archivers with high compression ratio

# valgrind ubuntu
[+] Running /usr/lib/p7zip/7z e -so -y /testcase
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1== Command: /usr/lib/p7zip/7z e -so -y /testcase
==1== 
aaaaaaERROR: CRC Failed : testcase~
ERROR: Data Error : #0
ERROR: Unsupported Method : testcase~
==1== Invalid read of size 8
==1==    at 0x52488ED: NCoderMixer2::CMixerMT::GetCoder(unsigned int) (CoderMixer2.cpp:869)
==1==    by 0x52147E8: NArchive::N7z::CDecoder::Decode(CExternalCodecs const*, IInStream*, unsigned long long, NArchive::N7z::CFolders const&, unsigned int, unsigned long long const*, ISequentialOutStream*, ICompressProgressInfo*, ISequentialInStream**, ICryptoGetTextPassword*, bool&, bool&, UString&, bool, unsigned int) (7zDecode.cpp:357)
==1==    by 0x5219C21: NArchive::N7z::CHandler::Extract(unsigned int const*, unsigned int, int, IArchiveExtractCallback*) (7zExtract.cpp:351)
==1==    by 0x13BA49: DecompressArchive (Extract.cpp:208)
==1==    by 0x13BA49: Extract(CCodecs*, CObjectVector<COpenType> const&, CRecordVector<int> const&, CObjectVector<UString>&, CObjectVector<UString>&, NWildcard::CCensorNode const&, CExtractOptions const&, IOpenCallbackUI*, IExtractCallbackUI*, IHashCalc*, UString&, CDecompressStat&) (Extract.cpp:445)
==1==    by 0x161FA8: Main2(int, char**) (Main.cpp:923)
==1==    by 0x11C526: main (MainAr.cpp:66)
==1==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1== 
==1== 
==1== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==1==  Access not within mapped region at address 0x0
==1==    at 0x52488ED: NCoderMixer2::CMixerMT::GetCoder(unsigned int) (CoderMixer2.cpp:869)
==1==    by 0x52147E8: NArchive::N7z::CDecoder::Decode(CExternalCodecs const*, IInStream*, unsigned long long, NArchive::N7z::CFolders const&, unsigned int, unsigned long long const*, ISequentialOutStream*, ICompressProgressInfo*, ISequentialInStream**, ICryptoGetTextPassword*, bool&, bool&, UString&, bool, unsigned int) (7zDecode.cpp:357)
==1==    by 0x5219C21: NArchive::N7z::CHandler::Extract(unsigned int const*, unsigned int, int, IArchiveExtractCallback*) (7zExtract.cpp:351)
==1==    by 0x13BA49: DecompressArchive (Extract.cpp:208)
==1==    by 0x13BA49: Extract(CCodecs*, CObjectVector<COpenType> const&, CRecordVector<int> const&, CObjectVector<UString>&, CObjectVector<UString>&, NWildcard::CCensorNode const&, CExtractOptions const&, IOpenCallbackUI*, IExtractCallbackUI*, IHashCalc*, UString&, CDecompressStat&) (Extract.cpp:445)
==1==    by 0x161FA8: Main2(int, char**) (Main.cpp:923)
==1==    by 0x11C526: main (MainAr.cpp:66)
==1==  If you believe this happened as a result of a stack
==1==  overflow in your program's main thread (unlikely but
==1==  possible), you can try to increase the size of the
==1==  main thread stack using the --main-stacksize= flag.
==1==  The main thread stack size used in this run was 8388608.
==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 27,492 bytes in 864 blocks
==1==   total heap usage: 3,233 allocs, 2,369 frees, 1,481,087 bytes allocated
==1== 
==1== LEAK SUMMARY:
==1==    definitely lost: 0 bytes in 0 blocks
==1==    indirectly lost: 0 bytes in 0 blocks
==1==      possibly lost: 0 bytes in 0 blocks
==1==    still reachable: 27,492 bytes in 864 blocks
==1==                       of which reachable via heuristic:
==1==                         newarray           : 1,296 bytes in 2 blocks
==1==         suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
==1== 
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

valgrind: the 'impossible' happened:
   main(): signal was supposed to be fatal

host stacktrace:
==1==    at 0x58046FFA: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x58047127: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x58047390: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580473C0: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580BA566: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580F6117: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Comment 1 Ben Cotton 2022-11-29 17:59:13 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 2 Ben Cotton 2022-12-13 16:48:47 UTC
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.