linux-kernel - Re: Anonymous inode cleanup?

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]

Message-ID: <20151113063103.GO22011@ZenIV.linux.org.uk>
Date:	Fri, 13 Nov 2015 06:31:04 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Rajat Jain <rajatxjain@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Anonymous inode cleanup?

On Thu, Nov 12, 2015 at 09:43:00PM -0800, Rajat Jain wrote:
> Hello,
> 
> I'm writing a module that wants to get anonymous fd [using
> anon_inode_getfd()] and my code looks like this:
> 
> fd = anon_inode_getfd(...)
> if (fd < 0)
>     return -EINVAL;
> 
> if (foobar_fail()) {
>     /* undo everything */
>     return -EINVAL;
> }
> 
> My question is that in case of a failure after the anon_inode_getfd(),
> I want to cleanup and undo whatever needs to be done w.r.t. anodnymous
> fd I just allocated. (May be put a reference, or return the fd to the
> free pool or whatever). Can some one please let me know what cleanup
> needs to be done?
> 
> However neither I see a cleanup function, nor I see any of the drivers
> attempting
> to free the fd in case of failure.

You can't.  As soon as it's in descriptor table, you'd better be *done*
with it.  No "I need more setup done", no "I just need to do one final
check" - the moment it hits the descriptor table, another thread might
be issuing syscalls on it.  Including dup2(), so there's no way to take
it back.  Moreover, another thread might've done dup2() over your
descriptor, so you can't even decide to close the one you'd just installed.
Yes, even in cases when the failed action would be to report the resulting
descriptor to userland.  Generally you should try to return descriptors to
userland only via the syscall return value.

_If_ you are returning them via a sucky API, the right sequence is
	reserve the descriptor(s)
	set the file(s) up
	fill whatever structure you'll be using to report descriptors to
userland and copy it to userland memory
	use fd_install() to put files into descriptor table.

See e.g. fs/pipe.c and look for pipe2 in there for example of dealing with
such APIs.

"Set the file up" primitive in case of anon_inode is anon_inode_getfile();
grep and you shall see...

Again, fd_install() is the equivalent of hitting "send" - there's no way
to make what you've published disappear.  It's the point of no return.
--
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/