func->new_func has been accessed after rcu_read_unlock() in klp_ftrace_handler()
and therefore the access was not protected.
Signed-off-by: Petr Mladek <[email protected]>
---
kernel/livepatch/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index ff7f47d026ac..cde66192e20e 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -314,12 +314,12 @@ static void notrace klp_ftrace_handler(unsigned long ip,
rcu_read_lock();
func = list_first_or_null_rcu(&ops->func_stack, struct klp_func,
stack_node);
- rcu_read_unlock();
-
if (WARN_ON_ONCE(!func))
- return;
+ goto unlock;
klp_arch_set_pc(regs, (unsigned long)func->new_func);
+unlock:
+ rcu_read_unlock();
}
static int klp_disable_func(struct klp_func *func)
--
1.8.5.6
On Wed, 18 Feb 2015, Petr Mladek wrote:
> func->new_func has been accessed after rcu_read_unlock() in klp_ftrace_handler()
> and therefore the access was not protected.
>
> Signed-off-by: Petr Mladek <[email protected]>
> ---
> kernel/livepatch/core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index ff7f47d026ac..cde66192e20e 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -314,12 +314,12 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> rcu_read_lock();
> func = list_first_or_null_rcu(&ops->func_stack, struct klp_func,
> stack_node);
> - rcu_read_unlock();
> -
> if (WARN_ON_ONCE(!func))
> - return;
> + goto unlock;
>
> klp_arch_set_pc(regs, (unsigned long)func->new_func);
> +unlock:
> + rcu_read_unlock();
This can't hurt, even though the only scenario where this could in theory
trigger as a bug (module removal) is non-issue now.
But I'd like to take it nevertheless ... Seth, Josh?
Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, Feb 21, 2015 at 12:29:30AM +0100, Jiri Kosina wrote:
> On Wed, 18 Feb 2015, Petr Mladek wrote:
>
> > func->new_func has been accessed after rcu_read_unlock() in klp_ftrace_handler()
> > and therefore the access was not protected.
> >
> > Signed-off-by: Petr Mladek <[email protected]>
> > ---
> > kernel/livepatch/core.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index ff7f47d026ac..cde66192e20e 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -314,12 +314,12 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> > rcu_read_lock();
> > func = list_first_or_null_rcu(&ops->func_stack, struct klp_func,
> > stack_node);
> > - rcu_read_unlock();
> > -
> > if (WARN_ON_ONCE(!func))
> > - return;
> > + goto unlock;
> >
> > klp_arch_set_pc(regs, (unsigned long)func->new_func);
> > +unlock:
> > + rcu_read_unlock();
>
> This can't hurt, even though the only scenario where this could in theory
> trigger as a bug (module removal) is non-issue now.
>
> But I'd like to take it nevertheless ... Seth, Josh?
Acked-by: Josh Poimboeuf <[email protected]>
--
Josh
On Wed, 18 Feb 2015, Petr Mladek wrote:
> func->new_func has been accessed after rcu_read_unlock() in klp_ftrace_handler()
> and therefore the access was not protected.
>
> Signed-off-by: Petr Mladek <[email protected]>
Applied to for-3.20/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs