From: Stephen Hemminger <stephen@networkplumber.org>
To: Pedro Tammela <pctammela@mojatatu.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH iproute2 1/2] color: use empty format string instead of NULL in vfprintf
Date: Mon, 22 Jan 2024 16:43:36 -0800 [thread overview]
Message-ID: <20240122164336.12119994@hermes.local> (raw)
In-Reply-To: <20240122210546.3423784-2-pctammela@mojatatu.com>
On Mon, 22 Jan 2024 18:05:45 -0300
Pedro Tammela <pctammela@mojatatu.com> wrote:
> NULL is passed in the format string when nothing is to be printed.
> This is commonly done in the print_bool function when a flag is false.
> Glibc seems to handle this case nicely but for musl it will cause a
> segmentation fault.
>
> The following is an example of one crash in musl based systems/containers:
> tc qdisc add dev dummy0 handle 1: root choke limit 1000 bandwidth 10000
> tc qdisc replace dev dummy0 handle 1: root choke limit 1000 bandwidth 10000 min 100
> tc qdisc show dev dummy0
>
> Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
> ---
> lib/color.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Wouldn't it be simpler to just add a short circuit check.
This would fix the color case as well.
diff --git a/lib/color.c b/lib/color.c
index 59976847295c..cd0f9f7509b5 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -140,6 +140,9 @@ int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...)
int ret = 0;
va_list args;
+ if (fmt == NULL)
+ return 0;
+
va_start(args, fmt);
if (!color_is_enabled || attr == COLOR_NONE) {
next prev parent reply other threads:[~2024-01-23 0:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 21:05 [PATCH iproute2 0/2] some musl fixes Pedro Tammela
2024-01-22 21:05 ` [PATCH iproute2 1/2] color: use empty format string instead of NULL in vfprintf Pedro Tammela
2024-01-23 0:43 ` Stephen Hemminger [this message]
2024-01-23 1:16 ` Pedro Tammela
2024-01-22 21:05 ` [PATCH iproute2 2/2] bpf: include libgen.h for basename Pedro Tammela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240122164336.12119994@hermes.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
--cc=pctammela@mojatatu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox