[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <e535d698-5268-e5fc-a238-0649c509cc4f@gmail.com>
Date: Thu, 13 Feb 2020 23:16:20 +0800
From: zerons <zeronsaxm@...il.com>
To: kernel-hardening@...ts.openwall.com
Cc: Shawn <citypw@...il.com>, spender@...ecurity.net
Subject: Maybe inappropriate use BUG_ON() in CONFIG_SLAB_FREELIST_HARDENED
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.
Best Regards,
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.
