[PATCH] drm/i915: fix use-after-free in page_flip_completed()

queue_work() after trace_i915_flip_complete() to fix this. Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions") Signed-off-by: Andrey Ryabinin --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/d

[PATCH] platform/x86: intel_pmc_core: fix out-of-bounds accesses on stack

this code a little bit. Fixes: 173943b3dae5 ("platform/x86: intel_pmc_core: ModPhy core lanes pg status") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- drivers/platform/x86/intel_pmc_core.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff

[PATCH] platform/x86: intel_pmc_core: fix out-of-bounds accesses on stack

this code a little bit. Fixes: 173943b3dae5 ("platform/x86: intel_pmc_core: ModPhy core lanes pg status") Signed-off-by: Andrey Ryabinin --- drivers/platform/x86/intel_pmc_core.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/pl

Re: x86/microcode: use-after-free after cpu offline/online

On 01/25/2017 08:23 PM, Borislav Petkov wrote: > On Wed, Jan 25, 2017 at 07:58:39PM +0300, Andrey Ryabinin wrote: >> On 4.10-rc5 >># echo 0 > /sys/devices/system/cpu/cpu1/online >># echo 1 > /sys/devices/system/cpu/cpu1/online >> >> triggers use-aft

Re: x86/microcode: use-after-free after cpu offline/online

On 01/25/2017 08:23 PM, Borislav Petkov wrote: > On Wed, Jan 25, 2017 at 07:58:39PM +0300, Andrey Ryabinin wrote: >> On 4.10-rc5 >># echo 0 > /sys/devices/system/cpu/cpu1/online >># echo 1 > /sys/devices/system/cpu/cpu1/online >> >> triggers use-aft

x86/microcode: use-after-free after cpu offline/online

On 4.10-rc5 # echo 0 > /sys/devices/system/cpu/cpu1/online # echo 1 > /sys/devices/system/cpu/cpu1/online triggers use-after-free (probably caused by 06b8534cb72 "x86/microcode: Rework microcode loading"). __load_ucode_intel() accesses initrd which is obviously gone at this point: [

x86/microcode: use-after-free after cpu offline/online

On 4.10-rc5 # echo 0 > /sys/devices/system/cpu/cpu1/online # echo 1 > /sys/devices/system/cpu/cpu1/online triggers use-after-free (probably caused by 06b8534cb72 "x86/microcode: Rework microcode loading"). __load_ucode_intel() accesses initrd which is obviously gone at this point: [

[PATCH v2] kasan: Respect /proc/sys/kernel/traceoff_on_warning

jlstra (Intel) <pet...@infradead.org> Acked-by: Alexander Potapenko <gli...@google.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Steven Rostedt <rost...@goodmis.org> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/kasan/report.c | 3 +++ 1 file chang

[PATCH v2] kasan: Respect /proc/sys/kernel/traceoff_on_warning

-by: Alexander Potapenko Cc: Dmitry Vyukov Cc: Steven Rostedt Signed-off-by: Andrey Ryabinin --- mm/kasan/report.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/kasan/report.c b/mm/kasan/report.c index b82b3e2..f479365 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -13,6 +13,7

Re: [PATCH] block: Initialize cfqq->ioprio_class in cfq_get_queue()

2017-01-23 17:06 GMT+03:00 Alexander Potapenko : > KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of > uninitialized memory in cfq_init_cfqq(): > > == > BUG: KMSAN: use of unitialized memory >

Re: [PATCH] block: Initialize cfqq->ioprio_class in cfq_get_queue()

2017-01-23 17:06 GMT+03:00 Alexander Potapenko : > KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of > uninitialized memory in cfq_init_cfqq(): > > == > BUG: KMSAN: use of unitialized memory > ... > Call Trace:

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 15:53 GMT+03:00 Peter Zijlstra : > On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: >> Hi Peter, >> >> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not >> > something I've ever ran into. >> > >> > Also, I would argue that this

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 15:53 GMT+03:00 Peter Zijlstra : > On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: >> Hi Peter, >> >> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not >> > something I've ever ran into. >> > >> > Also, I would argue that this is broken in llvm,

Re: [PATCH 1/2] kasan: drain quarantine of memcg slab objects

gt; __shutdown_memcg_cache() => shutdown_cache() > flushes per memcg quarantined objects, even if that memcg has been > rmdir'd and gone through memcg_deactivate_kmem_caches(). > > This leak only affects destroyed SLAB_ACCOUNT kmem caches when kasan is > enabled. So I don't thi

Re: [PATCH 1/2] kasan: drain quarantine of memcg slab objects

gt; __shutdown_memcg_cache() => shutdown_cache() > flushes per memcg quarantined objects, even if that memcg has been > rmdir'd and gone through memcg_deactivate_kmem_caches(). > > This leak only affects destroyed SLAB_ACCOUNT kmem caches when kasan is > enabled. So I don't think it's worth patching stable kernels. > > Signed-off-by: Greg Thelen > Acked-by: Andrey Ryabinin

Re: [PATCH] mm-add-vfree_atomic-fix

On 12/13/2016 09:15 PM, Andy Lutomirski wrote: >>> >>> But not quite acked by me. What happened to the vfree code that >>> causes vfree_deferred to be called in a preemptable context? That >>> sounds like a bug. >> >> Not sure I understand but the above stack points to a preemptible >> context

Re: [PATCH] mm-add-vfree_atomic-fix

On 12/13/2016 09:15 PM, Andy Lutomirski wrote: >>> >>> But not quite acked by me. What happened to the vfree code that >>> causes vfree_deferred to be called in a preemptable context? That >>> sounds like a bug. >> >> Not sure I understand but the above stack points to a preemptible >> context

Re: [PATCH] mm-add-vfree_atomic-fix

r/20161209142820.ga4...@dhcp22.suse.cz >>> and also concluded same as you >>> >>> On Mon 12-12-16 17:46:21, Andrey Ryabinin wrote: >>>> DEBUG_PREEMPT complains about using this_cpu_ptr() in preemptible: >>>> BUG: using smp_processor_id() in p

Re: [PATCH] mm-add-vfree_atomic-fix

22.suse.cz >>> and also concluded same as you >>> >>> On Mon 12-12-16 17:46:21, Andrey Ryabinin wrote: >>>> DEBUG_PREEMPT complains about using this_cpu_ptr() in preemptible: >>>> BUG: using smp_processor_id() in preemptible [] code:

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 05:13 PM, Dmitry Vyukov wrote: > On Tue, Dec 13, 2016 at 2:59 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> On 12/13/2016 12:38 PM, Dmitry Vyukov wrote: >>> On Tue, Dec 13, 2016 at 10:20 AM, Andrey Ryabinin >>> <aryabi...@virtuo

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 05:13 PM, Dmitry Vyukov wrote: > On Tue, Dec 13, 2016 at 2:59 PM, Andrey Ryabinin > wrote: >> On 12/13/2016 12:38 PM, Dmitry Vyukov wrote: >>> On Tue, Dec 13, 2016 at 10:20 AM, Andrey Ryabinin >>> wrote: >>>> >>>

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 12:38 PM, Dmitry Vyukov wrote: > On Tue, Dec 13, 2016 at 10:20 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 12/13/2016 11:58 AM, Dmitry Vyukov wrote: >> >>> --- a/Documentation/dev-tools/kasan.rst >>> +++ b

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 12:38 PM, Dmitry Vyukov wrote: > On Tue, Dec 13, 2016 at 10:20 AM, Andrey Ryabinin > wrote: >> >> >> On 12/13/2016 11:58 AM, Dmitry Vyukov wrote: >> >>> --- a/Documentation/dev-tools/kasan.rst >>> +++ b/Documentation/de

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 11:58 AM, Dmitry Vyukov wrote: > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -40,6 +40,14 @@ similar to the following to the respective kernel Makefile: > > KASAN_SANITIZE := n > > +Sometimes it may be useful to disable

Re: [PATCH v2] kasan: Support for r/w instrumentation control

On 12/13/2016 11:58 AM, Dmitry Vyukov wrote: > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -40,6 +40,14 @@ similar to the following to the respective kernel Makefile: > > KASAN_SANITIZE := n > > +Sometimes it may be useful to disable

[PATCH] mm-add-vfree_atomic-fix

llist_add() implementation is lock-less, so it works even if we adding to the list of some other cpu. schedule_work() is also preempt-safe. Reported-by: kernel test robot <ying.hu...@linux.intel.com> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmalloc.c | 9 - 1

[PATCH] mm-add-vfree_atomic-fix

llist_add() implementation is lock-less, so it works even if we adding to the list of some other cpu. schedule_work() is also preempt-safe. Reported-by: kernel test robot Signed-off-by: Andrey Ryabinin --- mm/vmalloc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mm

[PATCH v2] kasan: turn on -fsanitize-address-use-after-scope

-sanitize-address-use-after-scope. Now the kernel has everything required for that feature since commit 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it work, we just have to enable use-after-scope in CFLAGS. Signed-off-by: Andrey Ryabinin <aryabi...@virtuoz

[PATCH v2] kasan: turn on -fsanitize-address-use-after-scope

-sanitize-address-use-after-scope. Now the kernel has everything required for that feature since commit 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it work, we just have to enable use-after-scope in CFLAGS. Signed-off-by: Andrey Ryabinin Acked-by: Dmi

[PATCH] kasan: turn on -fsanitize-address-use-after-scope

to -fno-sanitize-address-use-after-scope. Now the kernel has everything required for that feature since commit 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it work, we just have to enable use-after-scope in CFLAGS. Signed-off-by: Andrey Ryabinin <aryabi...@

[PATCH] kasan: turn on -fsanitize-address-use-after-scope

to -fno-sanitize-address-use-after-scope. Now the kernel has everything required for that feature since commit 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it work, we just have to enable use-after-scope in CFLAGS. Signed-off-by: Andrey Ryabinin --

Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume

t;8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions never return, so their stack never gets unpoisoned, > resulting in stale KASAN shadow data which can cause later false > positive warnings like the one above. > > Reported-by: Scott Bauer <scott.ba...@intel.com> > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume

t;8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions never return, so their stack never gets unpoisoned, > resulting in stale KASAN shadow data which can cause later false > positive warnings like the one above. > > Reported-by: Scott Bauer > Signed-off-by: Josh Poimboeuf Acked-by: Andrey Ryabinin

Re: [PATCH v2] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/01/2016 11:31 PM, Josh Poimboeuf wrote: > arch/x86/kernel/acpi/wakeup_64.S | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/x86/kernel/acpi/wakeup_64.S > b/arch/x86/kernel/acpi/wakeup_64.S > index 169963f..1df9b75 100644 > ---

Re: [PATCH v2] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/01/2016 11:31 PM, Josh Poimboeuf wrote: > arch/x86/kernel/acpi/wakeup_64.S | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/x86/kernel/acpi/wakeup_64.S > b/arch/x86/kernel/acpi/wakeup_64.S > index 169963f..1df9b75 100644 > ---

Re: [PATCH v3] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/02/2016 05:42 PM, Josh Poimboeuf wrote: > diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c > index 0e9505f..e9d8ba0 100644 > --- a/mm/kasan/kasan.c > +++ b/mm/kasan/kasan.c > @@ -80,7 +80,14 @@ void kasan_unpoison_task_stack(struct task_struct *task) > /* Unpoison the stack for the

Re: [PATCH v3] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/02/2016 05:42 PM, Josh Poimboeuf wrote: > diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c > index 0e9505f..e9d8ba0 100644 > --- a/mm/kasan/kasan.c > +++ b/mm/kasan/kasan.c > @@ -80,7 +80,14 @@ void kasan_unpoison_task_stack(struct task_struct *task) > /* Unpoison the stack for the

Re: [PATCH] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/01/2016 02:10 AM, Josh Poimboeuf wrote: > Resuming from a suspend operation is showing a KASAN false positive > warning: > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions

Re: [PATCH] x86/suspend: fix false positive KASAN warning on suspend/resume

On 12/01/2016 02:10 AM, Josh Poimboeuf wrote: > Resuming from a suspend operation is showing a KASAN false positive > warning: > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions

Re: [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias

On 11/29/2016 09:55 PM, Laura Abbott wrote: > __pa_symbol is the correct API to find the physical address of symbols. > Switch to it to allow for debugging APIs to work correctly. But __pa() is correct for symbols. I see how __pa_symbol() might be a little faster than __pa(), but there is nothing

Re: [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias

On 11/29/2016 09:55 PM, Laura Abbott wrote: > __pa_symbol is the correct API to find the physical address of symbols. > Switch to it to allow for debugging APIs to work correctly. But __pa() is correct for symbols. I see how __pa_symbol() might be a little faster than __pa(), but there is nothing

Re: [RFC] kasan: is it a wrong report from kasan?

2016-11-30 11:05 GMT+03:00 Xishi Qiu : > The kernel version is v4.1, and I find some error reports from kasan. > I'm not sure whether it is a wrong report. > This looks like false positive that was fixed in 0d97e6d8024("arm64: kasan: clear stale stack poison"). Also you might

Re: [RFC] kasan: is it a wrong report from kasan?

2016-11-30 11:05 GMT+03:00 Xishi Qiu : > The kernel version is v4.1, and I find some error reports from kasan. > I'm not sure whether it is a wrong report. > This looks like false positive that was fixed in 0d97e6d8024("arm64: kasan: clear stale stack poison"). Also you might need

Re: mm: BUG in pgtable_pmd_page_dtor

apcount:0 mapping: (null) index:0x0 > flags: 0x1000400(reserved) > raw: 01000400 0001 > raw: ea0475e0 ea0475e0 0000 > page dumped because: VM_BUG_ON_PAGE(1) > > [aryabi...@virtuozzo.com: suggested print_hex_dump()] > Signed-off-by: Vlastimil Babka <vba...@suse.cz> Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: mm: BUG in pgtable_pmd_page_dtor

(null) index:0x0 > flags: 0x1000400(reserved) > raw: 01000400 0001 > raw: ea0475e0 ffffea00000475e0 > page dumped because: VM_BUG_ON_PAGE(1) > > [aryabi...@virtuozzo.com: suggested print_hex_dump()] > Signed-off-by: Vlastimil Babka Acked-by: Andrey Ryabinin

Re: mm: BUG in pgtable_pmd_page_dtor

On 11/25/2016 11:42 AM, Vlastimil Babka wrote: > pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx", > page, page_ref_count(page), mapcount, > @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason) > > pr_emerg("flags: %#lx(%pGp)\n",

Re: mm: BUG in pgtable_pmd_page_dtor

On 11/25/2016 11:42 AM, Vlastimil Babka wrote: > pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx", > page, page_ref_count(page), mapcount, > @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason) > > pr_emerg("flags: %#lx(%pGp)\n",

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

, thanks. > David > --- > commit 1dc938c3393d8ff0e04723956ed00ec21e2b2a89 > Author: Andrey Ryabinin <aryabi...@virtuozzo.com> > Date: Wed Nov 23 16:44:47 2016 + > > mpi: Fix NULL ptr dereference in mpi_powm() > > This fixes CVE-2016-8650. > > If mpi_powm()

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

38c3393d8ff0e04723956ed00ec21e2b2a89 > Author: Andrey Ryabinin > Date: Wed Nov 23 16:44:47 2016 + > > mpi: Fix NULL ptr dereference in mpi_powm() > > This fixes CVE-2016-8650. > > If mpi_powm() is given a zero exponent, it wants to immediately re

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:33 GMT+03:00 David Howells <dhowe...@redhat.com>: > Andrey Ryabinin <ryabinin@gmail.com> wrote: > >> > David Howells <dhowe...@redhat.com> wrote: >> > >> >> + if (!rp) { >> >> +

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:33 GMT+03:00 David Howells : > Andrey Ryabinin wrote: > >> > David Howells wrote: >> > >> >> + if (!rp) { >> >> + if (mpi_resize(res, 1) < 0) >> > >> > This is better done with RES

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:35 GMT+03:00 David Howells <dhowe...@redhat.com>: > Andrey Ryabinin <ryabinin@gmail.com> wrote: > >> I'm also made a fix for this yesterday - >> http://lkml.kernel.org/r/1479918484-31952-1-git-send-email-aryabi...@virtuozzo.com > > I should

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:35 GMT+03:00 David Howells : > Andrey Ryabinin wrote: > >> I'm also made a fix for this yesterday - >> http://lkml.kernel.org/r/1479918484-31952-1-git-send-email-aryabi...@virtuozzo.com > > I should add a record to the MAINTAINERS file that directs p

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:17 GMT+03:00 David Howells : > David Howells wrote: > >> + if (!rp) { >> + if (mpi_resize(res, 1) < 0) > > This is better done with RESIZE_IF_NEEDED(). > mpi_resize() is equal to RESIZE_IF_NEEDED(), it also

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 14:17 GMT+03:00 David Howells : > David Howells wrote: > >> + if (!rp) { >> + if (mpi_resize(res, 1) < 0) > > This is better done with RESIZE_IF_NEEDED(). > mpi_resize() is equal to RESIZE_IF_NEEDED(), it also checks for allocated space: int

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 11:51 GMT+03:00 David Howells : > This fixes CVE-2016-8650. > > If mpi_powm() is given a zero exponent, it wants to immediately return > either 1 or 0, depending on the modulus. However, if the result was > initalised with zero limb space, no limbs space is

Re: [PATCH 2/2] MPI: Fix mpi_powm() when exponent is 0 and the result has no limbs

2016-11-24 11:51 GMT+03:00 David Howells : > This fixes CVE-2016-8650. > > If mpi_powm() is given a zero exponent, it wants to immediately return > either 1 or 0, depending on the modulus. However, if the result was > initalised with zero limb space, no limbs space is allocated and a >

[PATCH] X.509: Fix double free in x509_cert_parse()

/0x2a0 [] entry_SYSCALL_64_fastpath+0x1e/0xad Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@vger.kernel.org> --- crypto/asymmetric_keys/x509_cert_parser.c | 1 - 1 file change

[PATCH] X.509: Fix double free in x509_cert_parse()

/0x2a0 [] entry_SYSCALL_64_fastpath+0x1e/0xad Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api") Signed-off-by: Andrey Ryabinin Cc: --- crypto/asymmetric_keys/x509_cert_parser.c | 1 - 1 file changed, 1 deletion(-) diff --git a/crypto/asymmetric_keys/x509_cert_pa

[PATCH] mpi: Fix NULL ptr dereference in mpi_powm()

/fulldisclosure/2016/Nov/76 [2] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526 Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta

[PATCH] mpi: Fix NULL ptr dereference in mpi_powm()

/fulldisclosure/2016/Nov/76 [2] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526 Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)") Signed-off-by: Andrey Ryabinin Cc: --- lib/mpi/mpi-pow.c | 7 ++- 1 file

Re: [PATCH] kasan: turn off -fsanitize-address-use-after-scope for now

..@google.com> and given how simple it is I'd suggest to just backport implementation. BTW, we also need "[PATCH] kasan: update kasan_global for gcc 7" - http://lkml.kernel.org/r/<1479219743-28682-1-git-send-email-dvyu...@google.com> in v4.0+ stable. > Link: > https://g

Re: [PATCH] kasan: turn off -fsanitize-address-use-after-scope for now

..@google.com> and given how simple it is I'd suggest to just backport implementation. BTW, we also need "[PATCH] kasan: update kasan_global for gcc 7" - http://lkml.kernel.org/r/<1479219743-28682-1-git-send-email-dvyu...@google.com> in v4.0+ stable. > Link: > https://gc

Re: [PATCH 07/10] mm: warn about vfree from atomic context

On 11/18/2016 04:03 PM, Christoph Hellwig wrote: > We can't handle vfree itself from atomic context, but callers > can explicitly use vfree_atomic instead, which defers the actual > vfree to a workqueue. Unfortunately in_atomic does not work > on non-preemptible kernels, so we can't just do the

Re: [PATCH 07/10] mm: warn about vfree from atomic context

On 11/18/2016 04:03 PM, Christoph Hellwig wrote: > We can't handle vfree itself from atomic context, but callers > can explicitly use vfree_atomic instead, which defers the actual > vfree to a workqueue. Unfortunately in_atomic does not work > on non-preemptible kernels, so we can't just do the

Re: [PATCH] kasan: support use-after-scope detection

callbacks and add a test. > > Signed-off-by: Dmitry Vyukov <dvyu...@google.com> > Cc: aryabi...@virtuozzo.com > Cc: gli...@google.com > Cc: a...@linux-foundation.org > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH] kasan: support use-after-scope detection

callbacks and add a test. > > Signed-off-by: Dmitry Vyukov > Cc: aryabi...@virtuozzo.com > Cc: gli...@google.com > Cc: a...@linux-foundation.org > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > > --- Acked-by: Andrey Ryabinin

Re: [PATCH] kasan: update kasan_global for gcc 7

mitry Vyukov <dvyu...@google.com> > Cc: aryabi...@virtuozzo.com > Cc: gli...@google.com > Cc: a...@linux-foundation.org > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH] kasan: update kasan_global for gcc 7

ukov > Cc: aryabi...@virtuozzo.com > Cc: gli...@google.com > Cc: a...@linux-foundation.org > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > --- Acked-by: Andrey Ryabinin

Re: [PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice

alov <andreyk...@google.com> Right, since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") printk requires KERN_CONT to continue log messages, and print_ip_sym() doesn't have it. After a small nit bellow fixed: Acked-by: Andrey Ryabinin <

Re: [PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice

Right, since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") printk requires KERN_CONT to continue log messages, and print_ip_sym() doesn't have it. After a small nit bellow fixed: Acked-by: Andrey Ryabinin > --- > kernel/sta

Re: [PATCH 2/2] kasan: improve error reports

On 11/08/2016 10:37 PM, Andrey Konovalov wrote: > 1. Change header format. > 2. Unify header format between different kinds of bad accesses. > 3. Add empty lines between parts of the report to improve readability. > 4. Improve slab object description. > 5. Improve mm/kasan/report.c readability. >

Re: [PATCH 2/2] kasan: improve error reports

On 11/08/2016 10:37 PM, Andrey Konovalov wrote: > 1. Change header format. > 2. Unify header format between different kinds of bad accesses. > 3. Add empty lines between parts of the report to improve readability. > 4. Improve slab object description. > 5. Improve mm/kasan/report.c readability. >

Re: KASAN & the vmalloc area

On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since?

Re: KASAN & the vmalloc area

On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since?

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 11/07/2016 06:09 PM, Christoph Hellwig wrote: > On Mon, Nov 07, 2016 at 06:01:45PM +0300, Andrey Ryabinin wrote: >>> So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we >>> always defer the work in these cases? >>> >>> So for n

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 11/07/2016 06:09 PM, Christoph Hellwig wrote: > On Mon, Nov 07, 2016 at 06:01:45PM +0300, Andrey Ryabinin wrote: >>> So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we >>> always defer the work in these cases? >>> >>> So for n

Re: [PATCH] coredump: fix unfreezable coredumping task

On 11/08/2016 01:26 AM, Andrew Morton wrote: > On Fri, 30 Sep 2016 11:50:34 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> It could be not possible to freeze coredumping task when it waits >> for 'core_state->startup' completion, because threa

Re: [PATCH] coredump: fix unfreezable coredumping task

On 11/08/2016 01:26 AM, Andrew Morton wrote: > On Fri, 30 Sep 2016 11:50:34 +0300 Andrey Ryabinin > wrote: > >> It could be not possible to freeze coredumping task when it waits >> for 'core_state->startup' completion, because threads are frozen >> in get_sig

[PATCH 1/3] mm/vmalloc: add vfree_atomic()

We are going to use sleeping lock for freeing vmap. However some vfree() users want to free memory from atomic (but not from interrupt) context. For this we add vfree_atomic() - deferred variation of vfree() which can be used in any atomic context (except NMIs). Signed-off-by: Andrey Ryabinin

[PATCH 1/3] mm/vmalloc: add vfree_atomic()

We are going to use sleeping lock for freeing vmap. However some vfree() users want to free memory from atomic (but not from interrupt) context. For this we add vfree_atomic() - deferred variation of vfree() which can be used in any atomic context (except NMIs). Signed-off-by: Andrey Ryabinin Cc

[PATCH 3/3] x86/ldt: use vfree_atomic() to free ldt entries

() schedule_tail() ret_from_fork() Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: Andy Lutomirski <l...@kernel.org> Cc: Joel Fernandes <joe...@google.com> Cc: Christoph Hellwig <h...@lst.de> Cc: Jisheng Zhang <jszh...@marvell.com> Cc: Chris Wilson <ch...@

[PATCH 3/3] x86/ldt: use vfree_atomic() to free ldt entries

() schedule_tail() ret_from_fork() Signed-off-by: Andrey Ryabinin Cc: Andy Lutomirski Cc: Joel Fernandes Cc: Christoph Hellwig Cc: Jisheng Zhang Cc: Chris Wilson Cc: John Dias Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/kernel/ldt.c | 2

[PATCH 2/3] kernel/fork: use vfree_atomic() to free thread stack

vfree() is going to use sleeping lock. Thread stack freed in atomic context, therefore we must use vfree_atomic() here. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: Andy Lutomirski <l...@kernel.org> Cc: Joel Fernandes <joe...@google.com> Cc: Christoph Hellwi

[PATCH 2/3] kernel/fork: use vfree_atomic() to free thread stack

vfree() is going to use sleeping lock. Thread stack freed in atomic context, therefore we must use vfree_atomic() here. Signed-off-by: Andrey Ryabinin Cc: Andy Lutomirski Cc: Joel Fernandes Cc: Christoph Hellwig Cc: Jisheng Zhang Cc: Chris Wilson Cc: John Dias Cc: Thomas Gleixner Cc: Ingo

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On 11/08/2016 04:24 PM, Joel Fernandes wrote: > On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson > wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >>> This is how everyone seems to already use them, but let's make that >>> explicit. >> >> Ah,

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On 11/08/2016 04:24 PM, Joel Fernandes wrote: > On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson > wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >>> This is how everyone seems to already use them, but let's make that >>> explicit. >> >> Ah, found an exception,

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 11/05/2016 06:43 AM, Joel Fernandes wrote: > On Mon, Oct 24, 2016 at 8:44 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 10/22/2016 06:17 PM, Christoph Hellwig wrote: >>> We want to be able to use a sleeping lock for freeing vmap to k

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 11/05/2016 06:43 AM, Joel Fernandes wrote: > On Mon, Oct 24, 2016 at 8:44 AM, Andrey Ryabinin > wrote: >> >> >> On 10/22/2016 06:17 PM, Christoph Hellwig wrote: >>> We want to be able to use a sleeping lock for freeing vmap to keep >>> latency down.

Re: [PATCH] coredump: fix unfreezable coredumping task

On 09/30/2016 11:50 AM, Andrey Ryabinin wrote: > It could be not possible to freeze coredumping task when it waits > for 'core_state->startup' completion, because threads are frozen > in get_signal() before they got a chance to complete 'core_state->startup'. > > Use

Re: [PATCH] coredump: fix unfreezable coredumping task

On 09/30/2016 11:50 AM, Andrey Ryabinin wrote: > It could be not possible to freeze coredumping task when it waits > for 'core_state->startup' completion, because threads are frozen > in get_signal() before they got a chance to complete 'core_state->startup'. > > Use

Re: linux-next: build warning in Linus' tree

On 10/30/2016 12:29 AM, Geert Uytterhoeven wrote: > Hi Linus, > > On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds > wrote: >> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds >> wrote: >>> >>> I wonder if we should make KASAN depend

Re: linux-next: build warning in Linus' tree

On 10/30/2016 12:29 AM, Geert Uytterhoeven wrote: > Hi Linus, > > On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds > wrote: >> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds >> wrote: >>> >>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it >>> does seem to disable a lot

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 10/22/2016 06:17 PM, Christoph Hellwig wrote: > We want to be able to use a sleeping lock for freeing vmap to keep > latency down. For this we need to use the deferred vfree mechanisms > no only from interrupt, but from any atomic context. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 10/22/2016 06:17 PM, Christoph Hellwig wrote: > We want to be able to use a sleeping lock for freeing vmap to keep > latency down. For this we need to use the deferred vfree mechanisms > no only from interrupt, but from any atomic context. > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH v2] kasan: support panic_on_warn

_on_warn is set. > > We use this for continuous fuzzing where we want kernel to stop > and reboot on any error. > > Signed-off-by: Dmitry Vyukov <dvyu...@google.com> > Cc: kasan-...@googlegroups.com > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexande

Re: [PATCH v2] kasan: support panic_on_warn

_on_warn is set. > > We use this for continuous fuzzing where we want kernel to stop > and reboot on any error. > > Signed-off-by: Dmitry Vyukov > Cc: kasan-...@googlegroups.com > Cc: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Andrew Morton > Cc: linux...

Re: [PATCH] kasan: support panic_on_warn

On 10/17/2016 11:18 AM, Dmitry Vyukov wrote: > On Mon, Oct 17, 2016 at 10:13 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 10/14/2016 08:10 PM, Dmitry Vyukov wrote: >>> If user sets panic_on_warn, he wants kernel to panic if there is &g

Re: [PATCH] kasan: support panic_on_warn

On 10/17/2016 11:18 AM, Dmitry Vyukov wrote: > On Mon, Oct 17, 2016 at 10:13 AM, Andrey Ryabinin > wrote: >> >> >> On 10/14/2016 08:10 PM, Dmitry Vyukov wrote: >>> If user sets panic_on_warn, he wants kernel to panic if there is >>> anything barely wr

Re: [PATCH] kasan: support panic_on_warn

_on_warn is set. > > We use this for continuous fuzzing where we want kernel to stop > and reboot on any error. > > Signed-off-by: Dmitry Vyukov <dvyu...@google.com> > Cc: kasan-...@googlegroups.com > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexande

<    5   6   7   8   9   10   11   12   13   14   >