From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Norris Subject: Re: [PATCH 2/4] test: firmware_class: add asynchronous request trigger Date: Wed, 9 Dec 2015 14:12:20 -0800 Message-ID: <20151209221220.GB51175@google.com> References: <1449628714-66641-1-git-send-email-computersforpeace@gmail.com> <1449628714-66641-2-git-send-email-computersforpeace@gmail.com> <20151209214843.GA51175@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Kees Cook Cc: Shuah Khan , Greg Kroah-Hartman , Ming Lei , LKML , Linux API , "Luis R. Rodriguez" List-Id: linux-api@vger.kernel.org On Wed, Dec 09, 2015 at 02:05:17PM -0800, Kees Cook wrote: > On Wed, Dec 9, 2015 at 1:48 PM, Brian Norris > wrote: > > I was also thinking, since use-after-free isn't necessarily immediately > > obvious (this worked fine in my testing), that maybe we could poison the > > buffer before kfree()'ing? Like: > > > > name = ...; > > len = strlen(name); > > > > ... > > > > rc = request_firmware_nowait(...); > > if (rc) { > > pr_info("..."); > > kfree(name); > > goto out; > > } > > /* > > * Clear out the name, to test for race conditions with the > > * async request > > */ > > memset(name, 0, len); > > kfree(name); > > Hrm, well, I'm not against it, but I think running under KASan is > probably the right way to find these things. But, might as well, just > to notice any regressions. Fair enough. The memset probably isn't that useful. BTW, one reason I didn't notice my use-after-free is that the "use" was under an error path that I didn't exercise. I need to remember to turn my brain back on. Brian