Re: [git pull] Input update for 2.6.17

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 27 Jun 2006, Linus Torvalds wrote:
>
>	slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten
	...
> 	 dd977458: redzone 1:0x5a5a5a5a, redzone 2:0x170fc2a5.

Ok, it's definitely repeatable, although with small variations.

Now, in verify_redzone_free(), the redzone values _should_ have been 
RED_ACTIVE (which is 0x170FC2A5), so here the end-of-zone marker is ok, 
but the beginning has been overwritten with the normal kmalloc poison 
bytes (5a).

In the second version, I got:


	slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten
	 <c0103d31> show_trace+0xd/0x10  <c0104317> dump_stack+0x19/0x1b
	 <c015c5a8> __slab_error+0x17/0x1c  <c015c657> cache_free_debugcheck+0xaa/0x181
	 <c015cc61> kfree+0x75/0xaa  <df0d5146> hci_usb_close+0xbf/0x11d [hci_usb]
	 <df0d51cb> hci_usb_disconnect+0x27/0x67 [hci_usb]  <c02ab0c7> usb_unbind_interface+0x37/0x6e
	 <c024276f> __device_release_driver+0x63/0x79  <c02429c1> device_release_driver+0x2e/0x3e
	 <c02420b8> bus_remove_device+0x7e/0x8e  <c024104a> device_del+0x115/0x149
	 <c02a96f0> usb_disable_device+0xca/0x12d  <c02a5617> usb_disconnect+0x9d/0x117
	 <c02a676e> hub_thread+0x5d4/0xd8a  <c0132ec1> kthread+0xc5/0xf1
	 <c0101005> kernel_thread_helper+0x5/0xb 
	d570528c: redzone 1:0x5a5a5a5a, redzone 2:0x5a2cf071.

ie now "redzone 2" (which again should be RED_ACTIVE: 0x170FC2A5) is 
actually RED_INACTIVE (0x5A2CF071), which means that the thing basically 
got free'd twice (and corrupted in between).

So I think "hci_usb_close()" is freeing a pointer that it (or somebody 
else) already freed once, and depending on what has happened in the 
meantime to it, it's either allocated by somebody else, or got freed 
again. 

It seems to be inside hci_usb_unlink_urbs() (which has been inlined).

I _think_ it's the

                        kfree(urb->transfer_buffer);

in the "released completed requests" loop. That's if I read the assembly 
right.. (and I'm pretty sure I do - it's just before releasing the urb 
itself which ends up being just another kfree()).

Anyway, "urb->transfer_buffer" was initialized with

	urb->transfer_buffer = skb->data;

and I'm pretty damn sure you're supposed to just kfree() it.

So Marcel, I think this is a hci_usb.c bug. But I'm not able to fix it, 
unless the fix is to just remove that kfree entirely.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux