[Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

Balint Reczey balint.reczey at canonical.com
Fri Dec 20 17:51:05 UTC 2019 

Verified binutils 2.33-2ubuntu1.2 by rebuilding gzip in the Bileto PPA
with new binutils and checking the rebuilt gzip binary:

root at ee-dwz:~# wget https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb
--2019-12-20 17:50:02--  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb
Resolving launchpad.net (launchpad.net)... 91.189.89.222, 91.189.89.223, 2001:67c:1560:8003::8003, ...
Connecting to launchpad.net (launchpad.net)|91.189.89.222|:443... connected.
HTTP request sent, awaiting response... 303 See Other
Location: https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb [following]
--2019-12-20 17:50:03--  https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb
Resolving launchpadlibrarian.net (launchpadlibrarian.net)... 91.189.89.228, 91.189.89.229, 2001:67c:1560:8003::8007, ...
Connecting to launchpadlibrarian.net (launchpadlibrarian.net)|91.189.89.228|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 95292 (93K) [application/x-debian-package]
Saving to: ‘gzip_1.10-0ubuntu3.1_amd64.deb’

gzip_1.10-0ubuntu3.1_amd64.deb
100%[=========================================================================================>]
93.06K  --.-KB/s    in 0.1s

2019-12-20 17:50:03 (715 KB/s) - ‘gzip_1.10-0ubuntu3.1_amd64.deb’ saved
[95292/95292]

root at ee-dwz:~# apt install ./gzip_1.10-0ubuntu3.1_amd64.deb 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'gzip' instead of './gzip_1.10-0ubuntu3.1_amd64.deb'
gzip is already the newest version (1.10-0ubuntu3.1).
The following package was automatically installed and is no longer required:
  libdumbnet1
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
root at ee-dwz:~# 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;}}'
root at ee-dwz:~# echo $?
0
root at ee-dwz:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE

Elf file type is DYN (Shared object file)
Entry point 0x4190
There are 14 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000310 0x000310 R   0x8
  INTERP         0x000350 0x0000000000000350 0x0000000000000350 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0027a0 0x0027a0 R   0x1000
  LOAD           0x003000 0x0000000000003000 0x0000000000003000 0x00ea05 0x00ea05 R E 0x1000
  LOAD           0x012000 0x0000000000012000 0x0000000000012000 0x003e80 0x003e80 R   0x1000
  LOAD           0x016690 0x0000000000017690 0x0000000000017690 0x000d70 0x000d70 RW  0x1000
  LOAD           0x000000 0x000000000001a000 0x000000000001a000 0x000000 0x0ca048 RW  0x1000
  DYNAMIC        0x016b80 0x0000000000017b80 0x0000000000017b80 0x0001f0 0x0001f0 RW  0x8
  NOTE           0x000370 0x0000000000000370 0x0000000000000370 0x000020 0x000020 R   0x8
  NOTE           0x000390 0x0000000000000390 0x0000000000000390 0x000044 0x000044 R   0x4
  GNU_PROPERTY   0x000370 0x0000000000000370 0x0000000000000370 0x000020 0x000020 R   0x8
  GNU_EH_FRAME   0x01433c 0x000000000001433c 0x000000000001433c 0x000404 0x000404 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x016690 0x0000000000017690 0x0000000000017690 0x000970 0x000970 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03     .init .plt .plt.got .plt.sec .text .fini 
   04     .rodata .eh_frame_hdr .eh_frame 
   05     .init_array .fini_array .data.rel.ro .dynamic .got .data 
   06     .bss 
   07     .dynamic 
   08     .note.gnu.property 
   09     .note.gnu.build-id .note.ABI-tag 
   10     .note.gnu.property 
   11     .eh_frame_hdr 
   12     
   13     .init_array .fini_array .data.rel.ro .dynamic .got 
root at ee-dwz:~# 


** Description changed:

- IMPORTANT: Binutils was accidentally built in -proposed instead of in a
- PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
- service/+archive/ubuntu/3877 for the -security pocket.
- 
  [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

** Tags removed: verification-needed verification-needed-eoan
** Tags added: verification-done verification-done-eoan

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
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

More information about the foundations-bugs mailing list