Commit 5dbeb56
committed
tracing: Initialize scratch_size to zero to prevent UB
In allocate_trace_buffer() the following code:
buf->buffer = ring_buffer_alloc_range(size, rb_flags, 0,
tr->range_addr_start,
tr->range_addr_size,
struct_size(tscratch, entries, 128));
tscratch = ring_buffer_meta_scratch(buf->buffer, &scratch_size);
setup_trace_scratch(tr, tscratch, scratch_size);
Has undefined behavior if ring_buffer_alloc_range() fails because
"scratch_size" is not initialize. If the allocation fails, then
buf->buffer will be NULL. The ring_buffer_meta_scratch() will return
NULL immediately if it is passed a NULL buffer and it will not update
scratch_size. Then setup_trace_scratch() will return immediately if
tscratch is NULL.
Although there's no real issue here, but it is considered undefined
behavior to pass an uninitialized variable to a function as input, and
UBSan may complain about it.
Just initialize scratch_size to zero to make the code defined behavior and
a little more robust.
Link: https://lore.kernel.org/all/[email protected]/
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>1 parent f00c920 commit 5dbeb56
1 file changed
+1
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
9398 | 9398 | | |
9399 | 9399 | | |
9400 | 9400 | | |
9401 | | - | |
| 9401 | + | |
9402 | 9402 | | |
9403 | 9403 | | |
9404 | 9404 | | |
| |||
0 commit comments