On Fri, 1 Jun 2007 15:20:05 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Jun 2007, Andrew Morton wrote: > > > If slab was smart enough, it would have poisoned those 8 bytes to some > > known pattern, and then checked that they still had that pattern when the > > memory got freed again. > > So this is new feature request? > > > But it isn't smart enough, so the bug went undetected. > > I should make SLUB put poisoning values in unused areas of a kmalloced > object? hm, I hadn't thought of it that way actually. I was thinking it was specific to kmalloc(0) but as you point out, the situation is generalisable. Yes, if someone does kmalloc(42) and we satisfy the allocation from the size-64 slab, we should poison and then check the allegedly-unused 22 bytes. Please ;) (vaguely stunned that we didn't think of doing this years ago). It'll be a large patch, I expect? Actually, I have this vague memory that slab would take that kmalloc(42) and would then return kmalloc(64)+22, so the returned memory is "right-aligned". This way the existing overrun-detection is applicable to all kmallocs. Maybe I dreamed it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
