Hey Scott, thank you very much for the fix! Can you confirm if this bug is related to https://dev.open-mesh.net/batman/ticket/86 ? This bug has very likely been caused by a memory corruption, but i couldn´t find where. (i have not experienced any kernel panics by this however ...).
Thanks, best regards
Simon
On Thu, Dec 04, 2008 at 02:14:27PM +1300, Scott Raynel wrote:
> Hi there,
>
> I've been spending some time tracking down a bug that's been causing
> memory corruption followed by random kernel panics. Thanks to the
> kernel's slab memory debugger I tracked it down to a kfree in send.c
> that was freeing a block of memory that had been written to past the
> end of its allocation.
>
> Turned out to be a simple typo, which I've fixed in the following
> patch. When resizing the packet_buff struct in batman_if, the new
> length was being updated but the old length was being used for the
> kmalloc(), causing something later to think it had more memory
> allocated to write to, hence writing past the end of the allocation.
>
> Signed-off-by: Scott Raynel <scottray...@gmail.com>
>
> Index: send.c
> ===================================================================
> --- send.c (revision 1105)
> +++ send.c (working copy)
> @@ -159,7 +159,7 @@
> if ((hna_local_changed) && (batman_if->if_num == 0)) {
>
> new_len = sizeof(struct batman_packet) + (num_hna *
> ETH_ALEN);
> - new_buf = kmalloc(batman_if->pack_buff_len, GFP_ATOMIC);
> + new_buf = kmalloc(new_len, GFP_ATOMIC);
>
> /* keep old buffer if kmalloc should fail */
> if (new_buf) {
>
>
> Cheers,
>
> --
> Scott Raynel
> WAND Network Research Group
> Department of Computer Science
> University of Waikato
> New Zealand
>
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> b.a.t.m....@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
signature.asc
Description: Digital signature
