Bug 34732
| Summary: | BUG: Null pointer dereference at fuse_dentry_revalidate | ||
|---|---|---|---|
| Product: | File System | Reporter: | Witold Baryluk (witold.baryluk+kernel) |
| Component: | VFS | Assignee: | fs_vfs |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | florian, maciej.rutecki, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.39-rc6-00569-g5895198-dirty | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 32012 | ||
| Attachments: | kernel config | ||
|
Description
Witold Baryluk
2011-05-09 13:09:16 UTC
Created attachment 56992 [details]
kernel config
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 9 May 2011 13:09:18 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=34732 > > Summary: BUG: unable to handle kernel NULL pointer dereference > at 00000020 > Product: File System > Version: 2.5 > Kernel Version: 2.6.39-rc6-00569-g5895198-dirty > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: VFS > AssignedTo: fs_vfs@kernel-bugs.osdl.org > ReportedBy: baryluk@smp.if.uj.edu.pl > Regression: No I assume this is a post-2.6.38 regression. I can't begin to think what might cause this. Is it reproducible? > > > When ressuming from suspend I got: > > [168878.711615] IP: [<c1286822>] fuse_dentry_revalidate+0x82/0x320 > [168878.711748] *pdpt = 000000002deb5001 *pde = 0000000000000000 > [168878.711875] Oops: 0000 [#1] PREEMPT SMP > [168878.711971] last sysfs file: > /sys/devices/virtual/net/teredo/statistics/collisions > [168878.712012] Modules linked in: ufs vfat fat isofs vboxnetadp vboxnetflt > nfsd ebtable_nat ebtables lib80211_crypt_ccmp uinput xcbc hdaps tp_smapi > thinkpad_ec radeonfb fb_ddc radeon ttm drm_kms_helper drm ipw2200 intel_agp > intel_gtt libipw i2c_algo_bit i2c_i801 agpgart rng_core cfbfillrect > cfbcopyarea > cfbimgblt video raid10 raid1 raid0 linear md_mod vboxdrv > [168878.712012] > [168878.712012] Pid: 25504, comm: alarmclock Tainted: G W > 2.6.39-rc6-00569-g5895198-dirty #22 IBM 2669UYD/2669UYD > [168878.712012] EIP: 0060:[<c1286822>] EFLAGS: 00010282 CPU: 0 > [168878.712012] EIP is at fuse_dentry_revalidate+0x82/0x320 > [168878.712012] EAX: c9a96080 EBX: 00000000 ECX: 028313a5 EDX: 00000000 > [168878.712012] ESI: 02295a2d EDI: 00000001 EBP: f4035d18 ESP: f4035c68 > [168878.712012] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > [168878.712012] Process alarmclock (pid: 25504, ti=f4034000 task=ce2587e0 > task.ti=f4034000) > [168878.712012] Stack: > [168878.712012] 00000000 00000002 00000000 00000000 c115f708 ce2587e0 > 00000054 > cc3ba5fc > [168878.712012] c9a96080 00000054 c115f790 f4035cbc 00000246 00000001 > c178e7cd > 00000246 > [168878.712012] f4035cb0 c1a28f30 cc3ba5fc 00000054 cc3ba5fc f4035d04 > c115f7a9 > 00000002 > [168878.712012] Call Trace: > [168878.712012] [<c115f708>] ? __d_lookup+0xe8/0x230 > [168878.712012] [<c115f790>] ? __d_lookup+0x170/0x230 > [168878.712012] [<c178e7cd>] ? sub_preempt_count.part.170+0x4d/0x90 > [168878.712012] [<c115f7a9>] ? __d_lookup+0x189/0x230 > [168878.712012] [<c115f620>] ? __d_lookup_rcu+0x1f0/0x1f0 > [168878.712012] [<c115f87c>] ? d_lookup+0x2c/0x50 > [168878.712012] [<c115239a>] __lookup_hash.part.11+0x4a/0x90 > [168878.712012] [<c11524c4>] lookup_one_len+0xe4/0x170 > [168878.712012] [<c1225fed>] ecryptfs_lookup+0xfd/0x1b0 > [168878.712012] [<c11518f7>] d_alloc_and_lookup+0x37/0x70 > [168878.712012] [<c1152e2b>] do_lookup+0x18b/0x250 > [168878.712012] [<c12aa50d>] ? security_inode_permission+0x1d/0x30 > [168878.712012] [<c115407b>] link_path_walk+0x16b/0x900 > [168878.712012] [<c11554be>] path_lookupat+0x4e/0x740 > [168878.712012] [<c1117a11>] ? might_fault+0x91/0xa0 > [168878.712012] [<c11179cb>] ? might_fault+0x4b/0xa0 > [168878.712012] [<c132d3f8>] ? strncpy_from_user+0x38/0x70 > [168878.712012] [<c1155bdc>] do_path_lookup+0x2c/0xb0 > [168878.712012] [<c115602b>] user_path_at+0x3b/0x70 > [168878.712012] [<c178e430>] ? do_page_fault+0x1d0/0x520 > [168878.712012] [<c114c1f9>] vfs_fstatat+0x59/0x90 > [168878.712012] [<c114c250>] vfs_lstat+0x20/0x30 > [168878.712012] [<c114c516>] sys_lstat64+0x16/0x30 > [168878.712012] [<c178e7cd>] ? sub_preempt_count.part.170+0x4d/0x90 > [168878.712012] [<c10bbcac>] ? audit_syscall_entry+0x2ac/0x2d0 > [168878.712012] [<c132ce98>] ? trace_hardirqs_on_thunk+0xc/0x10 > [168878.712012] [<c17921d8>] sysenter_do_call+0x12/0x38 > [168878.712012] Code: 01 00 00 00 8b 5d f4 89 d0 8b 75 f8 8b 7d fc 89 ec 5d > c3 > 8d b6 00 00 00 00 0f 86 62 01 00 00 8b 85 70 ff ff ff 31 d2 85 c0 74 d9 <f6> > 43 > 20 40 ba f6 ff ff ff 75 ce 8b 95 70 ff ff ff 8b 42 10 8b > [168878.712012] EIP: [<c1286822>] fuse_dentry_revalidate+0x82/0x320 SS:ESP > 0068:f4035c68 > [168878.712012] CR2: 0000000000000020 > [168878.784616] ---[ end trace 7d87d515c294ab86 ]--- > > > # uname -a > Linux sredniczarny 2.6.39-rc6-00569-g5895198-dirty #22 SMP PREEMPT Thu May 5 > 20:10:35 CEST 2011 i686 GNU/Linux > # > > # (dirty only because of modified Makefile) > > compiled using gcc 4.6.0-3 on i386. > > # cat /proc/mounts > rootfs / rootfs rw 0 0 > none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 > none /proc proc rw,nosuid,nodev,noexec,relatime 0 0 > none /dev devtmpfs rw,relatime,size=1024196k,nr_inodes=216465,mode=755 0 0 > none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 > 0 > /dev/mapper/sredniczarny-root / ext4 > rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0 > tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0 > varrun /var/run tmpfs rw,nosuid,relatime,mode=755 0 0 > varlock /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0 > tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 > varrun /var/run tmpfs rw,nosuid,relatime,mode=755 0 0 > varlock /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0 > /dev/sda1 /boot ext3 > rw,relatime,errors=continue,commit=5,barrier=1,data=ordered 0 0 > /dev/mapper/sredniczarny-tmp /tmp ext4 > rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0 > /dev/mapper/sredniczarny-usr /usr ext4 > rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0 > /dev/mapper/sredniczarny-var /var ext4 > rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0 > /dev/mapper/sredniczarny-home /home ext4 > rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0 > fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 > sctank2 /sctank2 fuse rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Books /sctank2/Books fuse > rw,relatime,user_id=0,group_id=0,allow_other > 0 0 > sctank2/Dane /sctank2/Dane fuse rw,relatime,user_id=0,group_id=0,allow_other > 0 > 0 > sctank2/Download /sctank2/Download fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Filmy /sctank2/Filmy fuse > rw,relatime,user_id=0,group_id=0,allow_other > 0 0 > sctank2/Muzyka /sctank2/Muzyka fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/MuzykaMod /sctank2/MuzykaMod fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Projekty /sctank2/Projekty fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Studia /sctank2/Studia fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/System /sctank2/System fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users /sctank2/Users fuse > rw,relatime,user_id=0,group_id=0,allow_other > 0 0 > sctank2/Users/baryluk /sctank2/Users/baryluk fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users/baryluk-www /sctank2/Users/baryluk-www fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users/baryluk-www/osis-attachments > /sctank2/Users/baryluk-www/osis-attachments fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users/baryluk/.Private /sctank2/Users/baryluk/.Private fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users/baryluk/.wine_drive_c /sctank2/Users/baryluk/.wine_drive_c fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/Users/scpguest /sctank2/Users/scpguest fuse > rw,relatime,user_id=0,group_id=0,allow_other 0 0 > sctank2/VMs /sctank2/VMs fuse rw,relatime,user_id=0,group_id=0,allow_other 0 > 0 > binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc > rw,nosuid,nodev,noexec,relatime 0 0 > cgroup /sys/fs/cgroup cgroup rw,relatime,cpu 0 0 > cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0 > cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0 > nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 > /dev/sr0 /media/cdrom0 iso9660 ro,relatime 0 0 > /home/baryluk/.Private /home/baryluk/Private ecryptfs > > rw,relatime,ecryptfs_fnek_sig=ca3ffc95d0fb0164,ecryptfs_sig=e4765846879e2bfb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 > 0 0 > # > > .config attached. > On Mon May 09, 2011 at 12:07:07PM -0700, Andrew Morton <akpm@linux-foundation.org> wrote: > I assume this is a post-2.6.38 regression. > > I can't begin to think what might cause this. Is it reproducible? I'd bet on e7c0a167860620bd2938366896964f729ddaeaaa eCryptfs uses lookup_one_len() to lookup lower files, which means that the lower filesystem's d_revalidate() can get a NULL nameidata pointer. That commit dropped the check on nd before dereferencing it. Tyler Sorry for answering in web-interface (I have network issues on my mailserver hosting side), hope it will work. > assume this is a post-2.6.38 regression. ecryptfs on fuse do not worked always, but I do not remember if I got any kernel oops before (more probable was getting -EIO when trying to open/read/write file). So yes, this is regression. No i get pretty heavy oops error on all opened terminals. I never before had this (or at least not in last year). > I can't begin to think what might cause this. Is it reproducible? Yes, it is reproducible - it happens early after reboot, few minutes after booting and logging into gnome. Probably can be reproduced easier by accessing ecrypts files earlier from console. I also happens on the 2.6.39-rc6-00585-gc2bf807-dirty (few commits later). It probably is ecryptfs problem (because it mounts after user logins in). Note. Underlying (encrypted) files for ecrypts are also on fuse filesystem! oops message is now slightly different (check stacktrace), on 2.6.39-rc6-00585-gc2bf807-dirty [ 1340.710879] BUG: unable to handle kernel NULL pointer dereference at 00000020 [ 1340.711046] IP: [<c1286822>] fuse_dentry_revalidate+0x82/0x320 [ 1340.711175] *pdpt = 000000002bd0c001 *pde = 0000000000000000 [ 1340.711300] Oops: 0000 [#1] PREEMPT SMP [ 1340.711396] last sysfs file: /sys/devices/virtual/net/vboxnet0/statistics/collisions [ 1340.711547] Modules linked in: isofs udf crc_itu_t vboxnetadp vboxnetflt nfsd ebtable_nat ebtables lib80211_crypt_ccmp uinput xcbc hdaps tp_smapi thinkpad_ec radeonfb fb_ddc radeon ttm drm_kms_helper drm ipw2200 i2c_algo_bit intel_agp intel_gtt i2c_i801 cfbfillrect libipw rng_core cfbcopyarea agpgart video cfbimgblt raid10 raid1 raid0 linear md_mod vboxdrv [ 1340.712012] [ 1340.712012] Pid: 10189, comm: updatedb.mlocat Tainted: G W 2.6.39-rc6-00585-gc2bf807-dirty #24 IBM 2669UYD/2669UYD [ 1340.712012] EIP: 0060:[<c1286822>] EFLAGS: 00010282 CPU: 0 [ 1340.712012] EIP is at fuse_dentry_revalidate+0x82/0x320 [ 1340.712012] EAX: ec7d5c80 EBX: 00000000 ECX: 0003f851 EDX: 00000000 [ 1340.712012] ESI: 00021094 EDI: 00000001 EBP: ebf37d78 ESP: ebf37cc8 [ 1340.712012] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 1340.712012] Process updatedb.mlocat (pid: 10189, ti=ebf36000 task=e8c028e0 task.ti=ebf36000) [ 1340.712012] Stack: [ 1340.712012] 00000000 00000002 00000000 00000000 e8c02d98 00000001 00000054 ece17080 [ 1340.712012] ec7d5c80 00000054 c115f780 ebf37d1c 00000246 00000001 c178e80d 00000246 [ 1340.712012] ebf37d10 c1a28f30 ece17080 00000054 ece17080 ebf37d64 c115f799 00000002 [ 1340.712012] Call Trace: [ 1340.712012] [<c115f780>] ? __d_lookup+0x170/0x230 [ 1340.712012] [<c178e80d>] ? sub_preempt_count.part.170+0x4d/0x90 [ 1340.712012] [<c115f799>] ? __d_lookup+0x189/0x230 [ 1340.712012] [<c115f610>] ? __d_lookup_rcu+0x1f0/0x1f0 [ 1340.712012] [<c115f86c>] ? d_lookup+0x2c/0x50 [ 1340.712012] [<c115238a>] __lookup_hash.part.11+0x4a/0x90 [ 1340.712012] [<c11524b4>] lookup_one_len+0xe4/0x170 [ 1340.712012] [<c1225fed>] ecryptfs_lookup+0xfd/0x1b0 [ 1340.712012] [<c11518e7>] d_alloc_and_lookup+0x37/0x70 [ 1340.712012] [<c1152e1b>] do_lookup+0x18b/0x250 [ 1340.712012] [<c11555a5>] path_lookupat+0x145/0x740 [ 1340.712012] [<c11179f1>] ? might_fault+0x91/0xa0 [ 1340.712012] [<c11179ab>] ? might_fault+0x4b/0xa0 [ 1340.712012] [<c132d3f8>] ? strncpy_from_user+0x38/0x70 [ 1340.712012] [<c1155bcc>] do_path_lookup+0x2c/0xb0 [ 1340.712012] [<c115601b>] user_path_at+0x3b/0x70 [ 1340.712012] [<c114c1e9>] vfs_fstatat+0x59/0x90 [ 1340.712012] [<c114c240>] vfs_lstat+0x20/0x30 [ 1340.712012] [<c114c506>] sys_lstat64+0x16/0x30 [ 1340.712012] [<c115185a>] ? path_put+0x1a/0x20 [ 1340.712012] [<c10bbcac>] ? audit_syscall_entry+0x2ac/0x2d0 [ 1340.712012] [<c132ce98>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 1340.712012] [<c1792218>] sysenter_do_call+0x12/0x38 [ 1340.712012] Code: 01 00 00 00 8b 5d f4 89 d0 8b 75 f8 8b 7d fc 89 ec 5d c3 8d b6 00 00 00 00 0f 86 62 01 00 00 8b 85 70 ff ff ff 31 d2 85 c0 74 d9 <f6> 43 20 40 ba f6 ff ff ff 75 ce 8b 95 70 ff ff ff 8b 42 10 8b [ 1340.712012] EIP: [<c1286822>] fuse_dentry_revalidate+0x82/0x320 SS:ESP 0068:ebf37cc8 [ 1340.712012] CR2: 0000000000000020 [ 1340.763907] ---[ end trace efa1f8dc8f63a330 ]--- # ls -l /home/baryluk/.Private lrwxrwxrwx. 1 baryluk baryluk 31 2009-12-08 /home/baryluk/.Private -> /sctank2/Users/baryluk/.Private # mount | grep '/sctank2/Users/baryluk/.Private' sctank2/Users/baryluk/.Private on /sctank2/Users/baryluk/.Private type fuse (rw,allow_other) # Tyler Hicks <tyhicks@linux.vnet.ibm.com> writes: > On Mon May 09, 2011 at 12:07:07PM -0700, Andrew Morton > <akpm@linux-foundation.org> wrote: >> I assume this is a post-2.6.38 regression. >> >> I can't begin to think what might cause this. Is it reproducible? > > I'd bet on e7c0a167860620bd2938366896964f729ddaeaaa > > eCryptfs uses lookup_one_len() to lookup lower files, which means that > the lower filesystem's d_revalidate() can get a NULL nameidata pointer. > That commit dropped the check on nd before dereferencing it. Looks like you hit the nail right on the head. Following patch should fix it. Thanks, Miklos commit d24339059d640f108c08ba99ef30e3bafa10f8e4 Author: Miklos Szeredi <mszeredi@suse.cz> Date: Tue May 10 17:35:58 2011 +0200 fuse: fix oops in revalidate when called with NULL nameidata Some cases (e.g. ecryptfs) can call ->dentry_revalidate with NULL nameidata. https://bugzilla.kernel.org/show_bug.cgi?id=34732 Tyler Hicks pointed out that this bug was introduced by commit e7c0a16786 "fuse: make fuse_dentry_revalidate() RCU aware" Reported-by: Witold Baryluk <baryluk@smp.if.uj.edu.pl> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index c6ba49b..b32eb29 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -174,7 +174,7 @@ static int fuse_dentry_revalidate(struct dentry *entry, struct nameidata *nd) if (!inode) return 0; - if (nd->flags & LOOKUP_RCU) + if (nd && (nd->flags & LOOKUP_RCU)) return -ECHILD; fc = get_fuse_conn(inode); Fixed by commit d24339059d640f108c08ba99ef30e3bafa10f8e4 . |