netdev - Re: [PATCH] q_tbf: Fix potential static-overflow in tbf_print

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240710160852.2e8e0177@hermes.local>
Date: Wed, 10 Jul 2024 16:08:52 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Maks Mishin <maks.mishinfz@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] q_tbf: Fix potential static-overflow in tbf_print_opt

On Sun,  7 Jul 2024 20:55:38 +0300
Maks Mishin <maks.mishinfz@...il.com> wrote:

> An element of array '&b1[0]' of size 64, declared at q_tbf.c:257,
> is accessed by an index with values in [0, 74] at q_tbf.c:279,
> which may lead to a buffer overflow.
> 
> Details: Format string: '%s/%u'. Size of buffer parameter is 63;
> Specifier '%u': min value '-2147483647' requires 10 character(s),
> max value '2147483647' requires 10 character(s), so the buffer needs
> enough space to receive 10 character(s).
> Size of the string except for specifiers is 1; Total maximum size is 74.
> 
> Found by RASU JSC.
> 
> Signed-off-by: Maks Mishin <maks.mishinFZ@...il.com>
> ---
>  tc/q_tbf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tc/q_tbf.c b/tc/q_tbf.c
> index 9356dfd2..b9f4191c 100644
> --- a/tc/q_tbf.c
> +++ b/tc/q_tbf.c
> @@ -254,7 +254,7 @@ static int tbf_print_opt(const struct qdisc_util *qu, FILE *f, struct rtattr *op
>  	double latency, lat2;
>  	__u64 rate64 = 0, prate64 = 0;
>  
> -	SPRINT_BUF(b1);
> +	char b1[74];

Looks correct, but wonder about other alternatives here.
  * printing buffer and cell log as combined value was a mistake.
    ideally, json should be one value per key, not something like "10K/4"
  * not sure how sprint_size() could ever get large enough with any realistic input.
    that makes this a theoretical problem.
  * the use of sprintf() in q_tbf.c is leftover historical bad C practice. Should be using snprintf always.
  * do not like introducing magic constant 74 here, why not just 2*SPRINT_BSIZE (ie 128)