| Message ID | 20240326174839.487582-1-kiryushin@ancud.ru (mailing list archive) |
|---|---|
| State | Superseded |
| Commit | 17bb5093493efb28ba57a97b2020acb4e2c2d639 |
| Headers | show |
| Series | rcu-tasks: Update show_rcu_tasks_trace_gp_kthread buffer size | expand |
On Tue, Mar 26, 2024 at 08:48:39PM +0300, Nikita Kiryushin wrote: > 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 <kiryushin@ancud.ru> Good catch! Applied for testing and further review. Thanx, Paul > --- > 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 <kiryushin@ancud.ru> 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 <kiryushin@ancud.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
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),
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 <kiryushin@ancud.ru> --- kernel/rcu/tasks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)