lkml.org 
[lkml]   [2021]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectA missing security check bug in trace_format_open().
Dear maintainers,
hi, our team has found a missing check bug on Linux kernel v5.10.7
using static analysis. There is a missing security check bug in
trace_format_open() before calling function seq_open().

Function profile_open() checks security_locked_down() before the
critical function seq_open().
1. //check security_locked_down() ///////////////////////
2. static int profile_open(struct inode *inode, struct file *file)
3. {
4. int ret;
5. ret = security_locked_down(LOCKDOWN_TRACEFS);
6. if (ret)
7. return ret;
8. return seq_open(file, &profile_seq_op);
9. }

While trace_format_open() does not call this check,
security_locked_down(), and the parameters of calling seq_open() are
similar.
1. static int trace_format_open(struct inode *inode, struct file *file)
2. {
3. struct seq_file *m;
4. int ret;
5.
6. /* Do we want to hide event format files on tracefs lockdown? */
7.
8. ret = seq_open(file, &trace_format_seq_ops);
9. if (ret < 0)
10. return ret;
11.
12. m = file->private_data;
13. m->private = file;
14.
15. return 0;
16. }

Both functions are assigned to the same struct type and field.
1. static const struct file_operations kprobe_profile_ops = {
2. …
3. .open = profile_open,
4. …
5. };
6. static const struct file_operations ftrace_event_format_fops = {
7. …
8. .open = trace_format_open,
9. …
10. };


In conclusion, we assume that these functions work in the same way.
However, it is not appropriate that one function is called without
checking.

Thanks!


Best regards,
Jinmeng Zhou

\
 
 \ /
  Last update: 2021-05-21 16:32    [W:0.137 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site