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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 9 Jan 2019 23:24:44 +0800
From:   "Peng Wang" <rocking@....edu.cn>
To:     "'Matthew Wilcox'" <willy@...radead.org>
Cc:     <cl@...ux.com>, <penberg@...nel.org>, <rientjes@...gle.com>,
        <iamjoonsoo.kim@....com>, <akpm@...ux-foundation.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mm/slub.c: re-randomize random_seq if necessary


On Wednesday, January 9, 2019 8:14 PM, Matthew Wilcox wrote:
> On Wed, Jan 09, 2019 at 05:06:27PM +0800, Peng Wang wrote:
> > calculate_sizes() could be called in several places
> > like (red_zone/poison/order/store_user)_store() while
> > random_seq remains unchanged.
> >
> > If random_seq is not NULL in calculate_sizes(), re-randomize it.
> 
> Why do we want to re-randomise the slab at these points?

At these points, s->size might change,
but random_seq still use the old size and not updated.

When doing shuffle_freelist() in allocat_slab(),
old next object offset would be used. 

    idx = s->random_seq[*pos];

One possible case:

s->size gets smaller, then number of objects in a slab gets bigger.
The size of s->random_seq array should be bigger but not updated.
In next_freelist_entry(), *pos might exceed the s->random_seq.

When we get zero value from s->random_seq[*pos] twice after exceeding,
BUG_ON(object == fp) would be triggered in set_freepointer().


Powered by blists - more mailing lists