Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 233325 - Dumps restore dies with SIGSEGV when restoring a remote compressed dump
Summary: Dumps restore dies with SIGSEGV when restoring a remote compressed dump
Alias: None
Product: Fedora
Classification: Fedora
Component: dump
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-21 16:31 UTC by Lubomir Kundrak
Modified: 2013-04-30 23:35 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-27 13:33:25 UTC

Attachments (Terms of Use)

Description Lubomir Kundrak 2007-03-21 16:31:06 UTC
Description of problem:

Restore can not restore compressed dumps located on remote systems,
moreover it crashes after receiving a fatal signal.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

Create a compressed dump file. Uncompressed one won't do.

# mkdir somedir
# dump zf somedir.dump somedir
  DUMP: Date of this level  dump: Wed Mar 21 17:20:59 2007

Attempt to access it locally succeeds...

$ RSH=ssh restore if somedir.dump
Dump tape is compressed.
restore > what
Dump   date: Wed Mar 21 17:21:49 2007
Dumped from: the epoch
Level 0 dump of / (dir home/lkundrak/somedir) on pluto:/dev/mapper/vg00-root
Label: none
restore >

...whereas remote restore via SSH fails:

$ RSH=ssh restore if localhost:somedir.dump
Connection to localhost established.
Dump tape is compressed.
short compressed block: 32772 expected: 135005703
decompression error, block 33: length mismatch
Segmentation fault (core dumped)

Additional info:

I haven't looked at this at all, so just in case I set this to private for
now and open just for security sensitive group, as there might be a memory
corruption. It also might be that the Priority I set is too high.

Comment 1 Lubomir Kundrak 2007-03-21 16:43:26 UTC
$ gdb restore restore-13333.core
Core was generated by `restore if localhost:somedir.dump'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000046f0d3 in _wordcopy_fwd_dest_aligned ()
(gdb) bt
#0  0x000000000046f0d3 in _wordcopy_fwd_dest_aligned ()
#1  0x000000000046ebdf in memmove ()
#2  0x000000000040da53 in readtape_comprtape (buf=0x7fff8fef0c80 "") at tape.c:2151
#3  0x000000000040d11e in readtape (buf=0x7fff8fef0c80 "") at tape.c:1890
#4  0x000000000040bf7f in getfile (fill=0x40c3ba <xtrmap>, skip=0x40c3f6
<xtrmapskip>) at tape.c:1311
#5  0x000000000040a807 in setup () at tape.c:417
#6  0x00000000004057c0 in main (argc=1, argv=0x768650) at main.c:488
#7  0x000000000044b470 in __libc_start_main ()
#8  0x00000000004001b9 in _start ()

Comment 2 Lubomir Kundrak 2007-03-21 16:47:44 UTC
Is not SSH specific.

$ RSH=rsh restore if localhost:somedir.dump
Connection to localhost established.
connect to address port 544: Connection refused
Trying krb4 rsh...
connect to address port 544: Connection refused
trying normal rsh (/usr/bin/rsh)
Dump tape is compressed.
short compressed block: 32772 expected: 135005703
decompression error, block 33: length mismatch
Segmentation fault (core dumped)

Comment 3 Lubomir Kundrak 2007-03-21 22:10:32 UTC
Seems just like an out-of-bound read, with no possible security implications.
Making public.

#2  0x000000000040da53 in readtape_comprtape (buf=0x7fffd959ef00 "") at tape.c:2151
2151                    memmove(buf, &tbufptr[(blkcnt++ * TP_BSIZE)], TP_BSIZE);
(gdb) print &tbufptr[(blkcnt++ * TP_BSIZE)]
Cannot access memory at address 0x75baa0
(gdb) print TP_BSIZE
$5 = 1024
(gdb) print blkcnt
$6 = 126

Comment 4 Stelian Pop 2007-03-27 11:35:13 UTC
Not a bug, see the restore man page:

        -l     When  doing  remote  restores,  assume the remote file
               is a regular file (instead of a tape device). If you’re
               restoring a remote compressed file, you will need to specify
               this option or restore will fail to access it correctly.

With the -l, restore does perform correctly.

Comment 5 Adam Tkac 2007-03-27 11:47:44 UTC
(In reply to comment #4)

Thanks much for your very fast feedback. But I think that segfault is bad end
(even thought this due user mistake). I think restore could write something like
"could not access device" or "you must specify -l option when doing remote
restore", not segfault. I could write proposed patch but are you going to accept
that patch or no patch is needed for issues like this.

Regards, -A-

Comment 6 Adam Tkac 2007-03-27 11:49:23 UTC
adding upstream to CC, please see comment #5

Comment 7 Stelian Pop 2007-03-27 13:26:53 UTC
Of course it would be better to handle the error gracefully, but unfortunately
this is hard if possible at all.

The main problem is that compression on tape and compression on file are two
different beasts (mainly because of the blocking factor of the tape drive), and
need two different algorithms to decompress.

In order to use the right algorithm, restore needs to know if the media is a
tape or a file. For a local tape/file it's quite simple (restore issues a
MTIOCGET ioctl and if this fails then it assumes the media is a file). 

Things are more difficult when the media is accessed remotely. rmt(1) protocol
is quite limited, and has real compatability problems when used in mixed
environments (Linux dump, other OS tape server).

A while ago, dump/restore tried to autodetect the remote media type. However,
this caused problems, and this is why dump-0.4b25, in november 2001, added the
-l option. From the CHANGES file:
        Add the -l option to restore to specify if, when doing a
        remote restore, the file used to access the backup is a 
        regular file (the defaults being a tape drive). Restore needs
        to know this information when reading a remote compressed 
        dump. Previously, this information was autodetected, but
        the autodetection code fails (with ioctl: Inappropriate ioctl 
        for device) when using a non Linux remote box. Thanks to 
        many users and especially to Eros Albertazzi 
        <> for reporting this.

This is quite old, and I don't remember exactly what the problems were.

But on the other side, this is the first time someone complains about this since
2001, so I would simply consider this bug to be a feature and close it with a

Comment 8 Adam Tkac 2007-03-27 13:33:25 UTC
(In reply to comment #7)

Don't waste time with this, closing

Note You need to log in before you can comment on or make changes to this bug.