* NULL pointer dereference
@ 2003-01-02 11:28 Vitezslav Samel
0 siblings, 0 replies; 4+ messages in thread
From: Vitezslav Samel @ 2003-01-02 11:28 UTC (permalink / raw)
To: linux-kernel, ext3-users
Hi!
I tried to use cdrdao on 2.5.5x kernels but kernel gives me following
messages. Further debugging reveals that sb is NULL in __ext3_std_error()
function. I tried this on ext2 and it seems it isn't ext3 specific, on
ext2 it also doesn't work.
cdrdao is after this in D state and is unkillable, but the CD-ROM drive
from which I tried to grab is perfectly usable.
This happens to me only with cdrdao, otherwise system is perfectly solid.
Cheers,
Vita
grabbing to the ext3 partition:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unable to handle kernel NULL pointer dereference at virtual address 00000118
printing eip:
c018893a
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c018893a>] Not tainted
EFLAGS: 00010097
EIP is at vsnprintf+0x22a/0x41c
eax: 00000118 ebx: c0344919 ecx: 00000118 edx: fffffffe
esi: cdb21e50 edi: ffffffff ebp: 00000118 esp: cdb21dfc
ds: 0068 es: 0068 ss: 0068
Process cdrdao (pid: 238, threadinfo=cdb20000 task=d12c4780)
Stack: c0344900 00000246 d11e0a00 c02ae2c8 d201ab70 d2609f20 ffffffff 00000000
c0344cff c01179c9 c0344900 00000400 c02733da cdb21e4c 00000000 c02725c6
d11e0a00 d201ab60 c01672a8 c02733c0 00000118 c02725c6 cdb21e6c 00000000
Call Trace:
[<c01179c9>] printk+0x61/0x114
[<c01672a8>] __ext3_std_error+0x30/0x40
[<c0162c0a>] ext3_setattr+0x19a/0x1b0
[<c014b606>] notify_change+0xe6/0x180
[<c013696b>] do_truncate+0x5b/0x78
[<c0142d41>] may_open+0x165/0x17c
[<c0143015>] open_namei+0x2bd/0x3d0
[<c013770f>] filp_open+0x3b/0x5c
[<c0137a63>] sys_open+0x37/0x78
[<c0108877>] syscall_call+0x7/0xb
Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 44 24 10 8b 44
grabbing to the ext2 partition:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unable to handle kernel paging request at virtual address 0a00007c
printing eip:
c012d596
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c012d596>] Not tainted
EFLAGS: 00010296
EIP is at vmtruncate+0x102/0x140
eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 0a000000
esi: 00000000 edi: d37a7504 ebp: 00000000 esp: d2023e50
ds: 0068 es: 0068 ss: 0068
Process cdrdao (pid: 159, threadinfo=d2022000 task=d2666140)
Stack: 00000048 d2023edc d37a7430 00000000 d37a7504 d37a74c0 00050070 0a000000
00000000 c0000024 00000a00 d37a7430 d2023edc d37a7430 c0175795 d37a7430
d2023edc d2023edc 000081a4 00000048 c014b606 d24ee9c0 d2023edc d37a7430
Call Trace:
[<c0175795>] ext2_setattr+0x25/0x30
[<c014b606>] notify_change+0xe6/0x180
[<c013696b>] do_truncate+0x5b/0x78
[<c0142d41>] may_open+0x165/0x17c
[<c0143015>] open_namei+0x2bd/0x3d0
[<c013770f>] filp_open+0x3b/0x5c
[<c0137a63>] sys_open+0x37/0x78
[<c0108877>] syscall_call+0x7/0xb
Code: 8b 42 7c 85 c0 74 0d 8b 40 2c 85 c0 74 06 52 ff d0 83 c4 04
^ permalink raw reply [flat|nested] 4+ messages in thread
* NULL pointer dereference
@ 2009-09-02 13:49 Ciprian Docan
2009-09-02 15:59 ` Frans Pop
0 siblings, 1 reply; 4+ messages in thread
From: Ciprian Docan @ 2009-09-02 13:49 UTC (permalink / raw)
To: linux-kernel; +Cc: docan
Hi,
I got the following in dmesg:
BUG: unable to handle kernel NULL pointer dereference at 00000000000000ae
IP: [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
PGD a05e1067 PUD a05e2067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.3/class
CPU 1
Modules linked in: fuse sit tunnel4 nfs fscache nfsd lockd nfs_acl
auth_rpcgss exportfs autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6
ip6table_filter ip6_tables ipv6 dm_multipath uinput snd_hda_codec_analog
snd_hda_intel snd_hda_codec ppdev snd_hwdep snd_pcm parport_pc serio_raw
dcdbas snd_timer iTCO_wdt iTCO_vendor_support parport wmi snd soundcore
snd_page_alloc i2c_i801 usb_storage e1000e pata_acpi ata_generic i915 drm
i2c_algo_bit i2c_core video output [last unloaded: speedstep_lib]
Pid: 3898, comm: devkit-disks-da Not tainted
2.6.31-0.174.rc7.git2.fc12.x86_64 #1 OptiPlex 760
RIP: 0010:[<ffffffff8124701a>] [<ffffffff8124701a>]
ima_counts_put+0x34/0xb1
RSP: 0000:ffff8800a05f5d78 EFLAGS: 00010202
RAX: ffff8800b8f34148 RBX: 0000000000000004 RCX: 00000000b7698c0f
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000
RBP: ffff8800a05f5da8 R08: ffff8800a05f5ce8 R09: ffff8800a05f5d18
R10: 00000000b7698c0f R11: 0000000000000000 R12: 0000000000000024
R13: 0000000000000000 R14: ffff8800a05f5e28 R15: fffffffffffffffa
FS: 00007ff4a8490790(0000) GS:ffff880007bde000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000000ae CR3: 00000000a05e0000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process devkit-disks-da (pid: 3898, threadinfo ffff8800a05f4000, task
ffff8800a05f8000)
Stack:
ffff8800a05f5da8 00000000b7698c0f 0000000000000024 0000000000008001
<0> 0000000000000024 0000000000000000 ffff8800a05f5ef8 ffffffff8114e4b8
<0> ffff8800a05f5dc8 ffffffffffffff9c ffff8800a05f5dd8 00000000b7698c0f
Call Trace:
[<ffffffff8114e4b8>] do_filp_open+0x534/0x9f3
[<ffffffff810956f1>] ? lock_release_holdtime+0x3f/0x146
[<ffffffff811146c4>] ? might_fault+0x71/0xd9
[<ffffffff8115a407>] ? alloc_fd+0x125/0x14b
[<ffffffff8113f3f1>] do_sys_open+0x71/0x131
[<ffffffff8113f51e>] sys_open+0x33/0x49
[<ffffffff81012f42>] system_call_fastpath+0x16/0x1b
Code: 48 83 ec 18 0f 1f 44 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31
c0 83 3d 36 22 28 01 00 48 8b 47 08 89 f3 48 8b 78 50 74 5e <0f> b7 87 ae
00 00 00 25 00 f0 00 00 3d 00 80 00 00 75 4b e8 da
RIP [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
RSP <ffff8800a05f5d78>
CR2: 00000000000000ae
---[ end trace 027f1f2d55021c25 ]---
Kernel version is: 2.6.31-0.174.rc7.git2.fc12.x86_64 #1 SMP Mon Aug 24
23:25:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux, from F12 rawhide
repository.
I am not sure what caused this, as it happened over night, and the machine
was idle. The machine is still up and running, so if you need more
information about it please let me know and I will try to provide them.
Thank you,
--
Ciprian Docan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NULL pointer dereference
2009-09-02 13:49 NULL pointer dereference Ciprian Docan
@ 2009-09-02 15:59 ` Frans Pop
2009-09-02 21:08 ` Eric Paris
0 siblings, 1 reply; 4+ messages in thread
From: Frans Pop @ 2009-09-02 15:59 UTC (permalink / raw)
To: Ciprian Docan
Cc: linux-kernel, Mimi Zohar, James Morris, linux-fsdevel, Eric Paris
Adding CCs.
The commit that introduced ima_counts_put is:
commit 94e5d714f604d4cb4cb13163f01ede278e69258b
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date: Fri Jun 26 14:05:27 2009 -0400
integrity: add ima_counts_put (updated)
This patch fixes an imbalance message as reported by J.R. Okajima.
The IMA file counters are incremented in ima_path_check. If the
actual open fails, such as ETXTBSY, decrement the counters to
prevent unnecessary imbalance messages.
Possibly this has already been fixed by the following commit? It seems
unlikely though as that was a very early commit after -rc7 and the problem
kernel was -rc7.git2 (if I read the version correctly).
commit 53a7197aff20e341487fca8575275056fe1c63e5
Author: Eric Paris <eparis@redhat.com>
Date: Wed Aug 26 14:56:48 2009 -0400
IMA: iint put in ima_counts_get and put
ima_counts_get() calls ima_iint_find_insert_get() which takes a reference
to the iint in question, but does not put that reference at the end of the
function. This can lead to a nasty memory leak.
Cheers,
FJP
Ciprian Docan wrote:
> Hi,
>
> I got the following in dmesg:
>
> BUG: unable to handle kernel NULL pointer dereference at 00000000000000ae
> IP: [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
> PGD a05e1067 PUD a05e2067 PMD 0
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1f.3/class
> CPU 1
> Modules linked in: fuse sit tunnel4 nfs fscache nfsd lockd nfs_acl
> auth_rpcgss exportfs autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6
> ip6table_filter ip6_tables ipv6 dm_multipath uinput snd_hda_codec_analog
> snd_hda_intel snd_hda_codec ppdev snd_hwdep snd_pcm parport_pc serio_raw
> dcdbas snd_timer iTCO_wdt iTCO_vendor_support parport wmi snd soundcore
> snd_page_alloc i2c_i801 usb_storage e1000e pata_acpi ata_generic i915 drm
> i2c_algo_bit i2c_core video output [last unloaded: speedstep_lib]
> Pid: 3898, comm: devkit-disks-da Not tainted
> 2.6.31-0.174.rc7.git2.fc12.x86_64 #1 OptiPlex 760
> RIP: 0010:[<ffffffff8124701a>] [<ffffffff8124701a>]
> ima_counts_put+0x34/0xb1
> RSP: 0000:ffff8800a05f5d78 EFLAGS: 00010202
> RAX: ffff8800b8f34148 RBX: 0000000000000004 RCX: 00000000b7698c0f
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000
> RBP: ffff8800a05f5da8 R08: ffff8800a05f5ce8 R09: ffff8800a05f5d18
> R10: 00000000b7698c0f R11: 0000000000000000 R12: 0000000000000024
> R13: 0000000000000000 R14: ffff8800a05f5e28 R15: fffffffffffffffa
> FS: 00007ff4a8490790(0000) GS:ffff880007bde000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000000ae CR3: 00000000a05e0000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process devkit-disks-da (pid: 3898, threadinfo ffff8800a05f4000, task
> ffff8800a05f8000)
> Stack:
> ffff8800a05f5da8 00000000b7698c0f 0000000000000024 0000000000008001
> <0> 0000000000000024 0000000000000000 ffff8800a05f5ef8 ffffffff8114e4b8
> <0> ffff8800a05f5dc8 ffffffffffffff9c ffff8800a05f5dd8 00000000b7698c0f
> Call Trace:
> [<ffffffff8114e4b8>] do_filp_open+0x534/0x9f3
> [<ffffffff810956f1>] ? lock_release_holdtime+0x3f/0x146
> [<ffffffff811146c4>] ? might_fault+0x71/0xd9
> [<ffffffff8115a407>] ? alloc_fd+0x125/0x14b
> [<ffffffff8113f3f1>] do_sys_open+0x71/0x131
> [<ffffffff8113f51e>] sys_open+0x33/0x49
> [<ffffffff81012f42>] system_call_fastpath+0x16/0x1b
> Code: 48 83 ec 18 0f 1f 44 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31
> c0 83 3d 36 22 28 01 00 48 8b 47 08 89 f3 48 8b 78 50 74 5e <0f> b7 87 ae
> 00 00 00 25 00 f0 00 00 3d 00 80 00 00 75 4b e8 da
> RIP [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
> RSP <ffff8800a05f5d78>
> CR2: 00000000000000ae
> ---[ end trace 027f1f2d55021c25 ]---
>
> Kernel version is: 2.6.31-0.174.rc7.git2.fc12.x86_64 #1 SMP Mon Aug 24
> 23:25:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux, from F12 rawhide
> repository.
>
> I am not sure what caused this, as it happened over night, and the machine
> was idle. The machine is still up and running, so if you need more
> information about it please let me know and I will try to provide them.
>
> Thank you,
> --
> Ciprian Docan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NULL pointer dereference
2009-09-02 15:59 ` Frans Pop
@ 2009-09-02 21:08 ` Eric Paris
0 siblings, 0 replies; 4+ messages in thread
From: Eric Paris @ 2009-09-02 21:08 UTC (permalink / raw)
To: Frans Pop
Cc: Ciprian Docan, linux-kernel, Mimi Zohar, James Morris,
linux-fsdevel
On Wed, 2009-09-02 at 17:59 +0200, Frans Pop wrote:
> Adding CCs.
>
> The commit that introduced ima_counts_put is:
>
> commit 94e5d714f604d4cb4cb13163f01ede278e69258b
> Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
> Date: Fri Jun 26 14:05:27 2009 -0400
> integrity: add ima_counts_put (updated)
>
> This patch fixes an imbalance message as reported by J.R. Okajima.
> The IMA file counters are incremented in ima_path_check. If the
> actual open fails, such as ETXTBSY, decrement the counters to
> prevent unnecessary imbalance messages.
>
> Possibly this has already been fixed by the following commit? It seems
> unlikely though as that was a very early commit after -rc7 and the problem
> kernel was -rc7.git2 (if I read the version correctly).
>
> commit 53a7197aff20e341487fca8575275056fe1c63e5
> Author: Eric Paris <eparis@redhat.com>
> Date: Wed Aug 26 14:56:48 2009 -0400
> IMA: iint put in ima_counts_get and put
>
> ima_counts_get() calls ima_iint_find_insert_get() which takes a reference
> to the iint in question, but does not put that reference at the end of the
> function. This can lead to a nasty memory leak.
>
> Cheers,
> FJP
>
> Ciprian Docan wrote:
> > Hi,
> >
> > I got the following in dmesg:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 00000000000000ae
> > IP: [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
> > PGD a05e1067 PUD a05e2067 PMD 0
> > Oops: 0000 [#1] SMP
> > last sysfs file: /sys/devices/pci0000:00/0000:00:1f.3/class
> > CPU 1
> > Modules linked in: fuse sit tunnel4 nfs fscache nfsd lockd nfs_acl
> > auth_rpcgss exportfs autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6
> > ip6table_filter ip6_tables ipv6 dm_multipath uinput snd_hda_codec_analog
> > snd_hda_intel snd_hda_codec ppdev snd_hwdep snd_pcm parport_pc serio_raw
> > dcdbas snd_timer iTCO_wdt iTCO_vendor_support parport wmi snd soundcore
> > snd_page_alloc i2c_i801 usb_storage e1000e pata_acpi ata_generic i915 drm
> > i2c_algo_bit i2c_core video output [last unloaded: speedstep_lib]
> > Pid: 3898, comm: devkit-disks-da Not tainted
> > 2.6.31-0.174.rc7.git2.fc12.x86_64 #1 OptiPlex 760
> > RIP: 0010:[<ffffffff8124701a>] [<ffffffff8124701a>]
> > ima_counts_put+0x34/0xb1
> > RSP: 0000:ffff8800a05f5d78 EFLAGS: 00010202
> > RAX: ffff8800b8f34148 RBX: 0000000000000004 RCX: 00000000b7698c0f
> > RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000
> > RBP: ffff8800a05f5da8 R08: ffff8800a05f5ce8 R09: ffff8800a05f5d18
> > R10: 00000000b7698c0f R11: 0000000000000000 R12: 0000000000000024
> > R13: 0000000000000000 R14: ffff8800a05f5e28 R15: fffffffffffffffa
> > FS: 00007ff4a8490790(0000) GS:ffff880007bde000(0000)
> > knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 00000000000000ae CR3: 00000000a05e0000 CR4: 00000000000406e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process devkit-disks-da (pid: 3898, threadinfo ffff8800a05f4000, task
> > ffff8800a05f8000)
> > Stack:
> > ffff8800a05f5da8 00000000b7698c0f 0000000000000024 0000000000008001
> > <0> 0000000000000024 0000000000000000 ffff8800a05f5ef8 ffffffff8114e4b8
> > <0> ffff8800a05f5dc8 ffffffffffffff9c ffff8800a05f5dd8 00000000b7698c0f
> > Call Trace:
> > [<ffffffff8114e4b8>] do_filp_open+0x534/0x9f3
> > [<ffffffff810956f1>] ? lock_release_holdtime+0x3f/0x146
> > [<ffffffff811146c4>] ? might_fault+0x71/0xd9
> > [<ffffffff8115a407>] ? alloc_fd+0x125/0x14b
> > [<ffffffff8113f3f1>] do_sys_open+0x71/0x131
> > [<ffffffff8113f51e>] sys_open+0x33/0x49
> > [<ffffffff81012f42>] system_call_fastpath+0x16/0x1b
> > Code: 48 83 ec 18 0f 1f 44 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31
> > c0 83 3d 36 22 28 01 00 48 8b 47 08 89 f3 48 8b 78 50 74 5e <0f> b7 87 ae
> > 00 00 00 25 00 f0 00 00 3d 00 80 00 00 75 4b e8 da
> > RIP [<ffffffff8124701a>] ima_counts_put+0x34/0xb1
> > RSP <ffff8800a05f5d78>
> > CR2: 00000000000000ae
> > ---[ end trace 027f1f2d55021c25 ]---
> >
> > Kernel version is: 2.6.31-0.174.rc7.git2.fc12.x86_64 #1 SMP Mon Aug 24
> > 23:25:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux, from F12 rawhide
> > repository.
> >
> > I am not sure what caused this, as it happened over night, and the machine
> > was idle. The machine is still up and running, so if you need more
> > information about it please let me know and I will try to provide them.
> >
> > Thank you,
> > --
> > Ciprian Docan
Here's the code:
void ima_counts_put(struct path *path, int mask)
{
struct inode *inode = path->dentry->d_inode;
struct ima_iint_cache *iint;
if (!ima_initialized || !S_ISREG(inode->i_mode))
return;
[blah blah blah]
Here's the assembly:
[snip]
ffffffff81247007: 83 3d 36 22 28 01 00 cmpl $0x0,0x1282236(%rip) # ffffffff824c9244 <ima_initialized>
ffffffff8124700e: 48 8b 47 08 mov 0x8(%rdi),%rax
ffffffff81247012: 89 f3 mov %esi,%ebx
ffffffff81247014: 48 8b 78 50 mov 0x50(%rax),%rdi
ffffffff81247018: 74 5e je ffffffff81247078 <ima_counts_put+0x92>
ffffffff8124701a: 0f b7 87 ae 00 00 00 movzwl 0xae(%rdi),%eax <-------- BUG HERE
ffffffff81247021: 25 00 f0 00 00 and $0xf000,%eax
ffffffff81247026: 3d 00 80 00 00 cmp $0x8000,%eax
ffffffff8124702b: 75 4b jne ffffffff81247078 <ima_counts_put+0x92>
[snip]
Pretty clear that we checked ima_initialized (and it was !0) so we moved
on to dereference inode->i_mode. But inode was NULL; From the calling
code we have:
/* Negative dentry, just create the file */
if (!path.dentry->d_inode) {
/*
* This write is needed to ensure that a
* ro->rw transition does not occur between
* the time when the file is created and when
* a permanent write count is taken through
* the 'struct file' in nameidata_to_filp().
*/
error = mnt_want_write(nd.path.mnt);
if (error)
goto exit_mutex_unlock;
error = __open_namei_create(&nd, &path, flag, mode);
if (error) {
mnt_drop_write(nd.path.mnt);
goto exit;
}
filp = nameidata_to_filp(&nd, open_flag);
if (IS_ERR(filp))
ima_counts_put(&nd.path,
acc_mode & (MAY_READ | MAY_WRITE |
MAY_EXEC));
Which I guess has some negative dentry logic the ima code isn't properly
accounting for. Mimi can you try vert that __open_namei_create
returning 0 ALWAYS means it's a positive dentry? If it isn't always a
positive figure out if the ima_counts_put() call is needed?
-Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-09-02 21:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-02 13:49 NULL pointer dereference Ciprian Docan
2009-09-02 15:59 ` Frans Pop
2009-09-02 21:08 ` Eric Paris
-- strict thread matches above, loose matches on Subject: below --
2003-01-02 11:28 Vitezslav Samel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox