Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #61426 > unrolled thread

Bug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)

Started byjohn terragon <terragonjohn@yahoo.com>
First post2018-07-16 22:30 +0200
Last post2018-07-30 00:50 +0200
Articles 5 — 4 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes) john terragon <terragonjohn@yahoo.com> - 2018-07-16 22:30 +0200
    Processed: Re: [initramfs-tools-core] unmkinitramfs uses "-t" for  zcat like it was a "test integrity" option (it's not and it causes  crashes) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-07-18 07:10 +0200
    Bug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes) Ben Hutchings <ben@decadent.org.uk> - 2018-07-18 07:10 +0200
    Bug#903931: Neither zcat nor xzcat should be used in scripts Antonio Diaz Diaz <antonio@gnu.org> - 2018-07-27 09:50 +0200
    Bug#903931: Maybe trailing garbage or data in an unsupported format is causing the problem? Antonio Diaz Diaz <antonio@gnu.org> - 2018-07-30 00:50 +0200

#61426 — Bug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)

Fromjohn terragon <terragonjohn@yahoo.com>
Date2018-07-16 22:30 +0200
SubjectBug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)
Message-ID<wcii6-89r-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Package: initramfs-tools-core

Version: 0.130

Severity: normal




--- Please enter the report below this line. ---







The following code fragment is in the xcpio() function of unmkinitramfsunmkinitramfs:

if zcat -t "$archive" >/dev/null 2>&1 ; then
                zcat "$archive"
        elif xzcat -t "$archive" >/dev/null 2>&1 ; then
                xzcat "$archive"
        elif bzip2 -t "$archive" >/dev/null 2>&1 ; then
                bzip2 -c -d "$archive"
        elif lzop -t "$archive" >/dev/null 2>&1 ; then
                lzop -c -d "$archive"



the -t flag used with zcat does not have the same meaning it had with the other programs, xzcat, bzip2 and lzop. With the latter it
means "just do  a test" with the former it is equivalent to -vT (neither -v nor -T means "test"). Now, this causes a strange and
unpredictable behavior of unmkinitramfs (and of lsinitramfs, which uses unmkinitramfs) where for some, not all, initrd files it just aborts its operations with this

free(): invalid next size (normal)

Aborted



Notice that even when it aborts, the "guilty" initrd file is perfectly fine and it can uncrompressed with gunzip or with zcat (without the -t, which, again, it is not the flag for testing the input file).

Solution: remove the -t from "if zcat -t "$archive" >/dev/null 2>&1 ;"




--- System information. ---

Architecture: 

Kernel: Linux 4.17.4-cu5




Debian Release: buster/sid

 500 unstable ftp.debian.org 

 500 testing ftp.debian.org 

 500 stable ftp.debian.org 

 500 oldstable ftp.debian.org 

 500 oldoldstable ftp.debian.org 

 1 experimental ftp.debian.org 




--- Package information. ---

Depends (Version) | Installed

===================================-+-==============

klibc-utils (>= 2.0.4-8~) | 2.0.4-11

cpio | 2.12+dfsg-6

kmod | 25-1

 OR module-init-tools | 20-1

udev | 239-5







Recommends (Version) | Installed

=====================================-+-===================

busybox (>= 1:1.22.0-17~) | 1:1.27.2-2

 OR busybox-static (>= 1:1.22.0-17~) | 







Suggests (Version) | Installed

==============================-+-===========

bash-completion | 1:2.8-1

[toc] | [next] | [standalone]


#61453 — Processed: Re: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2018-07-18 07:10 +0200
SubjectProcessed: Re: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)
Message-ID<wcMSR-1e5-5@gated-at.bofh.it>
In reply to#61426
Processing control commands:

> reassign -1 gzip
Bug #903931 [initramfs-tools-core] [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)
Bug reassigned from package 'initramfs-tools-core' to 'gzip'.
Ignoring request to alter found versions of bug #903931 to the same values previously set
Ignoring request to alter fixed versions of bug #903931 to the same values previously set
> retitle -1 zcat -t sometimes crashes with heap corruption
Bug #903931 [gzip] [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)
Changed Bug title to 'zcat -t sometimes crashes with heap corruption' from '[initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)'.
> tag -1 moreinfo
Bug #903931 [gzip] zcat -t sometimes crashes with heap corruption
Added tag(s) moreinfo.

-- 
903931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903931
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#61454

FromBen Hutchings <ben@decadent.org.uk>
Date2018-07-18 07:10 +0200
Message-ID<wcMSR-1e5-1@gated-at.bofh.it>
In reply to#61426

[Multipart message — attachments visible in raw view] — view raw

Control: reassign -1 gzip
Control: retitle -1 zcat -t sometimes crashes with heap corruption
Control: tag -1 moreinfo

On Mon, 16 Jul 2018 20:17:13 +0000 (UTC) john terragon <terragonjohn@yahoo.com> wrote:
[...]
> the -t flag used with zcat does not have the same meaning it had with
the other programs, xzcat, bzip2 and lzop. With the latter it
> means "just do  a test" with the former it is equivalent to -vT
(neither -v nor -T means "test").

The manual page for zcat clearly states that -t does an integrity test.
 If it does not, that's a bug in zcat.

> Now, this causes a strange and
> unpredictable behavior of unmkinitramfs (and of lsinitramfs, which
uses unmkinitramfs) where for some, not all, initrd files it just
aborts its operations with this
>
> free(): invalid next size (normal)
> 
> Aborted
[...]

Crashing on weird input is a bug in the program that crashes.

Please report which version of gzip is installed.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky

[toc] | [prev] | [next] | [standalone]


#61645 — Bug#903931: Neither zcat nor xzcat should be used in scripts

FromAntonio Diaz Diaz <antonio@gnu.org>
Date2018-07-27 09:50 +0200
SubjectBug#903931: Neither zcat nor xzcat should be used in scripts
Message-ID<wg5FE-5kk-5@gated-at.bofh.it>
In reply to#61426
As advised in the xz man page:

When writing scripts that need to decompress files, it is recommended to 
always use the name xz with appropriate arguments (xz -d or xz -dc) 
instead of the names unxz and xzcat.

Patch follows:

diff -urdN initramfs-tools.orig/unmkinitramfs initramfs-tools/unmkinitramfs
--- initramfs-tools.orig/unmkinitramfs  2018-07-18 06:50:17.000000000 +0200
+++ initramfs-tools/unmkinitramfs       2018-07-27 09:17:07.000000000 +0200
@@ -14,10 +14,10 @@
         dir="$2"
         shift 2

-       if zcat -t "$archive" >/dev/null 2>&1 ; then
-               zcat "$archive"
-       elif xzcat -t "$archive" >/dev/null 2>&1 ; then
-               xzcat "$archive"
+       if gzip -t "$archive" >/dev/null 2>&1 ; then
+               gzip -c -d "$archive"
+       elif xz -t "$archive" >/dev/null 2>&1 ; then
+               xz -c -d "$archive"
         elif lz4cat -t "$archive" >/dev/null 2>&1 ; then
                 lz4cat "$archive"
         elif bzip2 -t "$archive" >/dev/null 2>&1 ; then


Best regards,
Antonio.

[toc] | [prev] | [next] | [standalone]


#61669 — Bug#903931: Maybe trailing garbage or data in an unsupported format is causing the problem?

FromAntonio Diaz Diaz <antonio@gnu.org>
Date2018-07-30 00:50 +0200
SubjectBug#903931: Maybe trailing garbage or data in an unsupported format is causing the problem?
Message-ID<wh2FH-808-3@gated-at.bofh.it>
In reply to#61426
Note in the code below that by using a multi-format zcat, other data not 
in one of the formats supported by the zcat used may be no longer 
ignored but passed to cpio (possibly compressed), which may be the cause 
of the problem.

Using the compressors directly to test the format (without *zcat 
wrappers) guarantees that the "other data" is indeed ignored.

         if zcat -t "$archive" >/dev/null 2>&1 ; then
                 zcat "$archive"
         elif xzcat -t "$archive" >/dev/null 2>&1 ; then
                 xzcat "$archive"
         elif lz4cat -t "$archive" >/dev/null 2>&1 ; then
                 lz4cat "$archive"
         elif bzip2 -t "$archive" >/dev/null 2>&1 ; then
                 bzip2 -c -d "$archive"
         elif lzop -t "$archive" >/dev/null 2>&1 ; then
                 lzop -c -d "$archive"
         # Ignoring other data, which may be garbage at the end of the file
         fi | (
                 if [ -n "$dir" ]; then
                         mkdir -p -- "$dir"
                         cd -- "$dir"
                 fi
                 cpio "$@"
         )

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web