linux-kernel - Re: 2.6.18-rc3-mm2: oops in sysfs_follow

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] [day] [month] [year] [list]
Date:	Thu, 24 Aug 2006 11:27:11 -0700
From:	Greg KH <greg@...ah.com>
To:	Maneesh Soni <maneesh@...ibm.com>
Cc:	Mike Galbraith <efault@....de>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.18-rc3-mm2:  oops in sysfs_follow_link()

On Thu, Aug 24, 2006 at 05:14:52PM +0530, Maneesh Soni wrote:
> On Mon, Aug 14, 2006 at 02:06:57PM -0700, Greg KH wrote:
> > On Sun, Aug 13, 2006 at 09:54:53AM +0000, Mike Galbraith wrote:
> > > (resend with corrected cc)
> > > 
> > > Greetings,
> > > 
> > > I just got the below double warning from lib/kref.c:32 followed by oops.
> > > 
> > > I had just rebooted after upping my printk buffer to 20 (to be able to
> > > see a complete boot despite the spam), and was poking Ctrl+Alt+F1 trying
> > > to get to a vt to watch.
> > 
> > Maneesh, any thoughts?
> > 
> > Original messages left below...
> > 
> > 
> 
> Sorry, took lot of time for this due to vaccations.

No problem, I haven't heard of anyone else hitting this problem.

> > > DEV: registering device: ID = 'vcs6'
> > > PM: Adding info for No Bus:vcs6
> > > DEV: registering device: ID = 'vcsa6'
> > > PM: Adding info for No Bus:vcsa6
> > > DEV: Unregistering device. ID = 'vcs6'
> > > PM: Removing info for No Bus:vcs6
> > > device_create_release called for vcs6
> > > DEV: Unregistering device. ID = 'vcsa6'
> > > PM: Removing info for No Bus:vcsa6
> > > device_create_release called for vcsa6
> > > BUG: warning at lib/kref.c:32/kref_get()
> > >  [<c1003eba>] show_trace_log_lvl+0x16e/0x191
> > >  [<c1004647>] show_trace+0x12/0x14
> > >  [<c1004768>] dump_stack+0x19/0x1b
> > >  [<c11d3f28>] kref_get+0x41/0x43
> > >  [<c11d3416>] kobject_get+0x12/0x17
> > >  [<c10b0dea>] sysfs_follow_link+0x1d0/0x245
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > >  [<b7d309c4>] 0xb7d309c4
> > >  [<c1004647>] show_trace+0x12/0x14
> > >  [<c1004768>] dump_stack+0x19/0x1b
> > >  [<c11d3f28>] kref_get+0x41/0x43
> > >  [<c11d3416>] kobject_get+0x12/0x17
> > >  [<c10b0dea>] sysfs_follow_link+0x1d0/0x245
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > > BUG: warning at lib/kref.c:32/kref_get()
> > >  [<c1003eba>] show_trace_log_lvl+0x16e/0x191
> > >  [<c1004647>] show_trace+0x12/0x14
> > >  [<c1004768>] dump_stack+0x19/0x1b
> > >  [<c11d3f28>] kref_get+0x41/0x43
> > >  [<c11d3416>] kobject_get+0x12/0x17
> > >  [<c10b0ccd>] sysfs_follow_link+0xb3/0x245
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > >  [<b7d309c4>] 0xb7d309c4
> > >  [<c1004647>] show_trace+0x12/0x14
> > >  [<c1004768>] dump_stack+0x19/0x1b
> > >  [<c11d3f28>] kref_get+0x41/0x43
> > >  [<c11d3416>] kobject_get+0x12/0x17
> > >  [<c10b0ccd>] sysfs_follow_link+0xb3/0x245
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
> > >  printing eip:
> > > c10b0d1f
> > > *pde = 00000000
> > > Oops: 0000 [#3]
> > > 4K_STACKS PREEMPT SMP 
> > > last sysfs file: /class/net/lo/address
> > > Modules linked in: ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8 sd_mod ir_kbd_i2c prism54 bt878 ohci1394 bttv video_buf ir_common btcx_risc tveeprom ieee1394 snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device i2c_i801 snd soundcore
> > > CPU:    0
> > > EIP:    0060:[<c10b0d1f>]    Not tainted VLI
> > > EFLAGS: 00010246   (2.6.18-rc3-mm2-smp #182) 
> > > EIP is at sysfs_follow_link+0x105/0x245
> > > eax: 00000000   ebx: 00000001   ecx: ffffffff   edx: ffffffff
> > > esi: 00000000   edi: 00000000   ebp: dff85ec4   esp: dff85e94
> > > ds: 007b   es: 007b   ss: 0068
> > > Process hald (pid: 4133, ti=dff85000 task=c24a3030 task.ti=dff85000)
> > > Stack: f8b0e078 dff85ed8 f7bca000 00000001 dff0d704 f7c15e40 ffffffea f8b0e078 
> > >        f8b0e168 c14b19a0 f7bc9800 00000100 dff85f34 c107d187 c10824d1 0809ab00 
> > >        c10822f8 dff0d77c 00001000 08096f54 00000070 dff85fb4 f7811000 44dee880 
> > > Call Trace:
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > >  [<b7d309c4>] 0xb7d309c4
> > >  [<c1003f83>] show_stack_log_lvl+0xa6/0xcb
> > >  [<c1004180>] show_registers+0x1d8/0x286
> > >  [<c100437f>] die+0x151/0x333
> > >  [<c10197f9>] do_page_fault+0x26b/0x51f
> > >  [<c13e1a99>] error_code+0x39/0x40
> > >  [<c107d187>] generic_readlink+0x28/0x70
> > >  [<c10796de>] sys_readlinkat+0x7c/0xa1
> > >  [<c107972a>] sys_readlink+0x27/0x29
> > >  [<c10030db>] syscall_call+0x7/0xb
> > > Code: dc 00 00 00 00 83 45 dc 01 8b 40 24 85 c0 75 f5 8b 45 ec 89 45 d0 bb 01 00 00 00 31 f6 ba ff ff ff ff 8b 4d d0 8b 39 89 d1 89 f0 <f2> ae f7 d1 49 83 c1 01 01 cb 8b 4d d0 8b 49 24 89 4d d0 85 c9 
> > > EIP: [<c10b0d1f>] sysfs_follow_link+0x105/0x245 SS:ESP 0068:dff85e94
> > >  <7>DEV: registering device: ID = 'vcs2'
> > > 
> > 
> 
> 
> I guess that earlier WARN_ON's are related to the oops we are seeing. 
> The oops has oocured becaure the target kobject->k_name is NULL? 
> Somehow the target kobjcet is getting freed while sysfs_follow_link() even
> though sysfs takes ref for the the target kobject at the time of symlink
> creation. Can there be some mispatch in kref_get()/kref_put() or kobject_get()
> /kobject_put() in higher layers?

Possibly, I really don't know.  As no one else has reported this, it
might have been an odd bug with something else in the -mm patchset.

thanks for the response.

greg k-h
-
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/