> From: "Kirill A. Shutemov"
> Subject:
> mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix
>
This should be a separate patch. Stackdepot was added in
cd11016e5f5212c13c0cec7384a525edc93b4921
which is in v4.
On 07/22/2016 04:32 PM, Alexander Potapenko wrote:
> On Thu, Jul 21, 2016 at 10:48 AM, Andrey Ryabinin
> wrote:
>>
>>
>> On 07/20/2016 09:43 PM, a...@linux-foundation.org wrote:
>>>
>>> The patch titled
>>> Subject:
>>> mm-kasan
On 09/19/2016 09:55 PM, Andrew Morton wrote:
> On Wed, 24 Aug 2016 18:08:08 -0700 (PDT) David Rientjes
> wrote:
>
>>> diff -puN lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free
>>> lib/stackdepot.c
>>> --- a/lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free
>>> +++ a/lib/stackd
On 06/21/2016 02:44 PM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 10:43:19 AM CEST Arnd Bergmann wrote:
>> On Tuesday, June 21, 2016 2:39:05 PM CEST Seung-Woo Kim wrote:
>>> To enable UBSAN on arm, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL
>>> from arm confiuration. Basic kernel booti
There is no need for it.
Signed-off-by: Andrey Ryabinin
---
drivers/md/dm-ioctl.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 966eb4b..2d5594e 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -36,14 +36,6
On 07/27/2016 03:45 PM, Steven Rostedt wrote:
> On Fri, 15 Jul 2016 17:19:46 +0800
> kbuild test robot wrote:
>
>> Hi,
>>
>> [auto build test WARNING on tip/x86/core]
>> [also build test WARNING on v4.7-rc7 next-20160714]
>> [if your patch is applied to the wrong git tree, please drop us a note
2016-07-29 18:19 GMT+03:00 Dave Jones :
> On Fri, Jul 29, 2016 at 11:05:14AM -0400, Dave Jones wrote:
> > I've just gotten back into running trinity on daily pulls of master, and
> it seems pretty horrific
> > right now. I can reproduce some kind of memory corruption within a couple
> minutes
On 07/29/2016 02:10 PM, Nicolas Iooss wrote:
> handle_object_size_mismatch() used %pk to format a kernel pointer in
> pr_err(). This seems to be a misspelling for %pK.
>
> Fixes: c6d308534aef ("UBSAN: run-time undefined behavior sanity checker")
> Signed-off-by: Nicolas Iooss
> ---
> lib/ubsan.
On 07/29/2016 06:49 PM, Dave Jones wrote:
> On Fri, Jul 29, 2016 at 06:21:12PM +0300, Andrey Ryabinin wrote:
> > 2016-07-29 18:19 GMT+03:00 Dave Jones :
> > > On Fri, Jul 29, 2016 at 11:05:14AM -0400, Dave Jones wrote:
> > > > I've just gotten back int
On 07/29/2016 08:32 PM, Andrey Ryabinin wrote:
>
>
> On 07/29/2016 06:49 PM, Dave Jones wrote:
>> On Fri, Jul 29, 2016 at 06:21:12PM +0300, Andrey Ryabinin wrote:
>> > 2016-07-29 18:19 GMT+03:00 Dave Jones :
>> > > On Fri, Jul 29, 2016 at 11:05:14AM -040
On 07/29/2016 09:39 PM, Dave Jones wrote:
> On Fri, Jul 29, 2016 at 08:56:08PM +0300, Andrey Ryabinin wrote:
>
> > >> > I suspect this is false positives due to changes in KASAN.
> > >> > Bisection probably will point to
> > >> > 80a9201a5
nstead, like in handle_missaligned_access().
>
> Signed-off-by: Nicolas Iooss
Acked-by: Andrey Ryabinin
Currently we just dump stack in case of double free bug.
Let's dump all info about the object that we have.
Signed-off-by: Andrey Ryabinin
---
mm/kasan/kasan.c | 3 +--
mm/kasan/kasan.h | 2 ++
mm/kasan/report.c | 54 ++
3 files ch
lementation")
Reported-by: Dave Jones
Signed-off-by: Andrey Ryabinin
---
mm/kasan/kasan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 3019cec..c99ef40 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -565,7 +565,7 @@ vo
ess 88000d1efebc for type
'struct qlist_node'
which requires 8 byte alignment
Reported-by: kernel test robot
Signed-off-by: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
---
include/
eported-by: Vegard Nossum
Reported-by: Sasha Levin
Signed-off-by: Andrey Ryabinin
---
mm/kasan/kasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index b6f99e8..3019cec 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -543,9 +543
On 08/01/2016 05:56 PM, Alexander Potapenko wrote:
> On Mon, Aug 1, 2016 at 4:55 PM, Andrey Ryabinin
> wrote:
>>
>>
>> On 07/28/2016 06:31 PM, Alexander Potapenko wrote:
>>> When free_meta_offset is not zero, it is usually aligned on 4 bytes,
>>> beca
lementation.
Enable stackdepot for SLAB")
$ git describe --contains cd11016e5f5212c
v4.6-rc1~6^2~4
> Whaddyathink?
>
Acked-by: Andrey Ryabinin
> --->o---
>
> mm, mempolicy: task->mempolicy must be NULL before dropping final reference
>
> KASAN allocates
. 2 of them are in filesystem code and used on a
device with mounted fs. The third one in lock_fs() has protection in
upper-layer code against freezing block device the second time without
thawing it first.
Signed-off-by: Andrey Ryabinin
---
fs/block_dev.c | 3 ++-
1 file changed, 2 insertions
alignment. Unaligned vmovdqa will
generate GP fault.
Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
requirements.
Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2")
Reported-by: Josh Poimboeuf
Signed-off-by: Andrey Ryabinin
Cc:
. Unaligned vmovdqa will
generate GP fault.
Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
requirements.
Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush
routines for AVX2")
Signed-off-by: Andrey Ryabinin
Cc:
---
arch/x86
On 05/29/2017 01:02 PM, Dmitry Vyukov wrote:
> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
> wrote:
>> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index 0bf81e837cbf..c795207d8a3c 100644
>>> --- a/arch/x86/
On 05/29/2017 02:19 PM, Dmitry Vyukov wrote:
> On Mon, May 29, 2017 at 1:18 PM, Andrey Ryabinin
> wrote:
>>
>>
>> On 05/29/2017 01:02 PM, Dmitry Vyukov wrote:
>>> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
>>> wrote:
>>>> On Thu
On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
>>>>> Looks like KASAN will be a problem for boot-time paging mode switching.
>>>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to
>>>>> gcc -fasan-shadow-offset=. But this value
On 05/29/2017 06:29 PM, Dmitry Vyukov wrote:
> Joonsoo,
>
> I guess mine (and Andrey's) main concern is the amount of additional
> complexity (I am still struggling to understand how it all works) and
> more arch-dependent code in exchange for moderate memory win.
>
> Joonsoo, Andrey,
>
> I have
On 10/18/2017 08:23 PM, Pavel Tatashin wrote:
> Hi Andrew and Michal,
>
> There are a few changes I need to do to my series:
>
> 1. Replace these two patches:
>
> arm64/kasan: add and use kasan_map_populate()
> x86/kasan: add and use kasan_map_populate()
>
> With:
>
> x86/mm/kasan: don't use
On 10/13/2017 08:32 PM, Pavel Tatashin wrote:
> During early boot, kasan uses vmemmap_populate() to establish its shadow
> memory. But, that interface is intended for struct pages use.
>
> Because of the current project, vmemmap won't be zeroed during allocation,
> but kasan expects that memory to
he patch bellow works for me. Could you please make sure that it works for you
as well? Just in case.
From: Andrey Ryabinin
Subject: x86/mm/kasan: don't use vmemmap_populate() to initialize
shadow
The kasan shadow is currently mapped using vmemmap_populate() since that
provides
On 10/18/2017 08:08 PM, Pavel Tatashin wrote:
>>
>> As I said, I'm fine either way, I just didn't want to cause extra work
>> or rebasing:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/535703.html
>
> Makes sense. I am also fine either way, I can submit a new patch mergi
On 10/18/2017 08:14 PM, Pavel Tatashin wrote:
> Thank you Andrey, I will test this patch. Should it go on top or replace the
> existing patch in mm-tree? ARM and x86 should be done the same either both as
> follow-ups or both replace.
>
It's a replacement of your patch.
> Pavel
>
> --
> To
get_wchan() is racy by design, it may access volatile stack
of running task, thus it may access redzone in a stack frame
and cause KASAN to warn about this.
Use kasan_disable_current()/kasan_enable_current() to silence
these warnings.
Reported-by: Sasha Levin
Signed-off-by: Andrey Ryabinin
On 10/05/2015 02:39 PM, Dmitry Vyukov wrote:
>>
>> But that's all pretty disgusting really.
>>
>> Cannot we do better, such as annotating the function and then KASAN sorting
>> out
>> its false positives, or something like that?
>
>
> We also plug __attribute__((no_sanitize_address)) on the fu
2015-10-05 14:09 GMT+03:00 Fengguang Wu :
> Hi Abylay,
>
>> cause of this 'Kernel Address sanitizer (KASan)' is enabled in your
>> config. With gcc-4.9 kasan was disabled in compile time because of:
>> "scripts/Makefile.kasan:23: CONFIG_KASAN: compiler does not support
>> all options. Trying minima
On 10/05/2015 07:39 PM, Andi Kleen wrote:
>> But, I think I have the solution.
>> We could have some blacklist - list of function names which we should be
>> ignored.
>> In kasan_report() we could resolve return address to function name and
>> compare it with name in list.
>> If name in list -> i
On 10/06/2015 10:26 AM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>> On 10/05/2015 07:39 PM, Andi Kleen wrote:
>>>> But, I think I have the solution.
>>>> We could have some blacklist - list of function names which we should be
>>>&g
On 10/06/2015 09:11 PM, Andy Lutomirski wrote:
>
> But what's wrong with the GCC attribute mechanism? Surely GCC ought
> to be able to generate the code, at least in the simple cases, and the
> attribute already exists. The attribute and READ_ONCE_NOCHECK seem
> like the least messy in the C cod
On 10/07/2015 11:54 AM, Andrey Ryabinin wrote:
> On 10/06/2015 09:11 PM, Andy Lutomirski wrote:
>>
>> But what's wrong with the GCC attribute mechanism? Surely GCC ought
>> to be able to generate the code, at least in the simple cases, and the
>> attribute al
instead of holding the rpc client we could just save nodename
in struct nlm_host and pass it to the rpc_create().
Thus ther is no need in keeping rpc client until last
unmonitor request. We could create separate RPC clients
for each monitor/unmonitor requests.
Signed-off-by: Andrey Ryabinin
--
instead of holding the rpc client we could just save nodename
in struct nlm_host and pass it to the rpc_create().
Thus ther is no need in keeping rpc client until last
unmonitor request. We could create separate RPC clients
for each monitor/unmonitor requests.
Signed-off-by: Andrey Ryabinin
---
2015-10-07 19:27 GMT+03:00 Andi Kleen :
> On Wed, Oct 07, 2015 at 11:54:42AM +0300, Andrey Ryabinin wrote:
>> On 10/06/2015 09:11 PM, Andy Lutomirski wrote:
>> >
>> > But what's wrong with the GCC attribute mechanism? Surely GCC ought
>> > to be able to
by the EFI stub.
Signed-off-by: Andrey Ryabinin
---
arch/x86/include/asm/efi.h | 11 +++
drivers/firmware/efi/libstub/efistub.h | 4
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 155162e..6862f
2015-08-28 17:43 GMT+03:00 Matt Fleming :
> On Fri, 28 Aug, at 02:09:59PM, Andrey Ryabinin wrote:
>> In not-instrumented code KASAN replaces instrumented
>> memset/memcpy/memmove with not-instrumented analogues
>> __memset/__memcpy/__memove.
>> However, on x86 the EFI
r changing ttbr1
- Add code comments.
Andrey Ryabinin (3):
arm64: move PGD_SIZE definition to pgalloc.h
arm64: add KASAN support
Documentation/features/KASAN: arm64 supports KASAN now
Linus Walleij (1):
ARM64: kasan: print memory assignment
.../features/debug/KASAN/arch-support.txt
th prefixed variants
to disable memory access checks for such files.
Signed-off-by: Andrey Ryabinin
Tested-by: Linus Walleij
Reviewed-by: Catalin Marinas
---
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 7 ++
arch/arm64/include/asm/kasan.h | 36 +
ar
: Andrey Ryabinin
Acked-by: Catalin Marinas
---
arch/arm64/mm/init.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f5c0680..7a1f9a0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -298,6 +298,9 @@ void __init mem_init(void
This will be used by KASAN latter.
Signed-off-by: Andrey Ryabinin
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/pgalloc.h | 1 +
arch/arm64/mm/pgd.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include
Signed-off-by: Andrey Ryabinin
---
Documentation/features/debug/KASAN/arch-support.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/features/debug/KASAN/arch-support.txt
b/Documentation/features/debug/KASAN/arch-support.txt
index 14531da..703f578 100644
to that function.
We declare it as static '__maybe_unsed' because GCC is not capable to
inline such function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
With KASAN=n READ_ONCE_NOCHECK() is just a clone of READ_ONCE().
Signed-off-by: Andrey Ryabinin
---
include/linux/compiler-gc
get_wchan() is racy by design, it may access volatile stack
of running task, thus it may access redzone in a stack frame
and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Sasha Levin
Signed-off-by: Andrey Ryabinin
---
arch/x86/kernel/process.c
n variant above
Cons:
- REAS_ONCE() becomes rather messy.
Andrey Ryabinin (2):
Provide READ_ONCE_NOCHECK()
x86/process: Silence KASAN warnings in get_wchan()
arch/x86/kernel/process.c| 6 +++---
include/linux/compiler-gcc.h | 13
include/linux/comp
On 10/13/2015 04:48 PM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>> get_wchan() is racy by design, it may access volatile stack
>> of running task, thus it may access redzone in a stack frame
>> and cause KASAN to warn about this.
>>
>> U
On 10/13/2015 04:57 PM, Dmitry Vyukov wrote:
> On Tue, Oct 13, 2015 at 3:48 PM, Ingo Molnar wrote:
>>
>> * Andrey Ryabinin wrote:
>>
>>> get_wchan() is racy by design, it may access volatile stack
>>> of running task, thus it may access redzone in a
Changes since v2:
- Added some code comments in the first patch.
Andrey Ryabinin (2):
Provide READ_ONCE_NOCHECK()
x86/process: Silence KASAN warnings in get_wchan()
arch/x86/kernel/process.c| 6 ++---
include/linux/compiler-gcc.h | 13 ++
include/linux/compiler.h | 60
get_wchan() is racy by design, it may access volatile stack
of running task, thus it may access redzone in a stack frame
and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Sasha Levin
Signed-off-by: Andrey Ryabinin
---
arch/x86/kernel/process.c
to that function.
We declare it as static '__maybe_unsed' because GCC is not capable to
inline such function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
With KASAN=n READ_ONCE_NOCHECK() is just a clone of READ_ONCE().
Signed-off-by: Andrey Ryabinin
---
include/linux/compiler-
On 10/13/2015 07:02 PM, kbuild test robot wrote:
> Hi Andrey,
>
> [auto build test WARNING on tip/auto-latest -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commi
On 10/14/2015 04:40 PM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>>
>>
>> On 10/13/2015 07:02 PM, kbuild test robot wrote:
>>> Hi Andrey,
>>>
>>> [auto build test WARNING on tip/auto-latest -- if it's inappropriate base,
&g
On 10/14/2015 06:50 PM, Dmitry Vyukov wrote:
> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney
> wrote:
>> On Wed, Oct 14, 2015 at 08:28:43AM -0700, tip-bot for Andrey Ryabinin wrote:
>>> Commit-ID: 4115ffdf4d6f8986a7abe1dd522c163f599bc0e6
>>> Gitweb:
2015-09-08 4:42 GMT+03:00 Xishi Qiu :
> The shadow which correspond 16 bytes may span 2 or 3 bytes. If shadow
> only take 2 bytes, we can return in "if (likely(!last_byte)) ...", but
> it calculates wrong, so fix it.
>
Please, be more specific. Describe what is wrong with the current code and why,
2015-09-08 12:52 GMT+03:00 Xishi Qiu :
> On 2015/9/8 17:49, Xishi Qiu wrote:
>
>> On 2015/9/8 17:36, Andrey Ryabinin wrote:
>>
>>> 2015-09-08 4:42 GMT+03:00 Xishi Qiu :
>>>> The shadow which correspond 16 bytes may span 2 or 3 bytes. If shadow
>>>&
On 09/07/2015 11:28 AM, Aneesh Kumar K.V wrote:
> Use is_module_address instead
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Andrey Ryabinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
2015-09-09 9:40 GMT+03:00 long.wanglong :
> On 2015/9/8 20:12, Xishi Qiu wrote:
>> The shadow which correspond 16 bytes memory may span 2 or 3 bytes. If the
>> memory is aligned on 8, then the shadow takes only 2 bytes. So we check
>> "shadow_first_bytes" is enough, and need not to call
>> "memory
2015-09-09 6:59 GMT+03:00 Wang Long :
> The current KASAN code can find the following out-of-bounds
> bugs:
> char *ptr;
> ptr = kmalloc(8, GFP_KERNEL);
> memset(ptr+7, 0, 2);
>
> the cause of the problem is the type conversion error in
> *memory_is_poisoned_n* function. So
d_1(addr + 15);".
> But the code "if (likely(!last_byte))" is wrong judgement.
>
> e.g. addr=0, so last_byte = 15 & KASAN_SHADOW_MASK = 7, then the code will
> continue to call "memory_is_poisoned_1(addr + 15);"
>
> Signed-off-by: Xishi Qiu
On 09/09/2015 06:59 AM, Wang Long wrote:
> This patch add some out of bounds testcases to test_kasan
> module.
>
> Signed-off-by: Wang Long
Acked-by: Andrey Ryabinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
s/Confilcts/Conflicts
Signed-off-by: Andrey Ryabinin
Reported-by: Andrew Morton
---
include/linux/compiler-gcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index f2a9aec..8efb40e 100644
--- a/include/linux
2015-10-15 0:47 GMT+03:00 Borislav Petkov :
> Hey,
>
> did the issue in $Subject get fixed somewhere?
>
> I remember reading something about it on lkml ...
I'm an idiot :(
The same failure was fixed for KMEMCHECK=y && KASAN=n config
But that fix didn't fix the KMEMCHECK=y && KASAN=y case.
>
> In
On 10/15/2015 12:18 PM, Stephen Rothwell wrote:
> Hi Andrey,
>
> On Tue, 13 Oct 2015 18:28:07 +0300 Andrey Ryabinin
> wrote:
>>
>> Some code may perform racy by design memory reads. This could be harmless,
>> yet such code may produce KASAN warnings.
>>
>
We could avoid using alias to work around this problem.
Reported-by: Stephen Rothwell
Signed-off-by: Andrey Ryabinin
---
include/linux/compiler.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index aa2ae4c..3436a4c 10
Changes since v3:
- Fixed build failure.
- Rename: s/READ_ONCE_NOCHECK/READ_ONCE_NOKSAN
- Spelling fix.
Changes since v2:
- Added some code comments in the first patch.
Andrey Ryabinin (2):
compiler, atomics: Provide READ_ONCE_NOKSAN()
x86/mm: Silence KASAN warnings in get_wchan()
arch
get_wchan() is racy by design, it may access volatile stack
of running task, thus it may access redzone in a stack frame
and cause KASAN to warn about this.
Use READ_ONCE_NOKSAN() to silence these warnings.
Reported-by: Sasha Levin
Signed-off-by: Andrey Ryabinin
---
arch/x86/kernel/process.c
On 10/16/2015 12:44 PM, Andrey Ryabinin wrote:
> Changes since v3:
> - Fixed build failure.
> - Rename: s/READ_ONCE_NOCHECK/READ_ONCE_NOKSAN
> - Spelling fix.
>
> Changes since v2:
> - Added some code comments in the first patch.
>
> Andrey Ryabinin (2):
>
cesses should not be applied to that function. We declare it as
static '__maybe_unsed' because GCC is not capable to inline such
function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
With KASAN=n READ_ONCE_NOKSAN() is just a clone of READ_ONCE().
Signed-off-by: Andrey Ryabinin
---
On 10/16/2015 01:00 PM, Peter Zijlstra wrote:
> On Fri, Oct 16, 2015 at 12:44:53PM +0300, Andrey Ryabinin wrote:
>> Some code may perform racy by design memory reads. This could be
>> harmless, yet such code may produce KASAN warnings.
>>
>> To hide such accesses from
But in the meanwhile move memcpy() declaration out ifdefs
to fix build.
Reported-by: Borislav Petkov
Signed-off-by: Andrey Ryabinin
---
arch/x86/include/asm/string_64.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include
On 10/16/2015 01:33 PM, Borislav Petkov wrote:
> On Fri, Oct 16, 2015 at 12:44:53PM +0300, Andrey Ryabinin wrote:
>> Some code may perform racy by design memory reads. This could be
>> harmless, yet such code may produce KASAN warnings.
>>
>> To hide such accesses from
hus we should turn it off.
Reported-by: Fengguang Wu
Signed-off-by: Andrey Ryabinin
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ab76b99..1d1521c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -197,6 +197,7 @@ config
16 октября 2015 г. 19:47:00 GMT+03:00, Andi Kleen пишет:
>On Fri, Oct 16, 2015 at 07:02:10PM +0300, Andrey Ryabinin wrote:
>> When the kernel compiled with KASAN=y, GCC adds redzones
>> for each variable on stack. This enlarges function's stack
>> frame and causes:
&
fault with KASAN=y, since there is no
good reason to not do this.
Signed-off-by: Andrey Ryabinin
---
Documentation/kasan.txt | 3 +--
lib/Kconfig.kasan | 3 +--
mm/slub.c | 2 ++
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/kasan.txt b/Doc
On 09/03/2015 10:54 AM, Aneesh Kumar K.V wrote:
> Use is_module_text_address instead
>
It should be is_module_address().
We use kernel_or_module_addr() to determine whether this
address belongs to some global variable or not.
And variables are in .data section, .text is only code.
Something l
insertions(+), 2 deletions(-)
Anyway, for this patch:
Reviewed-by: Andrey Ryabinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
isable kasan reporting when we are priting
s/priting/printing
> error w.r.t kasan.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/kasan/report.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
Reviewed-by: Andrey Ryabinin
--
To unsubscribe from this
Currently context size (cra_ctxsize) doesn't specified for
ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
doesn't allocate needed space for ghash_async_ctx, so any
read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.
Signed-off-by: Andrey Ryabinin
While the destination buffer 'iv' is MAX_IVLEN size,
the source 'template[i].iv' could be smaller. Thus
copying it via memcpy() leads to invalid memory access.
Use strlcpy() instead.
Signed-off-by: Andrey Ryabinin
---
crypto/testmgr.c | 4 ++--
1 file changed, 2 insert
On 09/03/2015 04:20 PM, Herbert Xu wrote:
> On Thu, Sep 03, 2015 at 02:32:00PM +0300, Andrey Ryabinin wrote:
>> While the destination buffer 'iv' is MAX_IVLEN size,
>> the source 'template[i].iv' could be smaller. Thus
>> copying it via memcpy() leads
cesses should not be applied to that function. We declare it as
static '__maybe_unsed' because GCC is not capable to inline such
function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
With KASAN=n READ_ONCE_NOCHECK() is just a clone of READ_ONCE().
Signed-off-by: Andrey Ryabini
Changes since v4:
- Rename back to READ_ONCE_NOCHECK().
Changes since v3:
- Fixed build failure.
- Rename: s/READ_ONCE_NOCHECK/READ_ONCE_NOKSAN
- Spelling fix.
Changes since v2:
- Added some code comments in the first patch.
Andrey Ryabinin (2):
compiler, atomics: Provide
get_wchan() is racy by design, it may access volatile stack
of running task, thus it may access redzone in a stack frame
and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Signed-off-by: Andrey Ryabinin
Reported-by: Sasha Levin
---
arch/x86/kernel/process.c
2015-10-01 10:57 GMT+03:00 Ingo Molnar :
> diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> index d411ca63c8b6..db64f7d6492d 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -140,7 +140,8 @@ Table 1-1: Process
On 10/01/2015 12:29 PM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>> 2015-10-01 10:57 GMT+03:00 Ingo Molnar :
>>> diff --git a/Documentation/filesystems/proc.txt
>>> b/Documentation/filesystems/proc.txt
>>> index d411ca63c8b6..db64f7d6492d
2015-10-01 13:39 GMT+03:00 Ingo Molnar :
>
> There's another problem as well: your change loses the PTRACE_MODE_READ
> permission
> check.
I guess, you should fix your patch than, because it removed this check
likewise...
>
> But ... I think I like it open coded, which is good precisely becaus
On 09/29/2015 09:47 PM, J. Bruce Fields wrote:
> On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote:
>> Commit cb7323fffa85 ("lockd: create and use per-net NSM
>> RPC clients on MON/UNMON requests") introduced per-net
>> NSM RPC clients. Unfortunat
On 10/01/2015 09:26 PM, J. Bruce Fields wrote:
> On Thu, Oct 01, 2015 at 07:36:19PM +0300, Andrey Ryabinin wrote:
>> On 09/29/2015 09:47 PM, J. Bruce Fields wrote:
>>> On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote:
>>>> Commit cb7323fffa85 (&quo
2015-10-03 13:54 GMT+03:00 Thomas Gleixner :
> On Fri, 2 Oct 2015, Sasha Levin wrote:
>> I'm seeing a different issue with this patch:
>>
>> [ 5228.736320] BUG: KASAN: out-of-bounds in get_wchan+0xf9/0x1b0 at addr
>> 88049d2b7c50
>> [ 5228.737560] Read of size 8 by task killall/22177
>> [ 5228
d something at NULL (root can do this),
with things like SMAP should catch the issue.
Signed-off-by: Andrey Ryabinin
---
arch/parisc/Kconfig| 1 -
arch/s390/Kconfig | 1 -
lib/Kconfig.ubsan | 11 ---
scripts/Makefile.ubsan | 4
4 files changed, 17 deletions(-)
di
86/mm: Fold p4d page table layer at runtime")
Signed-off-by: Andrey Ryabinin
---
arch/x86/include/asm/pgalloc.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index ada6410fd2ec..fbd578daa66e 100644
--- a/arch/x86/include
On 08/25/2018 02:58 AM, Jann Horn wrote:
> Reset the KASAN shadow state of the task stack when rewinding RSP.
> Without this, a kernel oops will leave parts of the stack poisoned, and
> code running under do_exit() can trip over such poisoned regions and cause
> nonsensical false-positive KASAN rep
On 08/28/2018 01:38 PM, Jann Horn wrote:
>>
>>
>> Why this has to be done in the rewind_stack_do_exit()?
>> Are there any problems with calling the kasan_unpoison_task_stack(current)
>> from oops_end(), before the rewind_stack_do_exit()?
>
> Ooh, good point! I didn't see that KASAN instrument
g, rewind the stack before
> do_exit()")
> Signed-off-by: Jann Horn
> ---
Acked-by: Andrey Ryabinin
On 08/14/2018 10:55 AM, Kyeongdon Kim wrote:
> Assembly optimized string functions cannot detect KASan bug.
> This might have been the intention of the original author.
> (not too much important to catch)
>
> But, I found the obvious uaf problem in strcmp() function.
> - in this case, using 32
1 - 100 of 1443 matches
Mail list logo
