public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: maneesh@in.ibm.com
Cc: "Duetsch, Thomas  LDE1" <thomas.duetsch@siemens.com>,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	Patrick Mochel <mochel@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [SYSFS] Kernel Null pointer dereference in sysfs_readdir()
Date: Wed, 12 Jul 2006 16:28:38 -0400	[thread overview]
Message-ID: <1152736118.13382.6.camel@localhost.localdomain> (raw)
In-Reply-To: <20060712195700.GA1743@in.ibm.com>

On Thu, 2006-07-13 at 01:27 +0530, Maneesh Soni wrote:

> 
> sysfs_attach_attr() is called from sysfs_lookup() only, and which in turn
> is called under parent inode's i_mutex from VFS layer.

Ah, I didn't see the parent mutex lock.

Does sysfs support hard links?  Where an inode may belong to two
different dentrys?

> 
> But you did help in spotting a bug which could happen like this
> 
> i_mutext held
> sysfs_lookup()
> -->sysfs_attach_attr()
>    --> sysfs_create() fails
>    --> sd->s_dentry has a NULL d_inode
>    --> sysfs_put() frees the sysfs_dirent 
>    --> error returned to lookup
> i_mutex released
> 
> But the sysfs_dirent with NULL d_inode is never unlinked from 
> the parent sysfs_dirent. And later on this happens

But doesn't this only happen in case of no memory?

Thomas, is the system running low on memory?

> 
> vfs_readdir()
> i_mutex held
> -->sysfs_readdir()
>    --> trips on the freed sysfs_dirent with NULL inode.
> 
> I am not sure if it is possible for other thread to see the freed 
> sysfs_dirent and trip at sd->s_dentry->d_inode but the sysfs_dirent
> should have been unlinked from the parent sysfs_dirent's s_children list.
> 
> > Now the question is, is it safe to add the test for s_dentry->d_inode too.
> > I ask this because the s_dentry is in the process of being filled, and 
> > I don't know what effect this will have on what readdir wants.  I guess
> > it may be safe, so I'm giving this patch:
> > 
> > -- Steve
> > 
> > 
> > Description:
> > 
> > In the process of creating a sysfs attribute, we can have a state
> > where the sysfs descriptor can have a dentry with a NULL inode.
> > 
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > 
> > Index: linux-2.6.18-rc1/fs/sysfs/dir.c
> > ===================================================================
> > --- linux-2.6.18-rc1.orig/fs/sysfs/dir.c	2006-07-12 09:43:10.000000000 -0400
> > +++ linux-2.6.18-rc1/fs/sysfs/dir.c	2006-07-12 10:01:18.000000000 -0400
> > @@ -445,7 +445,7 @@ static int sysfs_readdir(struct file * f
> >  
> >  				name = sysfs_get_name(next);
> >  				len = strlen(name);
> > -				if (next->s_dentry)
> > +				if (next->s_dentry && next->s_dentry->d_inode)
> >  					ino = next->s_dentry->d_inode->i_ino;
> >  				else
> >  					ino = iunique(sysfs_sb, 2);
> > 
> 
> I think this patch only fixes the sympton. I have tried to keep the
> assumption of no negative dentries (dentries with NULL d_inode) valid 
> in sysfs. So, this does indicate a bug. 

Something else that might help is knowing what the other tasks where
doing at the time.  Thomas, do you also have the task dump?  You can
send that to me offline if you like.

-- Steve



  reply	other threads:[~2006-07-12 20:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-12 11:35 [SYSFS] Kernel Null pointer dereference in sysfs_readdir() Duetsch, Thomas  LDE1
2006-07-12 12:06 ` Steven Rostedt
2006-07-12 12:39   ` AW: " Duetsch, Thomas  LDE1
2006-07-12 14:06     ` Steven Rostedt
2006-07-12 19:57       ` Maneesh Soni
2006-07-12 20:28         ` Steven Rostedt [this message]
2006-07-12 20:39           ` Maneesh Soni
2006-07-13  2:59             ` Steven Rostedt
2006-07-12 19:58 ` Maneesh Soni

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=1152736118.13382.6.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=mingo@elte.hu \
    --cc=mochel@osdl.org \
    --cc=thomas.duetsch@siemens.com \
    /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