+++ This bug was initially created as a clone of Bug #1086416 +++

sz can segfault in zsdata():

Core was generated by `sz core.0.26368.1520276402.sz.11'.
Program terminated with signal 11, Segmentation fault.
#0  zsdata (buf=0x611120 "core.0.26368.1520276402.sz.11", length=0, frameend=104) at zm.c:435
435                     zsendline(*buf); crc = updcrc((0377 & *buf), crc);
(gdb) bt
#0  zsdata (buf=0x611120 "core.0.26368.1520276402.sz.11", length=0, frameend=104) at zm.c:435
#1  0x00000000004041d1 in zsendfdata (zi=0x7fff17356e90) at lsz.c:2143
#2  0x0000000000404fcc in zsendfile (blen=<optimized out>, buf=<optimized out>, zi=<optimized out>) at lsz.c:1889
#3  wctxpn (zi=0x7fff17356e90) at lsz.c:1260
#4  0x00000000004057a9 in wcs (oname=0x7fff1735859d "core.0.26368.1520276402.sz.11", remotename=0x7fff17355d50 "core.0.26368.1520276402.sz.11")
    at lsz.c:1132
#5  0x0000000000406311 in wcsend (argc=1, argp=<optimized out>) at lsz.c:925
#6  0x00000000004081ea in main (argc=389378616, argv=0x7fff17357210) at lsz.c:792
(gdb)

So zsdata(*buf, length, frameend) was called with length = 0. It does the following:

void
zsdata(const char *buf, size_t length, int frameend)
{
        // .. unsigned short crc = 0 .. printf() ..

        do {
                zsendline(*buf); crc = updcrc((0377 & *buf), crc);
                buf++;
        } while (--length>0);
[..]
}

length is of type size_t, i.e. unsigned int. Subtracting one from zero will wrap length to a positive value. So the loop will run until either length becomes 0 again or dereferencing the buf pointer triggers a segfault, whatever comes first (the latter, of course.)

Calling zsdata() with zero length is intentional, BTW. This is where it got called from:

  if (c != ZACK) {
    ZSDATA (txbuf, 0, ZCRCE);
    goto gotack;
  }

...and various other places.

This bug might leak information to the receiver before sz finally crashes, so it likely has security impact. The same build of the package is present up to SLES 11 SP4.