Re: [PATCH] ipc,sem block sem_lock on sma->lock during sma initialization

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 21 Nov 2014 15:29:27 -0500 Rik van Riel <riel@redhat.com> wrote:

> On 11/21/2014 03:09 PM, Andrew Morton wrote:
> > On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel <riel@redhat.com>
> > wrote:
> > 
> >> When manipulating just one semaphore with semop, sem_lock only
> >> takes that single semaphore's lock. This creates a problem during
> >> initialization of the semaphore array, when the data structures
> >> used by sem_lock have not been set up yet. The sma->lock is
> >> already held by newary, and we just have to make sure everything
> >> else waits on that lock during initialization.
> >> 
> >> Luckily it is easy to make sem_lock wait on the sma->lock, by
> >> pretending there is a complex operation in progress while the sma
> >> is being initialized.
> >> 
> >> The newary function already zeroes sma->complex_count before
> >> unlocking the sma->lock.
> > 
> > What are the runtime effects of the bug?
> > 
> 
> NULL pointer dereference in spin_lock from sem_lock,
> if it is called before sma->sem_base has been pointed
> somewhere valid.

Help us out here.  People need to use this description to work out
which kernel versions need the patch and whether to backport the fix
into their various kernels.  Other people will be starting at this
changelog wondering "will this fix the bug my customer has reported".

Is there some bug report people can look at?

What userspace actions trigger this bug?