On Thu, Feb 13, 2020 at 4:43 PM zerons <zeronsaxm@xxxxxxxxx> wrote: > > Hi, > > In slub.c(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/slub.c?h=v5.4.19#n305), > for SLAB_FREELIST_HARDENED, an extra detection of the double free bug has been added. > > This patch can (maybe only) detect something like this: kfree(a) kfree(a). > However, it does nothing when another process calls kfree(b) between the two kfree above. > > The problem is, if the panic_on_oops option is not set(Ubuntu 16.04/18.04 default option), > for a bug which kfree an object twice in a row, if another process can preempt the process > triggered this bug and then call kmalloc() to get the object, the patch doesn't work. > > Case 0: failure race > Process A: > kfree(a) > kfree(a) > the patch could terminate Process A. > > Case 1: race done > Process A: > kfree(a) > Process B: > kmalloc() -> a > Process A: > kfree(a) > the patch does nothing. > > The attacker can check the return status of process A to see if the race is done. > > Without this extra detection, the kernel could be unstable while the attacker > trying to do the race. > In my opinion, this patch can somehow help attacker exploit this kind of bugs > more reliable. +Alexander Popov, who is the author of the double free check in SLAB_FREELIST_HARDENED. Ah, so as long as the double free happens in a user process context, you can retry triggering it until you succeed in winning the race to reallocate the object (without causing slab freelist corruption, as it would have had happened before SLAB_FREELIST_HARDENED). Nice idea!
