lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 29 Mar 2010 22:22:38 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Greg KH <greg@...ah.com>, Randy Dunlap <randy.dunlap@...cle.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	stable <stable@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org, Eric Dumazet <dada1@...mosbay.com>,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [stable] [PATCH 2.6.29.x - 2.6.31.1] module: fix
	__module_ref_addr()

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Mon, 2010-03-29 at 14:07 -0700, Greg KH wrote:
> > On Mon, Mar 29, 2010 at 04:09:46PM -0400, Mathieu Desnoyers wrote:
> > > * Steven Rostedt (rostedt@...dmis.org) wrote:
> > > > This patch does not apply to 2.6.34-rc, and the code in upstream looks
> > > > to have been fixed. Should this go to stable?
> > > 
> > > Yes. 2.6.34-rc does not have this issue anymore, but the patch is needed in
> > > -stable.
> > 
> > Why is this not in .34-rc2?  Can you find the specific patch in Linus's
> > tree that solves this and let stable@...nel.org know about it?
> > 
> 
> Looks like it was this commit:
> 
> commit e1783a240f491fb233f04edc042e16b18a7a79ba
> Author: Christoph Lameter <cl@...ux-foundation.org>
> Date:   Tue Jan 5 15:34:50 2010 +0900
> module: Use this_cpu_xx to dynamically allocate counters
> 
> Mathieu's fix was:
> 
> -   return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> +   return (local_t *) per_cpu_ptr(mod->refptr, cpu);
> 
> As Mathieu states in his change log, the bug is that the mod->refptr is
> outside the assembly obfuscation of the per_cpu_offset(). This allows
> the compiler to optimize and cause a NULL pointer dereference with the
> manipulation of per cpu data.
> 
> Christoph Lameter's change fixes this bug as a side effect:
> 
> -static inline local_t *__module_ref_addr(struct module *mod, int cpu)
> -{
> -#ifdef CONFIG_SMP
> -       return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> -#else
> -       return &mod->ref;
> -#endif
> -}
> -
>  /* Sometimes we know we already have a refcount, and it's easier not
>     to handle the error case (which only happens with rmmod --wait). */
>  static inline void __module_get(struct module *module)
>  {
>         if (module) {
> -               unsigned int cpu = get_cpu();
> -               local_inc(__module_ref_addr(module, cpu));
> +               preempt_disable();
> +               __this_cpu_inc(module->refptr->count);
>                 trace_module_get(module, _THIS_IP_,
> -                                local_read(__module_ref_addr(module, cpu)));
> -               put_cpu();
> +                                __this_cpu_read(module->refptr->count));
> +               preempt_enable();
>         }
>  }
> 
> By removing the buggy code all together.

Exactly. Steven has beaten me on the start line on this one. ;)

Thanks,

Mathieu

> 
> -- Steve
> 
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists