Date: Mon, 9 Jun 2008 02:42:40 -0700 From: "Garrett Cooper" <yanefbsd@gmail.com> To: rene.schickbauer@magnapowertrain.com Cc: freebsd-bugs@freebsd.org Subject: Re: misc/124410: malloc exposes previously free'd memory Message-ID: <7d6fde3d0806090242r4f2c8a54r4dddf3a47a919e8a@mail.gmail.com> In-Reply-To: <200806090940.m599e632060300@freefall.freebsd.org> References: <200806090940.m599e632060300@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 9, 2008 at 2:40 AM, <rene.schickbauer@magnapowertrain.com> wrote: > 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 > <http://www.hackaday.com/2008/02/21/breaking-disk-encryption-with-ram-dumps/>; Rene, Could you provide more info, such as CFLAGS used, CPUTYPE, and gcc --version please? Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d0806090242r4f2c8a54r4dddf3a47a919e8a>