archive mirror
 help / color / mirror / Atom feed
From: Alexander Popov <>
To: Kees Cook <>
Cc: Christopher Lameter <>,
	Matthew Wilcox <>,
	Pekka Enberg <>,
	David Rientjes <>,
	Joonsoo Kim <>,
	Andrew Morton <>,
	Linux-MM <>,
	LKML <>,
Subject: Re: [PATCH 1/1] mm/slub.c: add a naive detection of double free or corruption
Date: Wed, 19 Jul 2017 11:38:57 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 18.07.2017 23:04, Kees Cook wrote:
> On Tue, Jul 18, 2017 at 12:56 PM, Alexander Popov <> wrote:
>> On 17.07.2017 22:11, Kees Cook wrote:
>>> Let's merge this with the proposed CONFIG_FREELIST_HARDENED, then the
>>> performance change is behind a config, and we gain the rest of the
>>> freelist protections at the same time:
>> Hello Kees,
>> If I change BUG_ON() to VM_BUG_ON(), this check will work at least on Fedora
>> since it has CONFIG_DEBUG_VM enabled. Debian based distros have this option
>> disabled. Do you like that more than having this check under
> I think there are two issues: first, this should likely be under
> CONFIG_FREELIST_HARDENED since Christoph hasn't wanted to make these
> changes enabled by default (if I'm understanding his earlier review
> comments to me).

Ok, I'll rebase onto FREELIST_HARDENED and test it all together.

> The second issue is what to DO when a double-free is
> discovered. Is there any way to make it safe/survivable? If not, I
> think it should just be BUG_ON(). If it can be made safe, then likely
> a WARN_ONCE and do whatever is needed to prevent the double-free.

Please correct me if I'm wrong. It seems to me that double-free is a dangerous
situation that indicates some serious kernel bug (which might be maliciously
exploited). So I would not trust / rely on the process which experiences a
double-free error in the kernel mode.

But I guess the reaction to it should depend on the Linux kernel policy of
handling faults. Is it defined explicitly?

Anyway, if we try to mitigate the effect from a double-free error _here_ (for
example, skip putting the duplicated object to the freelist), I think we should
do the same for other cases of double-free and memory corruptions.

>> If you insist on putting this check under CONFIG_FREELIST_HARDENED, should I
>> rebase onto your patch and send again?
> That would be preferred for me -- I'd like to have both checks. :)


Best regards,

To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

  reply	other threads:[~2017-07-19  8:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 16:45 [PATCH 1/1] mm/slub.c: add a naive detection of double free or corruption Alexander Popov
2017-07-17 16:57 ` Christopher Lameter
2017-07-17 17:54 ` Matthew Wilcox
2017-07-17 18:04   ` Christopher Lameter
2017-07-17 19:01     ` Alexander Popov
2017-07-17 19:11       ` Kees Cook
2017-07-18 19:56         ` Alexander Popov
2017-07-18 20:04           ` Kees Cook
2017-07-19  8:38             ` Alexander Popov [this message]
2017-07-19 14:02             ` Christopher Lameter
2017-07-18 14:57       ` Christopher Lameter
2017-07-17 18:23   ` Alexander Popov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).