Bug 233325

$ 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 ()
(gdb)

Is not SSH specific.

$ RSH=rsh restore if localhost:somedir.dump
Connection to localhost established.
connect to address 127.0.0.1 port 544: Connection refused
Trying krb4 rsh...
connect to address 127.0.0.1 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)
$

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
(gdb)

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.

(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-

adding upstream to CC, please see comment #5

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 
        <eros.cnr.it> 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
WONTFIX :-)

(In reply to comment #7)

Don't waste time with this, closing