| Date | Sat, 16 May 2009 16:44:28 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.6.30-rc6: Reported regressions from 2.6.29 |
| |
On Sat, 16 May 2009, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13329 > Subject : cifs_close: NULL pointer dereference > Submitter : Luca Tettamanti <kronos.it@gmail.com> > Date : 2009-05-16 16:28 (1 days old) > References : http://marc.info/?l=linux-kernel&m=124249133701702&w=4
The code in this one decodes to
0: 89 ef mov %ebp,%edi 2: 45 31 e4 xor %r12d,%r12d 5: e8 f3 63 e7 df callq 0xffffffffdfe763fd a: 41 bd 0a 00 00 00 mov $0xa,%r13d 10: 48 c7 c7 c4 6b 61 a0 mov $0xffffffffa0616bc4,%rdi 17: e8 b3 7f e7 df callq 0xffffffffdfe77fcf 1c: 48 8b 53 10 mov 0x10(%rbx),%rdx 20: 48 8b 43 18 mov 0x18(%rbx),%rax 24: 48 c7 c7 c4 6b 61 a0 mov $0xffffffffa0616bc4,%rdi 2b:* 48 89 42 08 mov %rax,0x8(%rdx) <-- trapping instruction 2f: 48 89 10 mov %rdx,(%rax) 32: 48 c7 43 18 00 02 20 movq $0x200200,0x18(%rbx) 39: 00 3a: 48 8b 13 mov (%rbx),%rdx
which seems to match (modulo normal compiler issues):
movq -56(%rbp), %rdi # %sfp, call mutex_unlock # movq $GlobalSMBSeslock, %rdi #, call _write_lock # movq 16(%rbx), %rdx # <variable>.flist.next, D.47095 movq 24(%rbx), %rax # <variable>.flist.prev, D.47094 movq %rax, 8(%rdx) # D.47094, <variable>.prev movq %rdx, (%rax) # D.47095, <variable>.next movq $2097664, 24(%rbx) #, <variable>.flist.prev movq (%rbx), %rdx # <variable>.tlist.next, D.47099
which I think ends up being this code:
mutex_unlock(&pSMBFile->lock_mutex); write_lock(&GlobalSMBSeslock); list_del(&pSMBFile->flist);
ie 'pSMBFile->flist.next' looks to be zero. Either uninitialized or perhaps a use-after-free thing..
We have commit 90e4ee5d31 "[CIFS] Fix double list addition in cifs posix open code" that touches exactly that 'flist' thing, and removes the thing that adds it to the list because it's _claimed_ to be a "double add". It probably wasn't.
The bug reporter says:
> The machine is running kernel from git (1d80cac - almost rc6)
and that 1d80cac is _after_ 90e4ee5d31. So I do think 90e4ee5d31 is buggy.
Linus
|