| Message ID | 20230704102706eucms1p30d7ecdcc287f46ad67679fc8491b2e0f@eucms1p3 (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 02b0095e2fbbc060560c1065f86a211d91e27b26 |
| Delegated to: | Masami Hiramatsu |
| Headers | show |
| Series | [v2] trace: fix null pointer dereference in tracing_err_log_open() | expand |
On Tue, 04 Jul 2023 12:27:06 +0200 Mateusz Stachyra <m.stachyra@samsung.com> wrote: > Fix an issue in function 'tracing_err_log_open'. > The function doesn't call 'seq_open' if file is opened only with > write permissions, which results in 'file->private_data' being left at null. > If we then use 'lseek' on that opened file, 'seq_lseek' dereferences > 'file->private_data' in 'mutex_lock(&m->lock)', resulting in a Kernel panic. > Writing to this node requires root privilages, therefore this bug > has very little security impact. > > Tracefs node: /sys/kernel/tracing/error_log > > Example Kernel panic: > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 > Call trace: > mutex_lock+0x30/0x110 > seq_lseek+0x34/0xb8 > __arm64_sys_lseek+0x6c/0xb8 > invoke_syscall+0x58/0x13c > el0_svc_common+0xc4/0x10c > do_el0_svc+0x24/0x98 > el0_svc+0x24/0x88 > el0t_64_sync_handler+0x84/0xe4 > el0t_64_sync+0x1b4/0x1b8 > Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) > ---[ end trace 561d1b49c12cf8a5 ]--- > Kernel panic - not syncing: Oops: Fatal exception > Good catch! This looks good to me. Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Thanks! > Signed-off-by: Mateusz Stachyra <m.stachyra@samsung.com> > Suggested-by: Steven Rostedt <rostedt@goodmis.org> > --- > kernel/trace/trace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index b04f52e7c..4529e264c 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -8146,7 +8146,7 @@ static const struct file_operations tracing_err_log_fops = { > .open = tracing_err_log_open, > .write = tracing_err_log_write, > .read = seq_read, > - .llseek = seq_lseek, > + .llseek = tracing_lseek, > .release = tracing_err_log_release, > }; > > -- > 2.25.1
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b04f52e7c..4529e264c 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -8146,7 +8146,7 @@ static const struct file_operations tracing_err_log_fops = { .open = tracing_err_log_open, .write = tracing_err_log_write, .read = seq_read, - .llseek = seq_lseek, + .llseek = tracing_lseek, .release = tracing_err_log_release, };
Fix an issue in function 'tracing_err_log_open'. The function doesn't call 'seq_open' if file is opened only with write permissions, which results in 'file->private_data' being left at null. If we then use 'lseek' on that opened file, 'seq_lseek' dereferences 'file->private_data' in 'mutex_lock(&m->lock)', resulting in a Kernel panic. Writing to this node requires root privilages, therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ end trace 561d1b49c12cf8a5 ]--- Kernel panic - not syncing: Oops: Fatal exception Signed-off-by: Mateusz Stachyra <m.stachyra@samsung.com> Suggested-by: Steven Rostedt <rostedt@goodmis.org> --- kernel/trace/trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)