| 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
| ||
|
Message-ID: <alpine.LRH.2.00.1106282358450.14213@twin.jikos.cz> Date: Wed, 29 Jun 2011 00:00:08 +0200 (CEST) From: Jiri Kosina <jkosina@...e.cz> To: Ben Greear <greearb@...delatech.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: Question on debugging use-after-free memory issues. On Mon, 27 Jun 2011, Ben Greear wrote: > I have a case where deleted memory is being passed into an RPC callback. > I enabled SLUB memory poisoning and verified that the data pointed to > has 0x6b...6b value. > > Unfortunately, the rpc code is a giant maze of callbacks and I'm having > a difficult time figuring out where this data could be erroneously > deleted at. > > So first question: > > Given a pointer to memory, and with SLUB memory debuging on (and/or > other debugging options if applicable), is there a way to get any info > about where the memory was last deleted? > > Second: Any other suggestions for how to go about debugging this? > > I hit this problem under load after multiple hours, so just adding > printks in random places may not be feasible... First, this is not really a proper list for such questions. I'd propose kernel newbies community next time. Anyway, I'd propose to start with kmemcheck (see Documentation/kmemcheck.txt). It could pin-point the problemtic spot immediately (or it might not). -- Jiri Kosina SUSE Labs -- 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