linux-kernel - RE: [PATCH] kasan: improve double-free detection

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: <20E775CA4D599049A25800DE5799F6DD1F624B08@G4W3225.americas.hpqcorp.net>
Date:	Wed, 4 May 2016 20:13:07 +0000
From:	"Luruo, Kuthonuzo" <kuthonuzo.luruo@....com>
To:	Dmitry Vyukov <dvyukov@...gle.com>
CC:	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Alexander Potapenko <glider@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	kasan-dev <kasan-dev@...glegroups.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] kasan: improve double-free detection

> >> I missed that Alexander already landed patches that reduce header size
> >> to 16 bytes.
> >> It is not OK to increase them again. Please leave state as bitfield
> >> and update it with CAS (if we introduce helper functions for state
> >> manipulation, they will hide the CAS loop, which is nice).
> >>
> >
> > Available CAS primitives/compiler do not support CAS with bitfield. I propose
> > to change kasan_alloc_meta to:
> >
> > struct kasan_alloc_meta {
> >         struct kasan_track track;
> >         u16 size_delta;         /* object_size - alloc size */
> >         u8 state;                    /* enum kasan_state */
> >         u8 reserved1;
> >         u32 reserved2;
> > }
> >
> > This shrinks _used_ meta object by 1 byte wrt the original. (btw, patch v1 does
> > not increase overall alloc meta object size). "Alloc size", where needed, is
> > easily calculated as a delta from cache->object_size.
> 
> 
> What is the maximum size that slab can allocate?
> I remember seeing slabs as large as 4MB some time ago (or did I
> confuse it with something else?). If there are such large objects,
> that 2 bytes won't be able to hold even delta.
> However, now on my desktop I don't see slabs larger than 16KB in
> /proc/slabinfo.

max size for SLAB's slab is 32MB; default is 4MB. I must have gotten confused by
SLUB's 8KB limit. Anyway, new kasan_alloc_meta in patch V2:

struct kasan_alloc_meta {
        struct kasan_track track;
        union {
                u8 lock;
                struct {
                        u32 dummy : 8;
                        u32 size_delta : 24;    /* object_size - alloc size */
                };
        };
        u32 state : 2;                          /* enum kasan_alloc_state */
        u32 unused : 30;
};

This uses 2 more bits than current, but given the constraints I think this is
close to optimal.

Kuthonuzo