From patchwork Thu Feb 7 10:55:36 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Borkmann X-Patchwork-Id: 218891 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 291AF2C00DC for ; Thu, 7 Feb 2013 21:55:52 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758112Ab3BGKzr (ORCPT ); Thu, 7 Feb 2013 05:55:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59041 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757949Ab3BGKzl (ORCPT ); Thu, 7 Feb 2013 05:55:41 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r17AtegU007495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Feb 2013 05:55:40 -0500 Received: from localhost (vpn1-4-101.ams2.redhat.com [10.36.4.101]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r17AtdAA028992; Thu, 7 Feb 2013 05:55:39 -0500 From: Daniel Borkmann To: vyasevich@gmail.com Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-sctp@vger.kernel.org Subject: [PATCH net 1/2] net: sctp: sctp_auth_make_key_vector: fix undefined ref-count behaviour Date: Thu, 7 Feb 2013 11:55:36 +0100 Message-Id: <5eff11271160e84c7fc2d97b81161b1ae7be4a6e.1360231701.git.dborkman@redhat.com> In-Reply-To: References: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org In sctp_auth_make_key_vector(), a sctp_auth_bytes structure is being allocated, but without setting its object reference count, thus it's initialized with a random value from the memory, which can lead to i) premature free's of this object when being put (with possible subsequent kernel panics), or ii) memory leaks when refcount has a high value. Fix this by using the appropriate sctp_auth_create_key() allocator, which performs sanity checks, sets length and the refcount, as similar done in sctp_auth_asoc_set_secret() and others. This bug seems to be present since 2007 (1f485649f529: Implement SCTP-AUTH internals). Signed-off-by: Daniel Borkmann --- net/sctp/auth.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/sctp/auth.c b/net/sctp/auth.c index 159b9bc..55f1b06 100644 --- a/net/sctp/auth.c +++ b/net/sctp/auth.c @@ -205,12 +205,10 @@ static struct sctp_auth_bytes *sctp_auth_make_key_vector( if (chunks) len += ntohs(chunks->param_hdr.length); - new = kmalloc(sizeof(struct sctp_auth_bytes) + len, gfp); + new = sctp_auth_create_key(len, gfp); if (!new) return NULL; - new->len = len; - memcpy(new->data, random, ntohs(random->param_hdr.length)); offset += ntohs(random->param_hdr.length);