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. *** |