linux-kernel - Re: [RFC][PATCH 7/7] lkdtm: Add READ_AFTER

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <568C80BC.4080507@labbott.name>
Date:	Tue, 5 Jan 2016 18:49:32 -0800
From:	Laura Abbott <laura@...bott.name>
To:	Kees Cook <keescook@...omium.org>
Cc:	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test

On 1/5/16 4:15 PM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@...bott.name> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no poison is present:
>>
>> [   20.222501] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   20.226163] lkdtm: Freed val: 12345678
>>
>> with poison:
>>
>> [   24.203748] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   24.207261] general protection fault: 0000 [#1] SMP
>> [   24.208193] Modules linked in:
>> [   24.208193] CPU: 0 PID: 866 Comm: sh Not tainted 4.4.0-rc5-work+ #108
>>
>> Cc: Arnd Bergmann <arnd@...db.de>
>> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>> Signed-off-by: Laura Abbott <laura@...bott.name>
>> ---
>>   drivers/misc/lkdtm.c | 29 +++++++++++++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..c641fb7 100644
>> --- a/drivers/misc/lkdtm.c
>> +++ b/drivers/misc/lkdtm.c
>> @@ -92,6 +92,7 @@ enum ctype {
>>          CT_UNALIGNED_LOAD_STORE_WRITE,
>>          CT_OVERWRITE_ALLOCATION,
>>          CT_WRITE_AFTER_FREE,
>> +       CT_READ_AFTER_FREE,
>>          CT_SOFTLOCKUP,
>>          CT_HARDLOCKUP,
>>          CT_SPINLOCKUP,
>> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>>          "UNALIGNED_LOAD_STORE_WRITE",
>>          "OVERWRITE_ALLOCATION",
>>          "WRITE_AFTER_FREE",
>> +       "READ_AFTER_FREE",
>>          "SOFTLOCKUP",
>>          "HARDLOCKUP",
>>          "SPINLOCKUP",
>> @@ -417,6 +419,33 @@ static void lkdtm_do_action(enum ctype which)
>>                  memset(data, 0x78, len);
>>                  break;
>>          }
>> +       case CT_READ_AFTER_FREE: {
>> +               int **base;
>> +               int *val, *tmp;
>> +
>> +               base = kmalloc(1024, GFP_KERNEL);
>> +               if (!base)
>> +                       return;
>> +
>> +               val = kmalloc(1024, GFP_KERNEL);
>> +               if (!val)
>> +                       return;
>
> For both of these test failure return, I think there should be a
> pr_warn too (see CT_EXEC_USERSPACE).
>

I was going by the usual rule that messages on memory failures are
redundant because something somewhere else is going to be printing
out error messages.
  
>> +
>> +               *val = 0x12345678;
>> +
>> +               /*
>> +                * Don't just use the first entry since that's where the
>> +                * freelist goes for the slab allocator
>> +                */
>> +               base[1] = val;
>
> Maybe just aim at the middle, in case allocator freelist tracking ever
> grows? base[1024/sizeof(int)/2] or something?
>

Good point.

>> +               kfree(base);
>> +
>> +               tmp = base[1];
>> +               pr_info("Freed val: %x\n", *tmp);
>
> Instead of depending on the deref to fail, maybe just use a simple
> BUG_ON to test that the value did actually change? Or, change the
> pr_info to "Failed to Oops when reading freed value: ..." just to be
> slightly more verbose about what failed?
>

I'll come up with something to be more explicit here.


Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/