From: Aurelien DARRAGON <adarragon@haproxy.com>
Date: Thu, 28 Nov 2024 11:03:17 +0000 (+0100)
Subject: BUG/MINOR: log: fix lf_text() behavior with empty string
X-Git-Tag: v3.2-dev1~85
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3e470471b7e0ec113807f6981699fda9538e7ffc;p=thirdparty%2Fhaproxy.git

BUG/MINOR: log: fix lf_text() behavior with empty string

As reported by Baptiste in GH #2797, if a logformat alias leveraging
lf_text() ends up printing nothing (empty string), the whole logformat
evaluation stops, leading garbage log message.

This bug was introduced during 3.0 cycle in fcb7e4b ("MINOR: log: add
lf_rawtext{_len}() functions"). At that time I genuinely thought that
if strlcpy2() returned 0, it was due to a lack of space, actually
forgetting that the function may simply be called with an empty string.

Because of that, lf_text() would return NULL if called with an empty
string, and since all lf_*() helpers are expected to return NULL on
error, this explains why the logformat evaluation immediately stops in
this case.

To fix the issue, let's simply consider that strlcpy2() returning 0 is
not an error, like it was already the case before.

It should be backported in 3.1 and 3.0 with fcb7e4b.
---

diff --git a/src/log.c b/src/log.c
index 4b6c29c195..ac94f5fbc7 100644
--- a/src/log.c
+++ b/src/log.c
@@ -2411,8 +2411,6 @@ static inline char *_lf_text_len(char *dst, const char *src,
 			if (++len > size)
 				len = size;
 			len = strlcpy2(dst, src, len);
-			if (len == 0)
-				return NULL;
 		}
 		dst += len;
 		size -= len;