| Summary: | app-misc/mc-4.8.26 Bad system call | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Anton Bolshakov <anton.bugs> |
| Component: | Current packages | Assignee: | Sergei Trofimovich (RETIRED) <slyfox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | axiator, base-system, daks18, gryf_esm, ivo97, polynomial-c, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://midnight-commander.org/ticket/4219 | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=771096 https://bugs.astron.com/view.php?id=254 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
zip file with the issue
Strace output |
||
|
Description
Anton Bolshakov
2021-03-18 00:28:11 UTC
Thanks for the report. Let's start off with the easy bit and hope that it's that: what version of sys-apps/file? (please show emerge -pvO sys-apps/file and emerge --info). We may get lucky and find that bug 771096 has already resolved your case. If not, can you provide strace output (in addition to above information) like in that bug, of file failing on a zip file of yours? We need to know exactly which syscall is being made. Thanks for the report. Let's start off with the easy bit and hope that it's that: what version of sys-apps/file? (please show emerge -pvO sys-apps/file). We may get lucky and find that bug 771096 has already resolved your case. If not, can you provide strace output (in addition to above information) like in that bug, of file failing on a zip file of yours? We need to know exactly which syscall is being made. [ebuild R ] sys-apps/file-5.39-r4::gentoo USE="bzip2 seccomp zlib -lzma -python -static-libs" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 python3_9 -python3_7" 0 KiB
----------------------
strace file -L -z 0.zip
execve("/usr/bin/file", ["file", "-L", "-z", "0.zip"], 0x7ffd7ad543d8 /* 73 vars */) = 0
brk(NULL) = 0x55f36e2b3000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=176645, ...}) = 0
mmap(NULL, 176645, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa037ed8000
close(3) = 0
openat(AT_FDCWD, "/usr/lib64/libmagic.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0PG\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=174096, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa037ed6000
mmap(NULL, 177144, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa037eaa000
mmap(0x7fa037eae000, 114688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fa037eae000
mmap(0x7fa037eca000, 36864, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x20000) = 0x7fa037eca000
mmap(0x7fa037ed3000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7fa037ed3000
close(3) = 0
openat(AT_FDCWD, "/usr/lib64/libseccomp.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300Q\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=308984, ...}) = 0
mmap(NULL, 311344, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa037e5d000
mmap(0x7fa037e82000, 40960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7fa037e82000
mmap(0x7fa037e8c000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2f000) = 0x7fa037e8c000
mmap(0x7fa037e90000, 106496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x32000) = 0x7fa037e90000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p@\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1805928, ...}) = 0
mmap(NULL, 1819440, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa037ca0000
mmap(0x7fa037cc2000, 1335296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7fa037cc2000
mmap(0x7fa037e08000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x168000) = 0x7fa037e08000
mmap(0x7fa037e53000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b2000) = 0x7fa037e53000
mmap(0x7fa037e59000, 13104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa037e59000
close(3) = 0
openat(AT_FDCWD, "/lib64/libbz2.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=74480, ...}) = 0
mmap(NULL, 76840, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa037c8d000
mmap(0x7fa037c8f000, 53248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa037c8f000
mmap(0x7fa037c9c000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7fa037c9c000
mmap(0x7fa037c9e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x7fa037c9e000
close(3) = 0
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0203\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=100128, ...}) = 0
mmap(NULL, 102416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa037c73000
mmap(0x7fa037c76000, 57344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fa037c76000
mmap(0x7fa037c84000, 28672, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x7fa037c84000
mmap(0x7fa037c8b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fa037c8b000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa037c71000
arch_prctl(ARCH_SET_FS, 0x7fa037c71e80) = 0
mprotect(0x7fa037e53000, 16384, PROT_READ) = 0
mprotect(0x7fa037c8b000, 4096, PROT_READ) = 0
mprotect(0x7fa037c9e000, 4096, PROT_READ) = 0
mprotect(0x7fa037e90000, 102400, PROT_READ) = 0
mprotect(0x7fa037ed3000, 8192, PROT_READ) = 0
mprotect(0x55f36dd4d000, 4096, PROT_READ) = 0
mprotect(0x7fa037f2e000, 4096, PROT_READ) = 0
munmap(0x7fa037ed8000, 176645) = 0
brk(NULL) = 0x55f36e2b3000
brk(0x55f36e2d4000) = 0x55f36e2d4000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5543984, ...}) = 0
mmap(NULL, 5543984, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa037727000
close(3) = 0
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
prctl(PR_SET_DUMPABLE, SUID_DUMP_DISABLE) = 0
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, 0, 0x55f36e2b4b60) = 0
stat(0x55f36e2b4f30, 0x7fff2b3efaf0) = -1 ENOENT (No such file or directory)
stat(0x55f36e2b4f30, 0x7fff2b3efaf0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 0x55f36e2b8910, O_RDONLY) = 3
fstat(3, 0x7fff2b3efbe0) = 0
mmap(NULL, 6652192, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x7fa0370ce000
close(3) = 0
mprotect(0x7fa0370ce000, 6652192, PROT_READ) = 0
openat(AT_FDCWD, 0x7fa037e264d0, O_RDONLY) = 3
fstat(3, 0x7fff2b3ef960) = 0
mmap(NULL, 26988, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa037efd000
close(3) = 0
fstat(1, 0x7fff2b3ef520) = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa036fcd000
stat(0x7fff2b3f0ea2, 0x7fff2b3efbc0) = 0
openat(AT_FDCWD, 0x7fff2b3f0ea2, O_RDONLY|O_NONBLOCK) = 3
fstat(3, 0x7fff2b3efbc0) = 0
read(3, 0x7fa036fcd010, 1048576) = 246102
mmap(NULL, 1970176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa036dec000
mmap(NULL, 249856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa036daf000
munmap(0x7fa036daf000, 249856) = 0
munmap(0x7fa036dec000, 1970176) = 0
rt_sigaction(SIGPIPE, 0x7fff2b3ef710, 0x7fff2b3ef7b0, 8) = 0
write(1, 0x55f36e2b9520, 70.zip: ) = 7
pipe( <unfinished ...>) = ?
+++ killed by SIGSYS +++
Bad system call
--------------
zipinfo -v 0.zip
Archive: 0.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 246102 (000000000003C156h)
Actual end-cent-dir record offset: 246080 (000000000003C140h)
Expected end-cent-dir record offset: 246080 (000000000003C140h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 1 entry.
The central directory is 159 (000000000000009Fh) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 245921 (000000000003C0A1h).
Central directory entry #1:
---------------------------
0.pdf
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 6.3
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Feb 19 18:26:46
32-bit CRC value (hex): 30905a86
compressed size: 245814 bytes
uncompressed size: 303165 bytes
length of filename: 77 characters
length of extra field: 36 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
The central-directory extra field contains:
- A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes. The first
20 are: 00 00 00 00 01 00 18 00 15 02 34 b9 a9 06 d7 01 15 02 34 b9.
Created attachment 692205 [details]
zip file with the issue
I tried few zip files and facing this problem with all of them.
So here is the smallest I found
I can reproduce and confirm this. The --uncompress option with .zip files causes an invalid system call for me as well. Created attachment 692229 [details]
Strace output
same here I can confirm, and not only zip archives are affected, but also at least: lzma, xz, zstd (In reply to Anton Bolshakov from comment #0) > > Upstream bug is here: > https://midnight-commander.org/ticket/4219 > Upstream are waiting for a reply from you, I think. (In reply to aporilel from comment #8) > I can confirm, and not only zip archives are affected, but also at least: > lzma, xz, zstd Thanks. I haven't had a chance to test this yet. Something which would help a bit, is if anybody could fire up gdb on file with debugging symbols and show us a backtrace of when this happens. I suspect the file command is working as designed. The seccomp policy installed by file prohibits execution of external commands, but it needs to call unzip to look "inside" a zip file. This is even mentioned in the manpage that was quoted in comment 0. I think app-misc/mc would need to be updated to stop passing "-z" to file, or to add the "-S" option. (In reply to Mike Gilbert from comment #11) > I suspect the file command is working as designed. The seccomp policy > installed by file prohibits execution of external commands, but it needs to > call unzip to look "inside" a zip file. > > This is even mentioned in the manpage that was quoted in comment 0. > > I think app-misc/mc would need to be updated to stop passing "-z" to file, > or to add the "-S" option. I'd argue an error should be thrown rather than letting the filter kill it, but yes. > I'd argue an error should be thrown rather than letting the filter kill it
The end result would be the same, but I suppose the error message could be improved.
It might make sense to request that as an enhancement upstream.
This was fixed in mc upstream last month. Probably just needs a release or a backport. https://github.com/MidnightCommander/mc/commit/1ed638d66cf803f69ac12ee80a72d217f2146e43 1. Does mc-9999 work for you? 2. Upstream asks follow-up questions at https://midnight-commander.org/ticket/4219. Can you provide answers? (In reply to Mike Gilbert from comment #13) > > I'd argue an error should be thrown rather than letting the filter kill it > > The end result would be the same, but I suppose the error message could be > improved. > > It might make sense to request that as an enhancement upstream. This is just input validation, so yes of course it would be? Anyway, yeah, I will. I'll link it here. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10a9d09e7c28f9a838a2bf4ad27a6e657aee7e86 commit 10a9d09e7c28f9a838a2bf4ad27a6e657aee7e86 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-03-31 21:24:54 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-03-31 22:17:40 +0000 app-misc/mc: backport file seccomp failure Reported-by: Anton Bolshakov Closes: https://bugs.gentoo.org/776988 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> app-misc/mc/files/mc-4.8.26-file-seccomp.patch | 142 +++++++++++++++++++++++++ app-misc/mc/mc-4.8.26-r2.ebuild | 118 ++++++++++++++++++++ 2 files changed, 260 insertions(+) *** Bug 779679 has been marked as a duplicate of this bug. *** *** Bug 779940 has been marked as a duplicate of this bug. *** |
