A testcase:
[hjl@gnu-tgl-3 pr32761]$ cat x.c
#include <stdio.h>
char bss[0xb5dce8] __attribute__((aligned(65536)));
int
main (void)
{
printf ("hello\n");
}
[hjl@gnu-tgl-3 pr32761]$ gcc -B./ x.c
[hjl@gnu-tgl-3 pr32761]$ readelf -Wl a.out
Elf file type is EXEC (Executable file)
Entry point 0x4003b0
There are 14 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
PHDR 0x000040 0x0000000000400040 0x0000000000400040 0x000310
0x000310 R 0x8
INTERP 0x001000 0x0000000000401000 0x0000000000401000 0x00001c
0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0004b9
0x0004b9 R E 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0002c0
0x0002c0 R 0x1000
LOAD 0x001dc8 0x0000000000402dc8 0x0000000000402dc8 0x000244
0x000244 RW 0x1000
LOAD 0x010000 0x0000000000410000 0x0000000000410000 0x000000
0xb6dce8 RW 0x10000
The offset is beyond the file size.
DYNAMIC 0x001dd8 0x0000000000402dd8 0x0000000000402dd8 0x000200
0x000200 RW 0x8
NOTE 0x000350 0x0000000000400350 0x0000000000400350 0x000024
0x000024 R 0x4
NOTE 0x001260 0x0000000000401260 0x0000000000401260 0x000040
0x000040 R 0x8
NOTE 0x0012a0 0x00000000004012a0 0x00000000004012a0 0x000020
0x000020 R 0x4
GNU_PROPERTY 0x001260 0x0000000000401260 0x0000000000401260 0x000040
0x000040 R 0x8
GNU_EH_FRAME 0x0011a0 0x00000000004011a0 0x00000000004011a0 0x00002c
0x00002c R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW 0x10
GNU_RELRO 0x001dc8 0x0000000000402dc8 0x0000000000402dc8 0x000238
0x000238 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .note.gnu.build-id .init .plt .text .fini
03 .interp .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r
.rela.dyn .rela.plt .rodata .eh_frame_hdr .eh_frame .note.gnu.property
.note.ABI-tag
04 .init_array .fini_array .dynamic .got .got.plt .data
05 .bss
06 .dynamic
07 .note.gnu.build-id
08 .note.gnu.property
09 .note.ABI-tag
10 .note.gnu.property
11 .eh_frame_hdr
12
13 .init_array .fini_array .dynamic .got
[hjl@gnu-tgl-3 pr32761]$ ls -l a.out
-rwxr-xr-x 1 hjl hjl 12592 Mar 5 11:37 a.out
[hjl@gnu-tgl-3 pr32761]$
[hjl@gnu-tgl-3 pr32761]$
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip in Ubuntu Eoan results in Exec format error on WSL1
Status in binutils:
Fix Released
Status in binutils package in Ubuntu:
Fix Released
Status in gzip package in Ubuntu:
Fix Released
Status in binutils source package in Eoan:
Fix Released
Status in gzip source package in Eoan:
Fix Released
Bug description:
[Impact]
* Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
* The error occurs frequently in package updates and makes gzip inoperable
on WSL1
* The problem is caused by PT_LOAD offset pointing past the end of file and
the fix is fixing strip to not generate such ELF files and recompiling gzip
with the fixed strip.
[Test Case]
* Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v
size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
[ Regression Potential ]
* The binutils fix could cause binutils to generate invalid ELF files. The
fix is very small and isolated and has been tested and accepted by upstream,
which makes such problems unlikely.
* Bugs in the toolchain in general can make the rebuilt gzip show new
errors, but this generally applies to many SRUs and security updates. The
testing period in proposed should mitigate this risk.
[Other Info]
* Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed
instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci-
train-ppa-service/+archive/ubuntu/3878 for the -security pocket as
2.33-2ubuntu1.2.
[Originial Bug Text]
Summary:
Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
What I expect to happen:
gzip executes correctly on WSL1.
What happens instead:
gzip fails with an Exec format error.
Notes:
I suspect a change in how gzip is being built for Eoan is causing
issues with ELF parsing on the WSL1 translation layer. For example:
On Disco with gzip 1.9-3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
On Eoan with gzip 1.10-0ubuntu3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0,
stripped
Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
not believe this is an issue in 1.10 because this error does not occur
when building gzip from GNU project source on Ubuntu Eoan.
Justifications:
WSL1 will need to be patched in future Windows builds for this change
in ELF. However that patch will likely not be backported to older
builds of Windows, including Windows Enterprise/Server 2019.
To ensure Eoan can run on current and older builds of Windows Ubuntu
should consider looking at how it's building gzip and see if it can be
made to 'play nice' until WSL1 can be updated.
This was originally reported here:
https://github.com/microsoft/WSL/issues/4461
Details:
Description: Ubuntu Eoan Ermine (development branch)
Release: 19.10
gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
*** 1.10-0ubuntu3 500
500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
