linux-kernel - RE: [PATCH 2/2] Staging: memrar: Fixed 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]

Date:	Thu, 24 Jun 2010 10:36:10 -0700
From:	"Othman, Ossama" <ossama.othman@...el.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"henuxd@...il.com" <henuxd@...il.com>
CC:	"gregkh@...e.de" <gregkh@...e.de>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	"mattij.lammi@...il.com" <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 2/2] Staging: memrar: Fixed memrar_handler.c

Hi Alan,

> >  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. ?

Agreed, but I don't think there's anything we can do about it with the current interface.  We will always have a time-of-check-time-of-use TOCTOU race with this function as it stands.  I pointed out the issue in my response to Henri as well, but I focused more on hiding the lock from the caller.  The TOCTOU race exists in both versions, i.e. the old code and proposed new code.  The value returned from this function in this particular case will ultimately be passed to the user when the user issues a RAR_HANDLER_STAT ioctl to the /dev/memrar device.  For the most part, this function is only used for debugging.  It is not needed for general operation of the memrar_allocator or the memrar_handler (/dev/memrar).

-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/