lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 24 Feb 2012 16:54:31 +0000
From:	"Latif, Faisal" <faisal.latif@...el.com>
To:	Jesper Juhl <jj@...osbits.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	"Hefty, Sean" <sean.hefty@...el.com>,
	Roland Dreier <roland@...nel.org>
Subject: RE: [PATCH] IB: Fix potential mem leak in schedule_nes_timer()

I do not approve this patch. 

The type field is always set to either NES_TIMER_TYPE_SEND or NES_TIMER_TYPE_CLOSE when schedule_nes_timer() is called. Even if we wanted to make sure the value of type is one or the other, proper patch can be just a if stmt to check the type before new_send allocation.

Thanks
Faisal


> -----Original Message-----
> From: linux-rdma-owner@...r.kernel.org [mailto:linux-rdma-
> owner@...r.kernel.org] On Behalf Of Jesper Juhl
> Sent: Monday, February 20, 2012 2:56 PM
> To: linux-kernel@...r.kernel.org
> Cc: linux-rdma@...r.kernel.org; Hal Rosenstock; Hefty, Sean; Roland
> Dreier; Latif, Faisal
> Subject: [PATCH] IB: Fix potential mem leak in schedule_nes_timer()
> 
> In drivers/infiniband/hw/nes/nes_cm.c::schedule_nes_timer(), if we do
> not take the true branch of either the
>   (type == NES_TIMER_TYPE_SEND)
> or
>   (type == NES_TIMER_TYPE_SEND)
> 'if' statements (which it looks like we potentially could since that
> enum can have other values), then we'll leak the memory allocated to
> 'new_send'.
> 
> This (admittedly, rather clumsy) patch addresses that issue by turning
> the two 'if's into 'if' 'else if' and then adding a 'else' branch
> where we note that we need to free the mem and then later, when we are
> done with it, does a conditional kfree() based on the bool we set in
> the 'else' branch.
> 
> I also removed a redundant variable ('was_timer_set').
> 
> Signed-off-by: Jesper Juhl <jj@...osbits.net>
> ---
>  drivers/infiniband/hw/nes/nes_cm.c |   15 ++++++++-------
>  1 files changed, 8 insertions(+), 7 deletions(-)
> 
>  Compile tested only.
> 
> diff --git a/drivers/infiniband/hw/nes/nes_cm.c
> b/drivers/infiniband/hw/nes/nes_cm.c
> index a4972ab..434a25b 100644
> --- a/drivers/infiniband/hw/nes/nes_cm.c
> +++ b/drivers/infiniband/hw/nes/nes_cm.c
> @@ -663,8 +663,8 @@ int schedule_nes_timer(struct nes_cm_node *cm_node,
> struct sk_buff *skb,
>  	unsigned long flags;
>  	struct nes_cm_core *cm_core = cm_node->cm_core;
>  	struct nes_timer_entry *new_send;
> +	bool free_new_send = false;
>  	int ret = 0;
> -	u32 was_timer_set;
> 
>  	new_send = kzalloc(sizeof(*new_send), GFP_ATOMIC);
>  	if (!new_send)
> @@ -688,9 +688,7 @@ int schedule_nes_timer(struct nes_cm_node *cm_node,
> struct sk_buff *skb,
>  			return -EINVAL;
>  		}
>  		cm_node->recv_entry = new_send;
> -	}
> -
> -	if (type == NES_TIMER_TYPE_SEND) {
> +	} else if (type == NES_TIMER_TYPE_SEND) {
>  		new_send->seq_num = ntohl(tcp_hdr(skb)->seq);
>  		atomic_inc(&new_send->skb->users);
>  		spin_lock_irqsave(&cm_node->retrans_list_lock, flags);
> @@ -714,15 +712,18 @@ int schedule_nes_timer(struct nes_cm_node
> *cm_node, struct sk_buff *skb,
>  				return ret;
>  			}
>  		}
> +	} else {
> +		free_new_send = true;
>  	}
> 
> -	was_timer_set = timer_pending(&cm_core->tcp_timer);
> -
> -	if (!was_timer_set) {
> +	if (!timer_pending(&cm_core->tcp_timer)) {
>  		cm_core->tcp_timer.expires = new_send->timetosend;
>  		add_timer(&cm_core->tcp_timer);
>  	}
> 
> +	if (free_new_send)
> +		kfree(new_send);
> +
>  	return ret;
>  }
> 
> --
> 1.7.9.1
> 
> 
> --
> Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
> Don't top-post http://www.catb.org/jargon/html/T/top-post.html
> Plain text mails only, please.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ