linux-kernel - RE: [PATCH] Staging: memrar: Moved memrar_allocator struct into memrar

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] [day] [month] [year] [list]

Message-ID: <A5FE05C4C76E4C4CAB15D9962B96FC950CEA181645@orsmsx510.amr.corp.intel.com>
Date:	Thu, 24 Jun 2010 10:46:41 -0700
From:	"Othman, Ossama" <ossama.othman@...el.com>
To:	Henri Häkkinen <henrih81@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	"gregkh@...e.de" <gregkh@...e.de>,
	Matti Lammi <mattij.lammi@...il.com>,
	"randy.dunlap@...cle.com" <randy.dunlap@...cle.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] Staging: memrar: Moved memrar_allocator struct into
 memrar_allocator.c

Hi,

> >> size_t memrar_allocator_largest_free_area(struct memrar_allocator
> *allocator)
> >> {
> >> -	if (allocator == NULL)
> >> -		return 0;
> >> -	return allocator->largest_free_area;
> >> +	size_t tmp = 0;
> >> +
> >> +	if (allocator != NULL) {
> >> +		mutex_lock(&allocator->lock);
> >> +		tmp = allocator->largest_free_area;
> >> +		mutex_unlock(&allocator->lock);
> >
> > This doesn't seem to make any sense (in either version). The moment
> you
> > drop the lock the value in "tmp" becomes stale as the allocator could
> > change it. ?
> >
> 
> The idea was proposed by Ossama Othman in his earlier reply.

:-) 

[OO] > > Certainly the allocator->largest_free_area value could be updated
> after the lock is released and by the time it is returned to the user
> (for statistical purposes), but at least the internal allocator state
> would remain consistent in the presences of multiple threads.

My suggestion focused solely on hiding the allocator lock from the caller.  The TOCTOU race I alluded to above exists in the current version of the code, and was not introduced with the change I proposed to your patch.

HTH,
-Ossama
--
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/