Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-10 Thread Maneesh Soni 
On Wed, Aug 10, 2005 at 03:35:53PM -0700, Greg KH wrote:
> On Wed, Aug 10, 2005 at 03:36:36PM +0530, Maneesh Soni wrote:
> > On Wed, Aug 10, 2005 at 04:26:51PM +1000, Keith Owens wrote:
> > > FYI, the intermittent free after use in sysfs is still there in
> > > 2.6.13-rc6.
> > > 
> > 
> > The race condition is known here. It is some thing in the upper layer. 
> > In this case "driver/base/class.c" which frees the kobject's attributes 
> > even if there are live references to kobject.
> > 
> > 
> > open sysfs file unregister class device
> > sysfs_open_file()   class_device_del()
> >   -> takes a ref on kobject   -> kfree attribute struct
> >  -> accesses attributes   -> kobject_del()
> >   -> kref_put() 
> > close sysfs file  
> > sysfs_release() 
> >   -> acesses attributes using s_element
> >   -> drops ref to kobject
> > 
> > Solution could be either we have reference counting for attributes also
> > or keep attributes alive till the last reference to the kobject. Both these
> > needs changes in the driver core.
> > 
> > Greg, will the following patch make sense? This postpones the kfree() of
> > devt_attr till class_dev_release() is called. 
> 
> Yes, that patch looks good, if you fix up the space vs. tabs issue :)
> 

yuk.. sorry for that.. I corrected that now.

> But will that really fix this race?  I was under the impression the oops
> didn't come from trying to access the devt_attr, but the sysfs s_element
> pointer?

I am not able to recreate the race with or without the patch though. As per
the stack traces, and the debug messages from antother thread also,
I could see that it is use after free for attribute structure. s_element
is a pointer to the attribute structure in case of sysfs "files". Most of
the times this attribute structure is not allocated/freed dynamically unlike
/sys/class/vc/vcs*/dev, so we don't see any crashes.


> > Please check this patch out, if this helps or not.
> 
> I'd be interested in seeing if this fixes it.
> 

I just cc-ed others also who reported similar oops.

Thanks
Maneesh




o following patch moves the code to free devt_attr from class_device_del()
  to class_dev_release() which is called after the last reference to the
  corresponding kobject() is gone. This allows to keep the devt_attr 
  alive while the corresponding sysfs file is open.

Signed-off-by: Maneesh Soni <[EMAIL PROTECTED]>
---

 linux-2.6.13-rc6-maneesh/drivers/base/class.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff -puN drivers/base/class.c~fix-class-attributes-race drivers/base/class.c
--- linux-2.6.13-rc6/drivers/base/class.c~fix-class-attributes-race 
2005-08-10 12:35:06.0 +0530
+++ linux-2.6.13-rc6-maneesh/drivers/base/class.c   2005-08-11 
09:27:17.202081088 +0530
@@ -299,6 +299,11 @@ static void class_dev_release(struct kob
 
pr_debug("device class '%s': release.\n", cd->class_id);
 
+   if (cd->devt_attr) {
+   kfree(cd->devt_attr);
+   cd->devt_attr = NULL;
+   }
+
if (cls->release)
cls->release(cd);
else {
@@ -591,11 +596,10 @@ void class_device_del(struct class_devic
 
if (class_dev->dev)
sysfs_remove_link(&class_dev->kobj, "device");
-   if (class_dev->devt_attr) {
-   class_device_remove_file(class_dev, class_dev->devt_attr);
-   kfree(class_dev->devt_attr);
-   class_dev->devt_attr = NULL;
-   }
+
+   if (class_dev->devt_attr)
+class_device_remove_file(class_dev, class_dev->devt_attr);
+
class_device_remove_attrs(class_dev);
 
kobject_hotplug(&class_dev->kobj, KOBJ_REMOVE);
_

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: [EMAIL PROTECTED]
Phone: 91-80-25044990
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-10 Thread Greg KH 
On Wed, Aug 10, 2005 at 03:36:36PM +0530, Maneesh Soni wrote:
> On Wed, Aug 10, 2005 at 04:26:51PM +1000, Keith Owens wrote:
> > FYI, the intermittent free after use in sysfs is still there in
> > 2.6.13-rc6.
> > 
> 
> The race condition is known here. It is some thing in the upper layer. 
> In this case "driver/base/class.c" which frees the kobject's attributes 
> even if there are live references to kobject.
> 
> 
> open sysfs file   unregister class device
> sysfs_open_file() class_device_del()
>   -> takes a ref on kobject -> kfree attribute struct
>  -> accesses attributes -> kobject_del()
> -> kref_put() 
> close sysfs file
> sysfs_release()   
>   -> acesses attributes using s_element
>   -> drops ref to kobject
> 
> Solution could be either we have reference counting for attributes also
> or keep attributes alive till the last reference to the kobject. Both these
> needs changes in the driver core.
> 
> Greg, will the following patch make sense? This postpones the kfree() of
> devt_attr till class_dev_release() is called. 

Yes, that patch looks good, if you fix up the space vs. tabs issue :)

But will that really fix this race?  I was under the impression the oops
didn't come from trying to access the devt_attr, but the sysfs s_element
pointer?

> Please check this patch out, if this helps or not.

I'd be interested in seeing if this fixes it.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-10 Thread Maneesh Soni 
On Wed, Aug 10, 2005 at 04:26:51PM +1000, Keith Owens wrote:
> FYI, the intermittent free after use in sysfs is still there in
> 2.6.13-rc6.
> 

The race condition is known here. It is some thing in the upper layer. 
In this case "driver/base/class.c" which frees the kobject's attributes 
even if there are live references to kobject.


open sysfs file unregister class device
sysfs_open_file()   class_device_del()
  -> takes a ref on kobject   -> kfree attribute struct
 -> accesses attributes   -> kobject_del()
  -> kref_put() 
close sysfs file  
sysfs_release() 
  -> acesses attributes using s_element
  -> drops ref to kobject

Solution could be either we have reference counting for attributes also
or keep attributes alive till the last reference to the kobject. Both these
needs changes in the driver core.

Greg, will the following patch make sense? This postpones the kfree() of
devt_attr till class_dev_release() is called. 

Please check this patch out, if this helps or not.

Thanks
Maneesh


o following patch moves the code to free devt_attr from class_device_del()
  to class_dev_release() which is called after the last reference to the
  corresponding kobject() is gone. This allows to keep the devt_attr 
  alive while the corresponding sysfs file is open.

Signed-off-by: Maneesh Soni <[EMAIL PROTECTED]>
---

 linux-2.6.13-rc6-maneesh/drivers/base/class.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff -puN drivers/base/class.c~fix-class-attributes-race drivers/base/class.c
--- linux-2.6.13-rc6/drivers/base/class.c~fix-class-attributes-race 
2005-08-10 12:35:06.154386456 +0530
+++ linux-2.6.13-rc6-maneesh/drivers/base/class.c   2005-08-10 
14:27:12.903765112 +0530
@@ -299,6 +299,11 @@ static void class_dev_release(struct kob
 
pr_debug("device class '%s': release.\n", cd->class_id);
 
+if (cd->devt_attr) {
+kfree(cd->devt_attr);
+cd->devt_attr = NULL;
+}
+
if (cls->release)
cls->release(cd);
else {
@@ -591,11 +596,10 @@ void class_device_del(struct class_devic
 
if (class_dev->dev)
sysfs_remove_link(&class_dev->kobj, "device");
-   if (class_dev->devt_attr) {
-   class_device_remove_file(class_dev, class_dev->devt_attr);
-   kfree(class_dev->devt_attr);
-   class_dev->devt_attr = NULL;
-   }
+
+   if (class_dev->devt_attr)
+class_device_remove_file(cd, cd->devt_attr);
+
class_device_remove_attrs(class_dev);
 
kobject_hotplug(&class_dev->kobj, KOBJ_REMOVE);
_

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: [EMAIL PROTECTED]
Phone: 91-80-25044990
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-09 Thread Keith Owens 
FYI, the intermittent free after use in sysfs is still there in
2.6.13-rc6.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-02 Thread Greg KH 
On Tue, Aug 02, 2005 at 01:34:22PM +0530, Maneesh Soni wrote:
> Looks like the attribute structure is allocated dynamically and
> is freed before the sysfs_release() is called?
> 
> Basically it could be like this..
> 
> file (/sys/class/vc/vcs16/dev) is still open and the corresponding
> attribute structure is already gone. open files will the keep the
> corresponding dentry and in-turn sysfs_dirent alive.
> 
> sysfs_open_file() does call kobject_get() and it expects the
> kobject to be around while the sysfs files for kobject's corresponding
> attributes are open.
> 
> Greg, could there be cases where the kobject is alive but
> attributes are freed? In those cases we will need some
> way to keep attrbiutes alive while kobject is around.

Well, we need to remove the attributes before we free the kobject,
right?  It looks like we are racing here, I'll dig into this and see if
I can find anything...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-02 Thread Maneesh Soni 
On Tue, Aug 02, 2005 at 01:05:50PM +1000, Keith Owens wrote:
> On Mon, 1 Aug 2005 12:03:21 -0700,
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >Keith Owens <[EMAIL PROTECTED]> wrote:
> >>
> >> On Sat, 30 Jul 2005 02:29:55 -0700,
> >> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >> >Keith Owens <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
> >> >>  intermittent use after free in class_device_attr_show.  Reboot with no
> >> >>  changes and the problem does not always recur.
> >> >> ...
> >> >>  ip is at class_device_attr_show+0x50/0xa0
> >> >> ...
> >> >
> >> >It might help to know which file is being read from here.
> >> >
> >> >The below patch will record the name of the most-recently-opened sysfs
> >> >file.  You can print last_sysfs_file[] in the debugger or add the
> >> >appropriate printk to the ia64 code?
> >>
> >> No need for a patch.  It is /dev/vcsa2.
> >
> >You mean /sys/class/vc/vcsa2?
> 
> The vcsnn value varies.  I traced the dentry parent chain for the
> latest event.  From bottom to top the d_name entries are
> 
>   dev, vcs16, vc, class, /.
> 
> That makes no sense, why is dev a child of vcs16?  Raw data at the end.
> 

The path looks ok..

[EMAIL PROTECTED] ~]# ls -l /sys/class/vc/vcs1/dev
-r--r--r--  1 root root 4096 Aug  1 19:35 /sys/class/vc/vcs1/dev
[EMAIL PROTECTED] ~]# cat /sys/class/vc/vcs1/dev
7:1

> >That appears to be using generic code...
> >
> >Can you please summarise what you curently know about this bug?  What is
> >being accessed after free in class_device_attr_show()?  class_dev_attr?
> >cd?
> 
> IA64, compiled for both SMP and uni-processor.  Lots of debug configs,
> including slab poisoning.
> 
> The problem was first noticed at 2.6.13-rc3, it has also been seen in
> -rc4.  It is very intermittent, so -rc3 may not be the starting point.
> 
> Failures have been seen in two sysfs routines,
> sysfs_read_file()->class_device_attr_show() and
> sysfs_release()->module_put(owner).
> 
> The common denominator in the failures is that sd->s_element points to
> poisoned data.
> 
> Raw data, from the failure in sysfs_release:
> 
> kdb> filp 0xe0301eeae8d0
> name.name 0xe0301d171384  name.len  3
> File Pointer at 0xe0301eeae8d0
>  f_list.nxt = 0xe0301eeaea08 f_list.prv = 0xe03003e5aeb8
>  f_dentry = 0xe0301d1712a0 f_op = 0xa00100a615c8
>  f_count = 0 f_flags = 0x8000 f_mode = 0xd
>  f_pos = 5
> 
> dentry parent chain.  /class/vc/vcs16/dev WTF?
> 
> kdb> dentry 0xe0301d1712a0
> Dentry at 0xe0301d1712a0
>  d_name.len = 3 d_name.name = 0xe0301d171384 
>  d_count = 1 d_flags = 0x18 d_inode = 0xe0b476b32df0
>  d_parent = 0xe0301d171a80
>  d_hash.nxt = 0x d_hash.prv = 0x00200200
>  d_lru.nxt = 0xe0301d1712f8 d_lru.prv = 0xe0301d1712f8
>  d_child.nxt = 0xe0301d171af8 d_child.prv = 0xe0301d171af8
>  d_subdirs.nxt = 0xe0301d171318 d_subdirs.prv = 0xe0301d171318
>  d_alias.nxt = 0xe0b476b32e20 d_alias.prv = 0xe0b476b32e20
>  d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58
> 
> kdb> dentry 0xe0301d171a80
> Dentry at 0xe0301d171a80
>  d_name.len = 5 d_name.name = 0xe0301d171b64 
>  d_count = 2 d_flags = 0x10 d_inode = 0xe0301986cac0
>  d_parent = 0xe0347b87c880
>  d_hash.nxt = 0x d_hash.prv = 0x00200200
>  d_lru.nxt = 0xe0301d171ad8 d_lru.prv = 0xe0301d171ad8
>  d_child.nxt = 0xe03011ba9ae8 d_child.prv = 0xe03019f974c8
>  d_subdirs.nxt = 0xe0301d171308 d_subdirs.prv = 0xe0301d171308
>  d_alias.nxt = 0xe0301986caf0 d_alias.prv = 0xe0301986caf0
>  d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58
> 
> kdb> dentry 0xe0347b87c880
> Dentry at 0xe0347b87c880
>  d_name.len = 2 d_name.name = 0xe0347b87c964 
>  d_count = 8 d_flags = 0x0 d_inode = 0xe0b47a5dad70
>  d_parent = 0xe0b47a404760
>  d_hash.nxt = 0x d_hash.prv = 0xa0020079d000
>  d_lru.nxt = 0xe0347b87c8d8 d_lru.prv = 0xe0347b87c8d8
>  d_child.nxt = 0xe0b47a445668 d_child.prv = 0xe0347b921548
>  d_subdirs.nxt = 0xe0301a1fd788 d_subdirs.prv = 0xe0347b87c7c8
>  d_alias.nxt = 0xe0b47a5dada0 d_alias.prv = 0xe0b47a5dada0
>  d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58
> 
> kdb> dentry 0xe0b47a404760
> Dentry at 0xe0b47a404760
>  d_name.len = 5 d_name.name = 0xe0b47a404844 
>  d_count = 20 d_flags = 0x0 d_inode = 0xe0347bc95c18
>  d_parent = 0xe0b47a405180
>  d_hash.nxt = 0x d_hash.prv = 0xa002002d4bc8
>  d_lru.nxt = 0xe0b47a4047b8 d_lru.prv = 0xe0b47a4047b8
>  d_child.nxt = 0xe0b47a4048e8 d_child.prv = 0xe0b47a4046a8
>  d_subdirs.nxt = 0xe03013818d68 d_subdirs.prv = 0xe0b47a405d28
>  d_alias.nxt = 0xe0347bc95c48 d_alias.prv = 0xe0347bc95c48
>  d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58
> 
> kdb> dentry 0xe0b47a405180
> Dentry at 0xe0b47a405180

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-01 Thread Keith Owens 
On Tue, 02 Aug 2005 13:05:50 +1000, 
Keith Owens <[EMAIL PROTECTED]> wrote:
>The vcsnn value varies.  I traced the dentry parent chain for the
>latest event.  From bottom to top the d_name entries are
>
>  dev, vcs16, vc, class, /.
>
>That makes no sense, why is dev a child of vcs16?  Raw data at the end.

Ignore that bit, I was confusing /dev and dev as a subdir of a sysfs
entry.  The parent chain is right.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-01 Thread Keith Owens 
On Mon, 1 Aug 2005 12:03:21 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, 30 Jul 2005 02:29:55 -0700,
>> Andrew Morton <[EMAIL PROTECTED]> wrote:
>> >Keith Owens <[EMAIL PROTECTED]> wrote:
>> >>
>> >> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
>> >>  intermittent use after free in class_device_attr_show.  Reboot with no
>> >>  changes and the problem does not always recur.
>> >> ...
>> >>  ip is at class_device_attr_show+0x50/0xa0
>> >> ...
>> >
>> >It might help to know which file is being read from here.
>> >
>> >The below patch will record the name of the most-recently-opened sysfs
>> >file.  You can print last_sysfs_file[] in the debugger or add the
>> >appropriate printk to the ia64 code?
>>
>> No need for a patch.  It is /dev/vcsa2.
>
>You mean /sys/class/vc/vcsa2?

The vcsnn value varies.  I traced the dentry parent chain for the
latest event.  From bottom to top the d_name entries are

  dev, vcs16, vc, class, /.

That makes no sense, why is dev a child of vcs16?  Raw data at the end.

>That appears to be using generic code...
>
>Can you please summarise what you curently know about this bug?  What is
>being accessed after free in class_device_attr_show()?  class_dev_attr?
>cd?

IA64, compiled for both SMP and uni-processor.  Lots of debug configs,
including slab poisoning.

The problem was first noticed at 2.6.13-rc3, it has also been seen in
-rc4.  It is very intermittent, so -rc3 may not be the starting point.

Failures have been seen in two sysfs routines,
sysfs_read_file()->class_device_attr_show() and
sysfs_release()->module_put(owner).

The common denominator in the failures is that sd->s_element points to
poisoned data.

Raw data, from the failure in sysfs_release:

kdb> filp 0xe0301eeae8d0
name.name 0xe0301d171384  name.len  3
File Pointer at 0xe0301eeae8d0
 f_list.nxt = 0xe0301eeaea08 f_list.prv = 0xe03003e5aeb8
 f_dentry = 0xe0301d1712a0 f_op = 0xa00100a615c8
 f_count = 0 f_flags = 0x8000 f_mode = 0xd
 f_pos = 5

dentry parent chain.  /class/vc/vcs16/dev WTF?

kdb> dentry 0xe0301d1712a0
Dentry at 0xe0301d1712a0
 d_name.len = 3 d_name.name = 0xe0301d171384 
 d_count = 1 d_flags = 0x18 d_inode = 0xe0b476b32df0
 d_parent = 0xe0301d171a80
 d_hash.nxt = 0x d_hash.prv = 0x00200200
 d_lru.nxt = 0xe0301d1712f8 d_lru.prv = 0xe0301d1712f8
 d_child.nxt = 0xe0301d171af8 d_child.prv = 0xe0301d171af8
 d_subdirs.nxt = 0xe0301d171318 d_subdirs.prv = 0xe0301d171318
 d_alias.nxt = 0xe0b476b32e20 d_alias.prv = 0xe0b476b32e20
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

kdb> dentry 0xe0301d171a80
Dentry at 0xe0301d171a80
 d_name.len = 5 d_name.name = 0xe0301d171b64 
 d_count = 2 d_flags = 0x10 d_inode = 0xe0301986cac0
 d_parent = 0xe0347b87c880
 d_hash.nxt = 0x d_hash.prv = 0x00200200
 d_lru.nxt = 0xe0301d171ad8 d_lru.prv = 0xe0301d171ad8
 d_child.nxt = 0xe03011ba9ae8 d_child.prv = 0xe03019f974c8
 d_subdirs.nxt = 0xe0301d171308 d_subdirs.prv = 0xe0301d171308
 d_alias.nxt = 0xe0301986caf0 d_alias.prv = 0xe0301986caf0
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

kdb> dentry 0xe0347b87c880
Dentry at 0xe0347b87c880
 d_name.len = 2 d_name.name = 0xe0347b87c964 
 d_count = 8 d_flags = 0x0 d_inode = 0xe0b47a5dad70
 d_parent = 0xe0b47a404760
 d_hash.nxt = 0x d_hash.prv = 0xa0020079d000
 d_lru.nxt = 0xe0347b87c8d8 d_lru.prv = 0xe0347b87c8d8
 d_child.nxt = 0xe0b47a445668 d_child.prv = 0xe0347b921548
 d_subdirs.nxt = 0xe0301a1fd788 d_subdirs.prv = 0xe0347b87c7c8
 d_alias.nxt = 0xe0b47a5dada0 d_alias.prv = 0xe0b47a5dada0
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

kdb> dentry 0xe0b47a404760
Dentry at 0xe0b47a404760
 d_name.len = 5 d_name.name = 0xe0b47a404844 
 d_count = 20 d_flags = 0x0 d_inode = 0xe0347bc95c18
 d_parent = 0xe0b47a405180
 d_hash.nxt = 0x d_hash.prv = 0xa002002d4bc8
 d_lru.nxt = 0xe0b47a4047b8 d_lru.prv = 0xe0b47a4047b8
 d_child.nxt = 0xe0b47a4048e8 d_child.prv = 0xe0b47a4046a8
 d_subdirs.nxt = 0xe03013818d68 d_subdirs.prv = 0xe0b47a405d28
 d_alias.nxt = 0xe0347bc95c48 d_alias.prv = 0xe0347bc95c48
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

kdb> dentry 0xe0b47a405180
Dentry at 0xe0b47a405180
 d_name.len = 1 d_name.name = 0xe0b47a405264 
 d_count = 11 d_flags = 0x10 d_inode = 0xe0347bc97460
 d_parent = 0xe0b47a405180
 d_hash.nxt = 0x d_hash.prv = 0x
 d_lru.nxt = 0xe0b47a4051d8 d_lru.prv = 0xe0b47a4051d8
 d_child.nxt = 0xe0b47a4051e8 d_child.prv = 0xe0b47a4051e8
 d_subdirs.nxt = 0xe0b47a446ce8 d_subdirs.prv = 0xe0b47a404a08
 d_alias.nxt = 0xe0347bc97490 d_alias.prv = 0xe0347bc97490
 d_op =

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-01 Thread Andrew Morton 
Keith Owens <[EMAIL PROTECTED]> wrote:
>
> On Sat, 30 Jul 2005 02:29:55 -0700,
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >Keith Owens <[EMAIL PROTECTED]> wrote:
> >>
> >> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
> >>  intermittent use after free in class_device_attr_show.  Reboot with no
> >>  changes and the problem does not always recur.
> >> ...
> >>  ip is at class_device_attr_show+0x50/0xa0
> >> ...
> >
> >It might help to know which file is being read from here.
> >
> >The below patch will record the name of the most-recently-opened sysfs
> >file.  You can print last_sysfs_file[] in the debugger or add the
> >appropriate printk to the ia64 code?
> 
> No need for a patch.  It is /dev/vcsa2.

You mean /sys/class/vc/vcsa2?

That appears to be using generic code...

Can you please summarise what you curently know about this bug?  What is
being accessed after free in class_device_attr_show()?  class_dev_attr? 
cd?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-01 Thread Keith Owens 
Another (different) manifestation of use after free in sysfs.  It broke
on module_put(owner) in sysfs_release().  FWIW this ia64 build is
uni-processor, so there is a lot more context switching than normally
occurs on udev.

fill_kobj_path: path = '/class/vc/vcs2'
kobject_hotplug: /sbin/hotplug vc seq=1809 HOME=/ 
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add DEVPATH=/class/vc/vcs2 
SUBSYSTEM=vc
kobject vcsa2: registering. parent: vc, set: class_obj
kobject_hotplug
fill_kobj_path: path = '/class/vc/vcsa2'
kobject_hotplug: /sbin/hotplug vc seq=1810 HOME=/ 
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add DEVPATH=/class/vc/vcsa2 
SUBSYSTEM=vc
kobject_hotplug
fill_kobj_path: path = '/class/vc/vcs1'
kobject_hotplug: /sbin/hotplug vc seq=1811 HOME=/ 
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove DEVPATH=/class/vc/vcs1 
SUBSYSTEM=vc
kobject vcs1: cleaning up
kobject_hotplug
fill_kobj_path: path = '/class/vc/vcsa1'
kobject_hotplug: /sbin/hotplug vc seq=1812 HOME=/ 
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove DEVPATH=/class/vc/vcsa1 
SUBSYSTEM=vc
kobject vcsa1: cleaning up
kobject vcs16: cleaning up
Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6cf3
udev[24414]: Oops 8821862825984 [1]
Modules linked in: md5 ipv6 usbcore raid0 md_mod nls_iso8859_1 nls_cp437 dm_mod 
sg st osst

Pid: 24414, CPU 0, comm: udev
psr : 1010081a6018 ifs : 8308 ip  : []Not 
tainted
ip is at sysfs_release+0xf0/0x1c0
unat:  pfs : 0308 rsc : 0003
rnat:  bsps:  pr  : 00158659
ldrs:  ccv :  fpsr: 0009804c8270033f
csd :  ssd : 
b0  : a0010025bff0 b6  : a001e8c0 b7  : a0010057ff00
f6  : 1003e6b6b6b6b6b6b6b6b f7  : 0ffe58bbeff7b8000
f8  : 1003e0578 f9  : 1003e0005
f10 : 100019803b6e3 f11 : 1003e0005
r1  : a00100ddf690 r2  : 0001 r3  : e0b078360da0
r8  :  r9  : a00100be0a40 r10 : 00f4
r11 : 0001 r12 : e0b078367e30 r13 : e0b07836
r14 : 6b6b6b6b6b6b6cf3 r15 : 0001 r16 : e0b078360da0
r17 :  r18 : 054cd124 r19 : a0007fff62138000
r20 : a0007fff8c7a r21 : 0010 r22 : 4000
r23 : 6b6b6b6b6b6b6b6b r24 :  r25 : e0347bff0758
r26 : 0090 r27 : e030752f0728 r28 : e030752f0720
r29 : e030752f0738 r30 :  r31 : 0001

kdb> r s
 r32: e0b476b32df0  r33: e0b472417380  r34: 6b6b6b6b6b6b6b6b 
 r35: a0010019a060  r36: 0610  r37: 0610 
 r38: a0010025bff0  r39: 0308 

kdb> bt
Stack traceback for pid 24414
0xe0b078362441424400  10   R  0xe0b078360300 *udev
0xa0010025c010 sysfs_release+0xf0
args (0xe0b476b32df0, 0xe0b472417380, 0x6b6b6b6b6b6b6b6b, 
0xa0010019a060, 0x610)
0xa0010019a060 __fput+0x3c0
args (0xe0301eeae8d0, 0xe0301eeae8f0, 0xe0b476b32df0, 
0xe0301eeae8e0, 0xe0347bc91200)
0xa0010019a0c0 fput+0x40
args (0xe0301eeae8d0, 0xa00100191d60, 0x308, 0xe0b476b32df0)
0xa00100191d60 filp_close+0xc0
args (0xe0301eeae8d0, 0xe0b4720d5230, 0x0, 0xa001001920d0, 
0x919)
0xa001001920d0 sys_close+0x2f0
args (0x6, 0x60058210, 0x4000, 0x280, 0x0)
0xa001b520 ia64_ret_from_syscall
args (0x6, 0x60058210, 0x4000)
0xa0010640 __kernel_syscall_via_break
args (0x6, 0x60058210, 0x4000)

kdb> inode 0xe0b476b32df0
struct inode at  0xe0b476b32df0
 i_ino = 34192 i_count = 1 i_size 16384
 i_mode = 0100444  i_nlink = 0  i_rdev = 0x0
 i_hash.nxt = 0x i_hash.pprev = 0x
 i_list.nxt = 0xe0b472084d40 i_list.prv = 0xe0b476b31c98
 i_dentry.nxt = 0xe0301d1712a0 i_dentry.prv = 0xe0301d1712a0
 i_sb = 0xe03003e5ad58 i_op = 0xa00100a61488 i_data = 
0xe0b476b32f98 nrpages = 0
 i_fop= 0xa00100a615c8 i_flock = 0x i_mapping = 
0xe0b476b32f98
 i_flags 0x0 i_state 0x0 []  fs specific info @ 0xe0b476b33148

kdb> dentry 0xe0301d1712a0
Dentry at 0xe0301d1712a0
 d_name.len = 3 d_name.name = 0xe0301d171384 
 d_count = 1 d_flags = 0x18 d_inode = 0xe0b476b32df0
 d_parent = 0xe0301d171a80
 d_hash.nxt = 0x d_hash.prv = 0x00200200
 d_lru.nxt = 0xe0301d1712f8 d_lru.prv = 0xe0301d1712f8
 d_child.nxt = 0xe0301d171af8 d_child.prv = 0xe0301d171af8
 d_subdirs.nxt = 0xe0301d171318 d_subdirs.prv = 0xe0301d171318
 d_alias.nxt = 0xe0b476b32e20 d_alias.prv = 0xe0b476b32e20
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-08-01 Thread Keith Owens 
On Sat, 30 Jul 2005 02:29:55 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]> wrote:
>>
>> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
>>  intermittent use after free in class_device_attr_show.  Reboot with no
>>  changes and the problem does not always recur.
>> ...
>>  ip is at class_device_attr_show+0x50/0xa0
>> ...
>
>It might help to know which file is being read from here.
>
>The below patch will record the name of the most-recently-opened sysfs
>file.  You can print last_sysfs_file[] in the debugger or add the
>appropriate printk to the ia64 code?

No need for a patch.  It is /dev/vcsa2.

kdb> bt
Stack traceback for pid 23066
0xe0301abf80002306623051  10   R  0xe0301abf8300 *udev
0xa0010057f850 class_device_attr_show+0x50
args (0xe0b006abb900, 0x6b6b6b6b6b6b6b6b, 0xe030186d4000, 
0xa0010025cf90, 0x711)
0xa0010025cf90 sysfs_read_file+0x2b0
args (0xe03073917110, 0x60058210, 0x4000, 
0xe0301abffe38, 0xe0307a98d668)
0xa00100197ae0 vfs_read+0x1c0
args (0xe0301b2ba8d0, 0x60058210, 0x4000, 
0xe0301abffe38, 0xe0301b2ba8f0)
0xa00100197e20 sys_read+0x80
args (0x6, 0x60058210, 0x4000, 0x280, 0x0)
0xa001b520 ia64_ret_from_syscall
args (0x6, 0x60058210, 0x4000)
0xa0010640 __kernel_syscall_via_break
args (0x6, 0x60058210, 0x4000)

kdb> r
 psr: 0x1010081a6018   ifs: 0x8308ip: 0xa0010057f850
unat: 0x   pfs: 0x0711   rsc: 0x0003
rnat: 0xa00100abbb40  bsps: 0x036apr: 0x00159659
ldrs: 0x   ccv: 0x  fpsr: 0x0009804c0270033f
  b0: 0xa0010025cf90b6: 0xa001e8c0b7: 0xa0010057f800
  r1: 0xa00100ddf690r2: 0xe03073917128r3: 0xe03003018498
  r8: 0xr9: 0xa00100bfbbe8   r10: 0xe030186d4000
 r11: 0x00c061b5   r12: 0xe0301abffe20   r13: 0xe0301abf8000
 r14: 0xa0010057f800   r15: 0xe030186d4000   r16: 0x6db6db6db6db6db7
 r17: 0x2a155f98   r18: 0xa0007fff62138000   r19: 0xe030030102c8
 r20: 0xe0300301   r21: 0xfffefcf1   r22: 0x0010
 r23: 0xa00100d3f1a0   r24: 0xa00100bfbbe8   r25: 0x0542abf3
 r26: 0xa00100995718   r27: 0xe03003015208   r28: 0x
 r29: 0xe0300301   r30: 0xa00100d3f1a0   r31: 0x
®s = e0301abffc60

kdb> r s
 r32: e0b006abb900  r33: 6b6b6b6b6b6b6b6b  r34: e030186d4000
 r35: a0010025cf90  r36: 0711  r37: a00100ddf690
 r38: e0b006abb8f0  r39: e030186d4000

kdb> filp 0xe0301b2ba8d0
name.name 0xe0301aced384  name.len  3
File Pointer at 0xe0301b2ba8d0
 f_list.nxt = 0xe0301b2bb9e0 f_list.prv = 0xe03003e5aeb8
 f_dentry = 0xe0301aced2a0 f_op = 0xa00100a615c8
 f_count = 1 f_flags = 0x8000 f_mode = 0xd
 f_pos = 0

kdb> dentry 0xe0301aced2a0
Dentry at 0xe0301aced2a0
 d_name.len = 3 d_name.name = 0xe0301aced384 
 d_count = 1 d_flags = 0x18 d_inode = 0xe0b4796a87c8
 d_parent = 0xe0b0044a6020
 d_hash.nxt = 0x d_hash.prv = 0x00200200
 d_lru.nxt = 0xe0301aced2f8 d_lru.prv = 0xe0301aced2f8
 d_child.nxt = 0xe0b0044a6098 d_child.prv = 0xe0b0044a6098
 d_subdirs.nxt = 0xe0301aced318 d_subdirs.prv = 0xe0301aced318
 d_alias.nxt = 0xe0b4796a87f8 d_alias.prv = 0xe0b4796a87f8
 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58

kdb> inode 0xe0b4796a87c8
struct inode at  0xe0b4796a87c8
 i_ino = 33036 i_count = 1 i_size 16384
 i_mode = 0100444  i_nlink = 0  i_rdev = 0x0
 i_hash.nxt = 0x i_hash.pprev = 0x
 i_list.nxt = 0xe0301b10d2f0 i_list.prv = 0xe0b474f1bb50
 i_dentry.nxt = 0xe0301aced2a0 i_dentry.prv = 0xe0301aced2a0
 i_sb = 0xe03003e5ad58 i_op = 0xa00100a61488 i_data = 
0xe0b4796a8970 nrpages = 0
 i_fop= 0xa00100a615c8 i_flock = 0x i_mapping = 
0xe0b4796a8970
 i_flags 0x0 i_state 0x0 []  fs specific info @ 0xe0b4796a8b20

kdb> kobject 0xe0b006abb900
kobject at 0xe0b006abb900
 k_name 0xe0b006abb908 'vcsa2'
 kref.refcount 1'
 entry.next = 0xe0b006abb920 entry.prev = 0xe0b006abb920
 parent = 0xe0347b877528 kset = 0xa00100abba30 ktype = 
0x dentry = 0xe0b0044a6020

The attr is passed to class_device_attr_show in r33 but gcc has reused
that register by the time of the oops.

kdb> id class_device_attr_show
0xa0010057f800 class_device_attr_show[MII]   alloc r36=ar.pfs,8,6,0
0xa0010057f806 class_device_attr_show+0x6mov r8=r0;;
0xa0010057f80c class_device_attr_show+0xcadds r2=24,r33

0xa0010057f810 class_device_attr_show+0x10[MMI]   mov r37=r1
0xa0010057f816 class_device_

Re: 2.6.13-rc4 use after free in class_device_attr_show

2005-07-30 Thread Andrew Morton 
Keith Owens <[EMAIL PROTECTED]> wrote:
>
> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
>  intermittent use after free in class_device_attr_show.  Reboot with no
>  changes and the problem does not always recur.
> ...
>  ip is at class_device_attr_show+0x50/0xa0
> ...
> 
>  Call Trace:
>   [] show_stack+0x80/0xa0
>  sp=e03076ce79c0 bsp=e03076ce10d8
>   [] show_regs+0x850/0x880
>  sp=e03076ce7b90 bsp=e03076ce1078
>   [] die+0x280/0x4a0
>  sp=e03076ce7ba0 bsp=e03076ce1028
>   [] ia64_do_page_fault+0x650/0xba0
>  sp=e03076ce7ba0 bsp=e03076ce0fb8
>   [] ia64_leave_kernel+0x0/0x290
>  sp=e03076ce7c50 bsp=e03076ce0fb8
>   [] class_device_attr_show+0x50/0xa0
>  sp=e03076ce7e20 bsp=e03076ce0f78
>   [] sysfs_read_file+0x2b0/0x360
>  sp=e03076ce7e20 bsp=e03076ce0f08
>   [] vfs_read+0x1c0/0x360
>  sp=e03076ce7e20 bsp=e03076ce0eb0
>   [] sys_read+0x80/0xe0
>  sp=e03076ce7e20 bsp=e03076ce0e38
>   [] ia64_ret_from_syscall+0x0/0x20
>  sp=e03076ce7e30 bsp=e03076ce0e38

It might help to know which file is being read from here.

The below patch will record the name of the most-recently-opened sysfs
file.  You can print last_sysfs_file[] in the debugger or add the
appropriate printk to the ia64 code?

--- devel/fs/sysfs/file.c~sysfs-crash-debugging 2005-07-30 01:32:10.0 
-0700
+++ devel-akpm/fs/sysfs/file.c  2005-07-30 02:09:01.0 -0700
@@ -6,6 +6,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 
@@ -324,8 +326,14 @@ static int check_perm(struct inode * ino
return error;
 }
 
+char last_sysfs_file[PATH_MAX];
+
 static int sysfs_open_file(struct inode * inode, struct file * filp)
 {
+   char *p = d_path(filp->f_dentry, sysfs_mount, last_sysfs_file,
+   sizeof(last_sysfs_file));
+   if (p)
+   memmove(last_sysfs_file, p, strlen(p));
return check_perm(inode,filp);
 }
 
diff -puN arch/i386/kernel/traps.c~sysfs-crash-debugging 
arch/i386/kernel/traps.c
--- devel/arch/i386/kernel/traps.c~sysfs-crash-debugging2005-07-30 
01:32:10.0 -0700
+++ devel-akpm/arch/i386/kernel/traps.c 2005-07-30 01:32:10.0 -0700
@@ -96,6 +96,8 @@ static int kstack_depth_to_print = 24;
 struct notifier_block *i386die_chain;
 static DEFINE_SPINLOCK(die_notifier_lock);
 
+extern char last_sysfs_file[];
+
 int register_die_notifier(struct notifier_block *nb)
 {
int err = 0;
@@ -370,6 +372,7 @@ void die(const char * str, struct pt_reg
 #endif
if (nl)
printk("\n");
+   printk(KERN_ALERT "last sysfs file: %s\n", last_sysfs_file);
 #ifdef CONFIG_KGDB
/* This is about the only place we want to go to kgdb even if in
 * user mode.  But we must go in via a trap so within kgdb we will
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc4 use after free in class_device_attr_show

2005-07-29 Thread Keith Owens 
2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options.  There is an
intermittent use after free in class_device_attr_show.  Reboot with no
changes and the problem does not always recur.

Starting SSH daemon   done
Starting sound driver done
Starting cupsddone
loading ACPI modules () Starting powersaved   done
Try to get initial date and time via NTP from  ntp0   done
Starting network time protocol daemon (NTPD)  done
Starting kernel based NFS server  done
Starting service automounter  done
udev[21369]: Oops 8813272891392 [1]

udev[21369]: Oops 8813272891392 [1]
Modules linked in: md5 ipv6 usbcore raid0 md_mod nls_iso8859_1 nls_cp437 dm_mod 
sg st osst

Pid: 21369, CPU 0, comm: udev
psr : 1010081a6018 ifs : 8308 ip  : []Not 
tainted
ip is at class_device_attr_show+0x50/0xa0
unat:  pfs : 0711 rsc : 0003
rnat: a00100abbae0 bsps: 01fb pr  : 00159659
ldrs:  ccv :  fpsr: 0009804c0270033f
csd :  ssd : 
b0  : a0010025def0 b6  : a001e8c0 b7  : a00100580760
f6  : 1003e6db6db6db6db6db7 f7  : 1003e00c1d6ca
f8  : 1003e00c1d6ca f9  : 1003e054cdf86
f10 : 0 f11 : 0
r1  : a00100ddf0a0 r2  : e03072ab7288 r3  : e0300301c498
r8  :  r9  : a00100bfb5d0 r10 : e03075b28000
r11 : 00c1d6ca r12 : e03076ce7e20 r13 : e03076ce
r14 : a00100580760 r15 : e03075b28000 r16 : 6db6db6db6db6db7
r17 : 2a66fc30 r18 : a0007fff62138000 r19 : e030030102c8
r20 : e0300301 r21 : fffefcf1 r22 : 0010
r23 : a00100d46c50 r24 : a00100bfb5d0 r25 : 054cdf86
r26 : a001009968c8 r27 : e03003015208 r28 : 
r29 : e0300301 r30 : a00100d46c50 r31 : 

Call Trace:
 [] show_stack+0x80/0xa0
sp=e03076ce79c0 bsp=e03076ce10d8
 [] show_regs+0x850/0x880
sp=e03076ce7b90 bsp=e03076ce1078
 [] die+0x280/0x4a0
sp=e03076ce7ba0 bsp=e03076ce1028
 [] ia64_do_page_fault+0x650/0xba0
sp=e03076ce7ba0 bsp=e03076ce0fb8
 [] ia64_leave_kernel+0x0/0x290
sp=e03076ce7c50 bsp=e03076ce0fb8
 [] class_device_attr_show+0x50/0xa0
sp=e03076ce7e20 bsp=e03076ce0f78
 [] sysfs_read_file+0x2b0/0x360
sp=e03076ce7e20 bsp=e03076ce0f08
 [] vfs_read+0x1c0/0x360
sp=e03076ce7e20 bsp=e03076ce0eb0
 [] sys_read+0x80/0xe0
sp=e03076ce7e20 bsp=e03076ce0e38
 [] ia64_ret_from_syscall+0x0/0x20
sp=e03076ce7e30 bsp=e03076ce0e38
kdb> id class_device_attr_show
0xa00100580760 class_device_attr_show[MII]   alloc r36=ar.pfs,8,6,0
0xa00100580766 class_device_attr_show+0x6mov r8=r0;;
0xa0010058076c class_device_attr_show+0xcadds r2=24,r33

0xa00100580770 class_device_attr_show+0x10[MMI]   mov r37=r1
0xa00100580776 class_device_attr_show+0x16mov r39=r34
0xa0010058077c class_device_attr_show+0x1cadds r38=-16,r32

0xa00100580780 class_device_attr_show+0x20[MII]   nop.m 0x0
0xa00100580786 class_device_attr_show+0x26mov r35=b0;;
0xa0010058078c class_device_attr_show+0x2cmov.i ar.pfs=r36

0xa00100580790 class_device_attr_show+0x30[MII]   ld8 r33=[r2]
0xa00100580796 class_device_attr_show+0x36mov b0=r35;;
0xa0010058079c class_device_attr_show+0x3ccmp.eq p8,p9=0,r33

0xa001005807a0 class_device_attr_show+0x40[MBB]   nop.m 0x0
0xa001005807a6 class_device_attr_show+0x46  (p09) br.cond.dpnt.few 
0xa001005807b0 class_device_attr_show+0x50
0xa001005807ac class_device_attr_show+0x4cbr.ret.sptk.many b0

0xa001005807b0 class_device_attr_show+0x50[MMI]   ld8 r8=[r33],8;;
0xa001005807b6 class_device_attr_show+0x56ld8 r1=[r33],-8
0xa001005807bc class_device_attr_show+0x5cmov b7=r8

0xa001005807c0 class_device_attr_show+0x60[MIB]   nop.m 0x0
0xa001005807c6 class_device_attr_show+0x66nop.i 0x0
0xa001005807cc class_device_attr_show+0x6cbr.call.sptk.many 
b0=b7;;

0xa001005807d0 class_device_attr_show+0x70[MII]   mov r1=r37
0xa001005807d6 class_device_attr_show+0x76mov.i ar.