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] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Mar 2024 16:28:38 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Nikita Kiryushin <kiryushin@...ud.ru>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, Frederic Weisbecker
 <frederic@...nel.org>, Neeraj Upadhyay <quic_neeraju@...cinc.com>, Joel
 Fernandes <joel@...lfernandes.org>, Josh Triplett <josh@...htriplett.org>,
 Boqun Feng <boqun.feng@...il.com>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Lai Jiangshan <jiangshanlai@...il.com>,
 Zqiang <qiang.zhang1211@...il.com>, rcu@...r.kernel.org,
 linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH] rcu-tasks: Update show_rcu_tasks_trace_gp_kthread
 buffer size

On Tue, 26 Mar 2024 22:55:29 +0300
Nikita Kiryushin <kiryushin@...ud.ru> wrote:

> On 3/26/24 22:22, Steven Rostedt wrote:
> > Why 87? as it's not even word size, and this is on the stack.
> >  
> Got 87 as maximal used buffer length (result of
> sprintf(buf, "N%lu h:%lu/%lu/%lu",
>          (unsigned long int) -1,
>          (unsigned long int) -1,
>          (unsigned long int) -1,
>          (unsigned long int) -1);
> +1 for terminator.
> 
> Is word-size alignment a thing in this case? I thought that char buffers
> are ok to be aligned by 1?

Because it's on the stack, which will likely reserve data in word size.

Thus, buf[87] reserves as much data on the stack as buf[88].


> > Better yet, why not just use snprintf()?
> >  
> Seems like a better idea indeed, as if fixes overflows for unpractical cases,
> without added overhead to common cases. The only concern is possible truncation
> of data, that may break some automation (if output is parsed by someone,
> without accounting on it being cut, who knows). But again, it is for pretty unpractical
> values.
> 
> Will make a v2 patch with snprintf() with buffer length.
> 
> Genuinely look forward to being educated about aspects of aligning array sizes, as
> I do not really understand the limitations.

It's because it's on the stack, but it's always good to align. For
instance, kmalloc() will allocate things in 32 byte chunks.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ