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

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:	Fri, 21 Nov 2014 12:42:29 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Manfred Spraul <manfred@...orfullife.com>,
	Davidlohr Bueso <davidlohr@...com>,
	Rafael Aquini <aquini@...hat.com>
Subject: Re: [PATCH] ipc,sem block sem_lock on sma->lock during sma
 initialization

On Fri, 21 Nov 2014 15:29:27 -0500 Rik van Riel <riel@...hat.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@...hat.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?
--
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/