There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.
Update used buffer size for maximum needed size for
current format string.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs")
Signed-off-by: Nikita Kiryushin <[email protected]>
---
kernel/rcu/tasks.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
index 147b5945d67a..13ac514489c0 100644
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -1992,7 +1992,7 @@ static int __init rcu_spawn_tasks_trace_kthread(void)
#if !defined(CONFIG_TINY_RCU)
void show_rcu_tasks_trace_gp_kthread(void)
{
- char buf[64];
+ char buf[87];
sprintf(buf, "N%lu h:%lu/%lu/%lu",
data_race(n_trc_holdouts),
--
2.34.1
On Tue, 26 Mar 2024 20:48:39 +0300
Nikita Kiryushin <[email protected]> wrote:
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> index 147b5945d67a..13ac514489c0 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -1992,7 +1992,7 @@ static int __init rcu_spawn_tasks_trace_kthread(void)
> #if !defined(CONFIG_TINY_RCU)
> void show_rcu_tasks_trace_gp_kthread(void)
> {
> - char buf[64];
> + char buf[87];
Why 87? as it's not even word size, and this is on the stack.
>
> sprintf(buf, "N%lu h:%lu/%lu/%lu",
Better yet, why not just use snprintf()?
snprintf(buf, 64, "N%lu h:%lu/%lu/%lu",
-- Steve
> data_race(n_trc_holdouts),
> --
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?
> 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.
Thanks!
On Tue, 26 Mar 2024 22:55:29 +0300
Nikita Kiryushin <[email protected]> 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
There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.
Use snprintf() with buffer size instead of sprintf().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs")
Signed-off-by: Nikita Kiryushin <[email protected]>
---
v2: Use snprintf() as
Steven Rostedt <[email protected]> suggested.
kernel/rcu/tasks.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
index 147b5945d67a..963ecae3c8e6 100644
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -1994,7 +1994,7 @@ void show_rcu_tasks_trace_gp_kthread(void)
{
char buf[64];
- sprintf(buf, "N%lu h:%lu/%lu/%lu",
+ snprintf(buf, ARRAY_SIZE(buf), "N%lu h:%lu/%lu/%lu",
data_race(n_trc_holdouts),
data_race(n_heavy_reader_ofl_updates),
data_race(n_heavy_reader_updates),
--
2.34.1