From: "Geyslan G. Bem" <geys...@gmail.com>

In system_tr_open(), the filp->private_data can be assigned the 'dir'
variable even if it was freed. This is on the error path, and is
harmless because the error return code will prevent filp->private_data
from being used. But for correctness, we should not assign it to
a recently freed variable, as that can cause static tools to give
false warnings.

Also have both subsystem_open() and system_tr_open() return -ENODEV
if tracing has been disabled.

Link: 
http://lkml.kernel.org/r/1383764571-7318-1-git-send-email-geys...@gmail.com

Signed-off-by: Geyslan G. Bem <geys...@gmail.com>
Signed-off-by: Steven Rostedt <rost...@goodmis.org>
---
 kernel/trace/trace_events.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 043f833..f919a2e 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1062,6 +1062,9 @@ static int subsystem_open(struct inode *inode, struct 
file *filp)
        struct trace_array *tr;
        int ret;
 
+       if (tracing_is_disabled())
+               return -ENODEV;
+
        /* Make sure the system still exists */
        mutex_lock(&trace_types_lock);
        mutex_lock(&event_mutex);
@@ -1108,6 +1111,9 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
        struct trace_array *tr = inode->i_private;
        int ret;
 
+       if (tracing_is_disabled())
+               return -ENODEV;
+
        if (trace_array_get(tr) < 0)
                return -ENODEV;
 
@@ -1124,11 +1130,12 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
        if (ret < 0) {
                trace_array_put(tr);
                kfree(dir);
+               return ret;
        }
 
        filp->private_data = dir;
 
-       return ret;
+       return 0;
 }
 
 static int subsystem_release(struct inode *inode, struct file *file)
-- 
1.8.4.rc3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to