Re: 2.6.30-rc6: Reported regressions from 2.6.29

From: Linus Torvalds
Date: Sat May 16 2009 - 19:46:26 EST




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@xxxxxxxxx>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/