From owner-freebsd-bugs@FreeBSD.ORG Mon Jun 9 09:40:06 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD75A1065675 for ; Mon, 9 Jun 2008 09:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B6B3A8FC1D for ; Mon, 9 Jun 2008 09:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m599e6lf060301 for ; Mon, 9 Jun 2008 09:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m599e632060300; Mon, 9 Jun 2008 09:40:06 GMT (envelope-from gnats) Date: Mon, 9 Jun 2008 09:40:06 GMT Message-Id: <200806090940.m599e632060300@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: rene.schickbauer@magnapowertrain.com Cc: Subject: Re: misc/124410: malloc exposes previously free'd memory X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rene.schickbauer@magnapowertrain.com List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2008 09:40:06 -0000 The following reply was made to PR misc/124410; it has been noted by GNATS. From: rene.schickbauer@magnapowertrain.com To: bug-followup@FreeBSD.org, rene.schickbauer@magnapowertrain.com Cc: Subject: Re: misc/124410: malloc exposes previously free'd memory Date: Mon, 9 Jun 2008 11:08:13 +0200 I forgot to mention: Yes, i know, there is an option for malloc() to automatically initialize memory to "0". But this is doesn't look like it's enough: For one thing, it looks like the user may override global setting (is unsetting an option possible?). According to the man-page, the memset() (if option is set) is done in malloc() instead directly in the kernel, and realloc() and reallocf() are not covered at all. Also, free()ing memory should wipe it for security reasons, for example it may help against the "RAM freezing hacks", in cases where the application has already free()'d but not malloc()'d security relevant data; see also