in_syslog: fix null byte handling in message parsing

[niedbalski]

Description

Null bytes in syslog messages are incorrectly treated as message delimiters, causing message fragmentation and parser errors. This violates RFC 6587 section 3.4.1 which specifies that for octet-counting framing, only the calculated length determines message boundaries, and section 3.4.2 which specifies newline as the delimiter for non-transparent framing.

Current behaviour

When a syslog message contains a null byte, the parser treats it as a message boundary:

[ warn] [input:syslog:syslog.0] error parsing log message with parser 'syslog-rfc5424'
[debug] [input:syslog:syslog.0] unparsed log message:  byte

• Message gets split at the null byte position
• First part gets processed normally
• Second part fails to parse (invalid syslog format)
• Results in parser errors and log spam

Expected behaviour

Null bytes should be preserved in message content and not treated as delimiters:

• Complete message gets processed as single unit
• Null byte preserved in final parsed message
• No parser errors or message fragmentation

Changes

Modified syslog_prot_process() to skip null bytes when scanning for message boundaries, only treating newlines as delimiters per RFC 6587 section 3.4.2.

Fixes #2741

[cosmo0920]

only the calculated length determines message boundaries, and section 3.4.2 which specifies newline as the delimiter for non-transparent framing.

Is that true?
I mean the section 3.4.2 says:

The TRAILER has usually been a single character and most often is ASCII LF (%d10). However, other characters have also been seen, with ASCII NUL (%d00) being a prominent example. Some devices have also been seen to emit a two-character TRAILER, which is usually CR and LF.

So, non-transparent framing messages contain null byte as a one of the delimiter. So, it's still required to handle null-byte should be treated as a delimiter.
Should we check the null-byte as a termination of the non-framing messages? And then, this change is still valid in that case?

[niedbalski]

only the calculated length determines message boundaries, and section 3.4.2 which specifies newline as the delimiter for non-transparent framing.

Is that true? I mean the section 3.4.2 says:

The TRAILER has usually been a single character and most often is ASCII LF (%d10). However, other characters have also been seen, with ASCII NUL (%d00) being a prominent example. Some devices have also been seen to emit a two-character TRAILER, which is usually CR and LF.

So, non-transparent framing messages contain null byte as a one of the delimiter. So, it's still required to handle null-byte should be treated as a delimiter. Should we check the null-byte as a termination of the non-framing messages? And then, this change is still valid in that case?

@cosmo0920

This PR is controversial and open to debate. My interpretation here is If we're using non-transparent framing null bytes could be treated as delimiters, but If a message legitimately contains a null byte within its content (not as a
terminator), it shouldn't be split there. Then, if we are using octect counters, null bytes should not be treated as delimiters.

Perhaps the best option here is to (need your feedback)

1. Handle null bytes as delimiters when they're at the end of a complete syslog message
2. Skips null bytes when they're embedded within message content

[cosmo0920]

Perhaps the best option here is to (need your feedback)

1. Handle null bytes as delimiters when they're at the end of a complete syslog message

2. Skips null bytes when they're embedded within message content

I'd like to choose 1. behavior. Behavior 2. should be chosen but we need to refer the octet count and to use the count for determinating that a null-byte should be able to skip / safe to skip within the non-framing messages.