From patchwork Thu Dec  4 01:14:27 2008
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Scott Raynel <scottraynel@gmail.com>
X-Patchwork-Id: 5368
Received: from warlock.cs.waikato.ac.nz (warlock.cs.waikato.ac.nz
	[130.217.250.15])
	by open-mesh.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	mB41KNbn010108
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)
	for <b.a.t.m.a.n@open-mesh.net>; Thu, 4 Dec 2008 02:20:27 +0100
Received: from [192.107.171.51] (helo=dhcp-236.uni.crc.net.nz)
	by warlock.cs.waikato.ac.nz with esmtpsa
	(TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1L82nU-0005yh-69
	for b.a.t.m.a.n@open-mesh.net; Thu, 04 Dec 2008 14:14:28 +1300
Message-Id: <DFF8A357-1AF1-4F11-BE89-46DD131FA7FF@gmail.com>
From: Scott Raynel <scottraynel@gmail.com>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@open-mesh.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 4 Dec 2008 14:14:27 +1300
X-Mailer: Apple Mail (2.929.2)
Subject: [B.A.T.M.A.N.] [PATCH] batman-adv-kernelland: Fix memory corruption
	bug
X-BeenThere: b.a.t.m.a.n@open-mesh.net
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@open-mesh.net>
List-Id: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n.open-mesh.net>
List-Unsubscribe: <https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n>,
	<mailto:b.a.t.m.a.n-request@open-mesh.net?subject=unsubscribe>
List-Archive: <http://list.open-mesh.net/pipermail/b.a.t.m.a.n>
List-Post: <mailto:b.a.t.m.a.n@open-mesh.net>
List-Help: <mailto:b.a.t.m.a.n-request@open-mesh.net?subject=help>
List-Subscribe: <https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n>,
	<mailto:b.a.t.m.a.n-request@open-mesh.net?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2008 01:20:27 -0000

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 <scottraynel@gmail.com>



Cheers,
---
Scott Raynel
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

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) {