From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Jones <davej@codemonkey.org.uk>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev@googlegroups.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lib/strscpy: avoid KASAN false positive
Date: Wed, 19 Jul 2017 00:31:36 +0300 [thread overview]
Message-ID: <96a21da7-1258-0ada-298f-e0388849402a@virtuozzo.com> (raw)
In-Reply-To: <CA+55aFy-fxPm18RqtwpCJrWX0YvaQeT8HfcKNpF3qC+cxE8fqw@mail.gmail.com>
On 07/18/2017 11:26 PM, Linus Torvalds wrote:
> On Tue, Jul 18, 2017 at 1:15 PM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>>
>> No, it does warn about valid users. The report that Dave posted wasn't about wrong strscpy() usage
>> it was about reading 8-bytes from 5-bytes source string. It wasn't about buggy 'count' at all.
>> So KASAN will warn for perfectly valid code like this:
>> char dest[16];
>> strscpy(dest, "12345", sizeof(dest)):
>
> Ugh, ok, yes.
>
>> For strscpy() that would mean making the *whole* read from 'src' buffer unchecked by KASAN.
>
> So we do have that READ_ONCE_NOCHECK(), but could we perhaps have
> something that doesn't do a NOCHECK but a partial check and is simply
> ok with "this is an optimistc longer access"
>
This can be dont, I think.
Something like this:
static inline unsigned long read_partial_nocheck(unsigned long *x)
{
unsigned long ret = READ_ONCE_NOCHECK(x);
kasan_check_partial(x, sizeof(unsigned long));
return ret;
}
Where kasan_check_partial() will warn only if the kasan shadow has a negative value.
Positive values 1-7 in the shadow would mean a partial oob access, that should be ignored.
> We have that for the dcache case too, although there the code does
> that odd kasan_unpoison_shadow() instead.
>
Yes, it marks memory as valid, so it can be accessed without warning.
We can do this the same in strscpy(), but the disadvantage of this approach is that
memory becomes accessible for everyone, not just for the code that does optimistic reads.
Thus it would be possible to miss some off-by-ones (quite usual bug for strings).
next prev parent reply other threads:[~2017-07-18 21:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 17:15 Andrey Ryabinin
2017-07-18 17:14 ` Dmitry Vyukov
2017-07-18 17:22 ` Linus Torvalds
2017-07-18 20:15 ` Andrey Ryabinin
2017-07-18 20:26 ` Linus Torvalds
2017-07-18 21:31 ` Andrey Ryabinin [this message]
2017-07-18 21:32 ` Andrey Ryabinin
2017-07-18 22:04 ` Andrew Morton
2017-07-18 22:35 ` Linus Torvalds
2017-07-19 7:46 ` Dmitry Vyukov
2017-07-19 15:39 ` Chris Metcalf
2017-07-19 16:05 ` Dave Jones
2017-07-26 12:05 ` Dmitry Vyukov
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96a21da7-1258-0ada-298f-e0388849402a@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=davej@codemonkey.org.uk \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
all inboxes | Powered by JetHome®