Description
We've found using a header/footer construct in fixedlength2 causes a buffer overflow within go-corelib.
To reproduce, construct an input such as:
<REC_HDR>
<Lots of lines here...
...
...
...
<REC_FTR>
Tracing into go-corelib it looks like there's a default buffer size of 4096, so the input record needs to be greater than that to reproduce.
It looks ilke reader.lineBuf[i] is getting set to a pointer inside the buffer. When the buffer wraps, the lineBuf gets corrupted.
See attached files to reproduce. This occurs (for these data), when r.linesRead is 118 (or shortly thereafter).
I think something like this could fix it, but not sure if it's the optimal solution (this works though...).
This is in: fileformat/flatfile/fixedlength/reader.go
func (r *reader) readLine() error {
for {
// note1: ios.ByteReadLine returns a ln with trailing '\n' (and/or '\r') dropped.
// note2: ios.ByteReadLine won't return io.EOF if ln returned isn't empty.
b, err := ios.ByteReadLine(r.r)
switch {
case err == io.EOF:
return io.EOF
case err != nil:
return ErrInvalidFixedLength(r.fmtErrStr(r.linesRead+1, err.Error()))
}
r.linesRead++
if len(b) > 0 {
// Copy data out of the buffer into our local line buffer
lineCopy := make([]byte, len(b))
_ = copy(lineCopy, b)
r.linesBuf = append(r.linesBuf, line{lineNum: r.linesRead, b: lineCopy})
// This causes buffer overruns to appear in local data:
// r.linesBuf = append(r.linesBuf, line{lineNum: r.linesRead, b: b})
return nil
}
}
}
Cheers,
Paul