linux-kernel - Re: kmemcheck caught read from freed memory (cfq_free_io

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]

Message-ID: <Pine.LNX.4.64.0804021924280.6839@sbz-30.cs.Helsinki.FI>
Date:	Wed, 2 Apr 2008 19:32:26 +0300 (EEST)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	Vegard Nossum <vegard.nossum@...il.com>
cc:	paulmck@...ux.vnet.ibm.com, Ingo Molnar <mingo@...e.hu>,
	Jens Axboe <jens.axboe@...cle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kmemcheck caught read from freed memory (cfq_free_io_context)

Hi Vegard,

On Wed, Apr 2, 2008 at 6:08 PM, Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > Would the following be an appropriate fix?  It seems to me to be in
> > the same spirit as the existing check for s->ctor.
 
On Wed, 2 Apr 2008, Vegard Nossum wrote:
> In my opinion, no.
> 
> It would fix the false positives, but would in fact also hide cases
> such as this one with cfq, e.g. the real cases of mis-use.

Yes, but we might as well put Paul's patch in now and remove that later 
when we have a proper fix, no?

On Wed, 2 Apr 2008, Vegard Nossum wrote:
> Peter Zijlstra suggested this:
> > It would have to register an call_rcu callback itself in order to mark
> > it freed - and handle the race with the object being handed out again.
> 
> I will try to look into this -- for now, I need to understand RCU
> first (I've seen your LWN articles -- great work! :-))

Well, maybe we can add two new states: RCU_FREED and RCU_VALIDATED? The 
object is flagged with the first one as soon as an object is handed over 
to kmem_cache_free() and the latter needs to hook to the validation phase 
of RCU (how is that done btw?). Then kmemcheck could even give a better 
error message: "RCU-freed object used without validation."

And with delayed free for kmemcheck we discussed before, we'd hold on to 
the objects long enough to actually see these error conditions.

			Pekka
--
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/