From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261346AbVHBDGF (ORCPT ); Mon, 1 Aug 2005 23:06:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261362AbVHBDGF (ORCPT ); Mon, 1 Aug 2005 23:06:05 -0400 Received: from mail.ocs.com.au ([202.147.117.210]:47302 "EHLO mail.ocs.com.au") by vger.kernel.org with ESMTP id S261346AbVHBDGE (ORCPT ); Mon, 1 Aug 2005 23:06:04 -0400 X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.1 From: Keith Owens To: Andrew Morton Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.13-rc4 use after free in class_device_attr_show In-reply-to: Your message of "Mon, 01 Aug 2005 12:03:21 MST." <20050801120321.230349c5.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Aug 2005 13:05:50 +1000 Message-ID: <26771.1122951950@ocs3.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Aug 2005 12:03:21 -0700, Andrew Morton wrote: >Keith Owens wrote: >> >> On Sat, 30 Jul 2005 02:29:55 -0700, >> Andrew Morton wrote: >> >Keith Owens 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 0xe00000301eeae8d0 name.name 0xe00000301d171384 name.len 3 File Pointer at 0xe00000301eeae8d0 f_list.nxt = 0xe00000301eeaea08 f_list.prv = 0xe000003003e5aeb8 f_dentry = 0xe00000301d1712a0 f_op = 0xa000000100a615c8 f_count = 0 f_flags = 0x8000 f_mode = 0xd f_pos = 5 dentry parent chain. /class/vc/vcs16/dev WTF? kdb> dentry 0xe00000301d1712a0 Dentry at 0xe00000301d1712a0 d_name.len = 3 d_name.name = 0xe00000301d171384 d_count = 1 d_flags = 0x18 d_inode = 0xe00000b476b32df0 d_parent = 0xe00000301d171a80 d_hash.nxt = 0x0000000000000000 d_hash.prv = 0x0000000000200200 d_lru.nxt = 0xe00000301d1712f8 d_lru.prv = 0xe00000301d1712f8 d_child.nxt = 0xe00000301d171af8 d_child.prv = 0xe00000301d171af8 d_subdirs.nxt = 0xe00000301d171318 d_subdirs.prv = 0xe00000301d171318 d_alias.nxt = 0xe00000b476b32e20 d_alias.prv = 0xe00000b476b32e20 d_op = 0xa000000100a61870 d_sb = 0xe000003003e5ad58 kdb> dentry 0xe00000301d171a80 Dentry at 0xe00000301d171a80 d_name.len = 5 d_name.name = 0xe00000301d171b64 d_count = 2 d_flags = 0x10 d_inode = 0xe00000301986cac0 d_parent = 0xe00000347b87c880 d_hash.nxt = 0x0000000000000000 d_hash.prv = 0x0000000000200200 d_lru.nxt = 0xe00000301d171ad8 d_lru.prv = 0xe00000301d171ad8 d_child.nxt = 0xe000003011ba9ae8 d_child.prv = 0xe000003019f974c8 d_subdirs.nxt = 0xe00000301d171308 d_subdirs.prv = 0xe00000301d171308 d_alias.nxt = 0xe00000301986caf0 d_alias.prv = 0xe00000301986caf0 d_op = 0xa000000100a61870 d_sb = 0xe000003003e5ad58 kdb> dentry 0xe00000347b87c880 Dentry at 0xe00000347b87c880 d_name.len = 2 d_name.name = 0xe00000347b87c964 d_count = 8 d_flags = 0x0 d_inode = 0xe00000b47a5dad70 d_parent = 0xe00000b47a404760 d_hash.nxt = 0x0000000000000000 d_hash.prv = 0xa00000020079d000 d_lru.nxt = 0xe00000347b87c8d8 d_lru.prv = 0xe00000347b87c8d8 d_child.nxt = 0xe00000b47a445668 d_child.prv = 0xe00000347b921548 d_subdirs.nxt = 0xe00000301a1fd788 d_subdirs.prv = 0xe00000347b87c7c8 d_alias.nxt = 0xe00000b47a5dada0 d_alias.prv = 0xe00000b47a5dada0 d_op = 0xa000000100a61870 d_sb = 0xe000003003e5ad58 kdb> dentry 0xe00000b47a404760 Dentry at 0xe00000b47a404760 d_name.len = 5 d_name.name = 0xe00000b47a404844 d_count = 20 d_flags = 0x0 d_inode = 0xe00000347bc95c18 d_parent = 0xe00000b47a405180 d_hash.nxt = 0x0000000000000000 d_hash.prv = 0xa0000002002d4bc8 d_lru.nxt = 0xe00000b47a4047b8 d_lru.prv = 0xe00000b47a4047b8 d_child.nxt = 0xe00000b47a4048e8 d_child.prv = 0xe00000b47a4046a8 d_subdirs.nxt = 0xe000003013818d68 d_subdirs.prv = 0xe00000b47a405d28 d_alias.nxt = 0xe00000347bc95c48 d_alias.prv = 0xe00000347bc95c48 d_op = 0xa000000100a61870 d_sb = 0xe000003003e5ad58 kdb> dentry 0xe00000b47a405180 Dentry at 0xe00000b47a405180 d_name.len = 1 d_name.name = 0xe00000b47a405264 d_count = 11 d_flags = 0x10 d_inode = 0xe00000347bc97460 d_parent = 0xe00000b47a405180 d_hash.nxt = 0x0000000000000000 d_hash.prv = 0x0000000000000000 d_lru.nxt = 0xe00000b47a4051d8 d_lru.prv = 0xe00000b47a4051d8 d_child.nxt = 0xe00000b47a4051e8 d_child.prv = 0xe00000b47a4051e8 d_subdirs.nxt = 0xe00000b47a446ce8 d_subdirs.prv = 0xe00000b47a404a08 d_alias.nxt = 0xe00000347bc97490 d_alias.prv = 0xe00000347bc97490 d_op = 0x0000000000000000 d_sb = 0xe000003003e5ad58 Hex dump of dentry passed via filp to sysfs_release. kdb> mds 0xe00000301d1712a0 0xe00000301d1712a0 1800000001 ........ 0xe00000301d1712a8 1d244b3c sb e000003003e5ad58 struct super_block at 0xe000003003e5ad58 s_dev 0x0 blocksize 0x4000 s_flags 0x40000000 s_root 0xe00000b47a405180 s_dirt 0 s_dirty.next 0xe000003003e5ae90 s_dirty.prev 0xe000003003e5ae90 s_frozen 0 s_id [sysfs] fsdata (sysfs_dirent). kdb> mds e0000030701f6d00 0xe0000030701f6d00 00000001 ........ s_count 0xe0000030701f6d08 e0000030701f6d08 .m.p0... s_sibling 0xe0000030701f6d10 e0000030701f6d08 .m.p0... 0xe0000030701f6d18 e0000030701f6d18 .m.p0... s_children 0xe0000030701f6d20 e0000030701f6d18 .m.p0... 0xe0000030701f6d28 e000003073607c10 .|`s0... s_element 0xe0000030701f6d30 812400000004 ....$... s_type, s_mode 0xe0000030701f6d38 e00000301d1712a0 ....0... s_dentry 0xe0000030701f6d40 00000000 ........ s_iattr s_element kdb> mds e000003073607c10 0xe000003073607c10 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c18 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c20 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c28 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c30 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c38 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c40 6b6b6b6b6b6b6b6b kkkkkkkk 0xe000003073607c48 a56b6b6b6b6b6b6b kkkkkkk. The failure was caused by the bad data referenced by s_element.