[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#815915: marked as done (initramfs-tools-core: lsinitramfs causes zcat crash when Intel microcode is included in initrd)

Your message dated Sun, 17 Apr 2016 20:25:21 +0100
with message-id <1460921121.9121.19.camel@decadent.org.uk>
and subject line Re: lsinitramfs fails to properly skip the padding after each cpio archive
has caused the Debian Bug report #815915,
regarding initramfs-tools-core: lsinitramfs causes zcat crash when Intel microcode is included in initrd
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
815915: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815915
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: initramfs-tools-core
Version: 0.123
Severity: normal

Dear Maintainer,

When using lsinitramfs to check the contents of an initrd:

> root:~# lsinitramfs /boot/initrd.img-4.4.2
> /boot/initrd.img-4.4.2-curly-0
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/GenuineIntel.bin
> *** Error in `zcat': double free or corruption (!prev): 0x0000000002236940 ***

lsinitramfs runs fine on my AMD boxes.

It seems that Ubuntu has at least two reports of this: see their bug
numberss 1541076 and 1507443. I don't see a Debian bug report on it, though.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.2-curly-0 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages initramfs-tools-core depends on:
ii  cpio         2.11+dfsg-5
ii  klibc-utils  2.0.4-8
ii  kmod         22-1
ii  udev         228-6

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.22.0-18

Versions of packages initramfs-tools-core suggests:
pn  bash-completion  <none>

-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed:
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
DEVICE=
NFSROOT=auto


-- no debconf information

--- End Message ---
--- Begin Message --- 
On Sun, 2016-04-17 at 14:41 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Apr 2016, Ben Hutchings wrote:
> > 
> > On Wed, 30 Mar 2016 14:33:52 -0300 Henrique de Moraes Holschuh  wrote:
> > > 
> > > (note: I am not subscribed to this bug report. If you want a reply from
> > > me, please keep me Cc'd).
> > [...]
> > > 
> > > Now, to the root cause of the breakage:
> > >  
> > > The heuristics initramfs-tools "lsinitramfs" uses (used?) to locate the
> > > next initramfs are incomplete (it does not skip over the padding at the
> > > end of each initramfs)
> > Nope.
> > 
> > [...]
> > > 
> > > lsinitramfs needs to skip all zero bytes (or dwords) to locate the next
> > > initramfs segment, instead of assuming a cpio block size of 512 bytes.
> > [...]
> > 
> > That is exactly what it does.
> > 
> > Please don't guess what the 'root cause' is, actually do the research.
> Eh, unfortunately I actually did it (sometime ago, for the Ubuntu bug
> report), and evidently got it completely wrong.  Then, I copied my (faulty)
> anaylsis from the Ubuntu bug report to the Debian bug report without
> attempting to re-verify it.
> 
> So, it was actually even worse than not doing the research: it was doing it
> incorrectly in the first place, and not revalidating it sometime later.  I
> apologise for that.
> 
> Here is a data file that triggers the zcat crash, from one of the Ubuntu bug
> reports:
> https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1507443/+attachment/4499699/+files/initrd.img-4.2.0-16-generic.bak

So far as I can work out from that report, that file was rejected by
the *kernel*.  Anyway, lsinitramfs works for me with this file.

> Instrumenting lsinitramfs, we get the correct offset (0x2c00) for the next
> segment start offset, and the temporary file (subarchive) is also correct.
> So, lsinitramfs indeed skips the uncompressed initramfs properly.
>
> Changing lsinitramfs to keep the temporary subarchive makes it simple to
> check it and to test it against zcat.
> 
> A hexdump of the subarchive looks fine.  gzip -d will process it very
> happily, no errors at all.  So will cat (subarchive) | gzip -d | cpio -t.
> 
> zcat either works or crashes depending on how you call it on the resulting
> subarchive:
> 
> zcat -t (subarchive) >/dev/null crashes.

Works for me.

So no-one's shown a bug in initramfs-tools; most likely both problems
are due to some kind of file corruption and/or a bug in gzip.  I'm not
going to waste any more time chasing phantoms.

Ben.

> zcat (subarchive) | cpio -t, and zcat (subarchive) >/dev/null both work
> fine.
> 
-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: