Error while reading from Writer: bufio.Scanner: token too long

[kke]

This happens if you try to log something that is longer than 64kb without newlines through something like cmd.Stdout = logrus.Writer().

This can cause a denial of service in some cases.

The culprit is here:
https://github.com/sirupsen/logrus/blob/master/writer.go#L58-L59

Maybe it needs a custom scanner.Split(...) function or some other invention.

[ozfive]

The way to do this would be to modify func (entry *Entry) writerScanner(reader *io.PipeReader, printFunc func(args ...interface{})) in writer.go with a custom split function to split the input into chunks of up to 64kb

// writerScanner scans the input from the given reader and writes it to the logger using the specified print function.
// It splits the input into chunks of up to 64KB to avoid buffer overflows.
func (entry *Entry) writerScanner(reader *io.PipeReader, printFunc func(args ...interface{})) {
	scanner := bufio.NewScanner(reader)

	// Set the buffer size to the maximum token size to avoid buffer overflows
	scanner.Buffer(make([]byte, bufio.MaxScanTokenSize), bufio.MaxScanTokenSize)

	// Define a split function to split the input into chunks of up to 64KB
	chunkSize := 64 * 1024 // 64KB
	splitFunc := func(data []byte, atEOF bool) (int, []byte, error) {
		if len(data) > chunkSize {
			return chunkSize, data[:chunkSize], nil
		}
		return 0, nil, nil
	}

	// Use the custom split function to split the input
	scanner.Split(splitFunc)

	// Scan the input and write it to the logger using the specified print function
	for scanner.Scan() {
		printFunc(strings.TrimRight(scanner.Text(), "\r\n"))
	}

	// If there was an error while scanning the input, log an error
	if err := scanner.Err(); err != nil {
		entry.Errorf("Error while reading from Writer: %s", err)
	}

	// Close the reader when we are done
	reader.Close()
}

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[kke]

Still relevant

[brahads]

I see that there were a couple of suggestions for this issue. Do we have a timeline when this issue might be fixed in this package?

[30787]

@kke @sirupsen Can you confirm which version has the vulnerability #1370 remediated? v1.9.2 shows this vulnerability in twistlock scan results for sles12sp5 basesd container image.

[kke]

Fixed in v1.9.3 via #1384