linux-kernel - Re: [PATCH v2 6/9] kasan: improve slab object description

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]

Date:   Tue, 14 Mar 2017 18:15:40 +0100
From:   Andrey Konovalov <andreyknvl@...gle.com>
To:     Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc:     Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 6/9] kasan: improve slab object description

On Thu, Mar 9, 2017 at 1:56 PM, Andrey Ryabinin <aryabinin@...tuozzo.com> wrote:
> On 03/06/2017 08:16 PM, Andrey Konovalov wrote:
>
>>>
>>> What about
>>>
>>> Object at ffff880068388540 belongs to cache kmalloc-128 of size 128
>>> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)
>>>
>>> ?
>>
>> Another alternative:
>>
>> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)
>> Object belongs to cache kmalloc-128 of size 128
>>
>
> Is it something wrong with just printing offset at the end as I suggested earlier?
> It's more compact and also more clear IMO.

This is what you suggested:

Object at ffff880068388540, in cache kmalloc-128 size: 128 accessed at
offset 123

After minor reworking of punctuation, etc, we get:

Object at ffff880068388540, in cache kmalloc-128 of size 128, accessed
at offset 123

It's good, but I still don't like two things:

1. The line is quite long. Over 84 characters in this example, but
might be longer for different cache names. The solution would be to
split it into two lines.

2. The access might be within the object (for example use-after-free),
or outside the object (slab-out-of-bounds). In this case just saying
"accessed at offset X" might be confusing, since the offset might be
from the start of the object, or might be from the end. The solution
would be to specifically describe this.

Out of all options above this one I like the most:

>> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)
>> Object belongs to cache kmalloc-128 of size 128

as:

1. It specifies whether the offset is inside or outside the object.
2. The lines are not too long (the first one is 76 chars).
3. Accounts for larger cache names (the second line has some spare space).
4. Shows exact addresses of start and end of the object (it's possible
to calculate the end address using the start and the size, but it's
nicer to have it already calculated and shown).

Thanks!

>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@...glegroups.com.
> To post to this group, send email to kasan-dev@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/69679f30-e502-d2cf-8dee-4ee88f64f887%40virtuozzo.com.
> For more options, visit https://groups.google.com/d/optout.