Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Feb 2020 16:15:44 +0100
From: Andrey Konovalov <>
To: zerons <>, Alexander Popov <>
Cc:, Shawn <>,
Subject: Re: Maybe inappropriate use BUG_ON() in CONFIG_SLAB_FREELIST_HARDENED

On Thu, Feb 13, 2020 at 4:43 PM zerons <> wrote:
> Hi,
> In slub.c(,
> 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

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!

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.