From: Chris Wright <chrisw@sous-sol.org>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
torvalds@osdl.org, akpm@osdl.org, alan@lxorguk.ukuu.org.uk,
Oleg Drokin <green@linuxhacker.ru>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: [PATCH 05/13] [PATCH] Missed error checking for intents filp in open_namei().
Date: Tue, 20 Jun 2006 00:00:05 -0700 [thread overview]
Message-ID: <20060620114708.454448000@sous-sol.org> (raw)
In-Reply-To: 20060620114527.934114000@sous-sol.org
[-- Attachment #1: missed-error-checking-for-intent-s-filp-in-open_namei.patch --]
[-- Type: text/plain, Size: 2006 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oleg Drokin <green@linuxhacker.ru>
It seems there is error check missing in open_namei for errors returned
through intent.open.file (from lookup_instantiate_filp).
If there is plain open performed, then such a check done inside
__path_lookup_intent_open called from path_lookup_open(), but when the open
is performed with O_CREAT flag set, then __path_lookup_intent_open is only
called with LOOKUP_PARENT set where no file opening can occur yet.
Later on lookup_hash is called where exact opening might take place and
intent.open.file may be filled. If it is filled with error value of some
sort, then we get kernel attempting to dereference this error value as
address (and corresponding oops) in nameidata_to_filp() called from
filp_open().
While this is relatively simple to workaround in ->lookup() method by just
checking lookup_instantiate_filp() return value and returning error as
needed, this is not so easy in ->d_revalidate(), where we can only return
"yes, dentry is valid" or "no, dentry is invalid, perform full lookup
again", and just returning 0 on error would cause extra lookup (with
potential extra costly RPCs).
So in short, I believe that there should be no difference in error handling
for opening a file and creating a file in open_namei() and propose this
simple patch as a solution.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/namei.c | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-2.6.16.21.orig/fs/namei.c
+++ linux-2.6.16.21/fs/namei.c
@@ -1628,6 +1628,12 @@ do_last:
goto exit;
}
+ if (IS_ERR(nd->intent.open.file)) {
+ mutex_unlock(&dir->d_inode->i_mutex);
+ error = PTR_ERR(nd->intent.open.file);
+ goto exit_dput;
+ }
+
/* Negative dentry, just create the file */
if (!path.dentry->d_inode) {
if (!IS_POSIXACL(dir->d_inode))
--
next prev parent reply other threads:[~2006-06-20 11:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 11:45 [PATCH 00/13] -stable review Chris Wright
2006-06-20 7:00 ` [PATCH 01/13] USB: Whiteheat: fix firmware spurious errors Chris Wright
2006-06-20 7:00 ` [PATCH 02/13] SPARC64: Fix D-cache corruption in mremap Chris Wright
2006-06-20 7:00 ` [PATCH 03/13] SPARC64: Respect gfp_t argument to dma_alloc_coherent() Chris Wright
2006-06-20 7:00 ` [PATCH 04/13] SPARC64: Fix missing fold at end of checksums Chris Wright
2006-06-20 7:00 ` Chris Wright [this message]
2006-06-20 7:00 ` [PATCH 06/13] tmpfs: time granularity fix for [acm]time going backwards Chris Wright
2006-06-20 7:00 ` [PATCH 07/13] SERIAL: PARPORT_SERIAL should depend on SERIAL_8250_PCI Chris Wright
2006-06-29 17:31 ` Michael Tokarev
2006-06-29 17:37 ` Russell King
2006-06-29 18:12 ` Chris Wright
2006-06-29 18:17 ` Michael Tokarev
2006-06-20 7:00 ` [PATCH 08/13] fs/namei.c: Call to file_permission() under a spinlock in do_lookup_path() Chris Wright
2006-06-20 7:00 ` [PATCH 09/13] JFS: Fix multiple errors in metapage_releasepage Chris Wright
2006-06-20 7:00 ` [PATCH 10/13] scsi_lib.c: properly count the number of pages in scsi_req_map_sg() Chris Wright
2006-06-20 7:00 ` [PATCH 11/13] I2O: Bugfixes to get I2O working again Chris Wright
2006-06-20 7:00 ` [PATCH 12/13] powernow-k8 crash workaround Chris Wright
2006-06-20 7:00 ` [PATCH 13/13] NTFS: Critical bug fix (affects MIPS and possibly others) Chris Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060620114708.454448000@sous-sol.org \
--to=chrisw@sous-sol.org \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=green@linuxhacker.ru \
--cc=gregkh@suse.de \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=tytso@mit.edu \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox