Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Should normally be used in "DIRECT" mode.
Acked-by: Kees Cook
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
refusing to do a fixup in the pagefault handler code when a userspace
accessor causes #PF on a kernel address and the current context isn't
whitelisted.
Signed-off-by: Jann Horn
---
v3:
- whitelist exact_copy
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
v3:
- really plumb the error code through to the handlers (Andy)
arch/x86/include/asm/extable.h | 3 +-
arch/x86
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
refusing to do a fixup in the pagefault handler code when a userspace
accessor causes #PF on a kernel address and the current context isn't
whitelisted.
Signed-off-by: Jann Horn
---
v3:
- whitelist exact_copy
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
v3:
- really plumb the error code through to the handlers (Andy)
arch/x86/include/asm/extable.h | 3 +-
arch/x86
(in particular, checking whether the fault address is actually in
userspace), introduce a new exception table handler ex_handler_uaccess()
and wire it up to all the user access fixups (excluding ones that
already use _ASM_EXTABLE_EX).
Signed-off-by: Jann Horn
---
NOTE: I haven't touched the two
(in particular, checking whether the fault address is actually in
userspace), introduce a new exception table handler ex_handler_uaccess()
and wire it up to all the user access fixups (excluding ones that
already use _ASM_EXTABLE_EX).
Signed-off-by: Jann Horn
---
NOTE: I haven't touched the two
something crazy like changing RIP
so that it suddenly points to an instruction that does userspace access.)
For #PF on a kernel address from kernel space, after the kprobe fault
handler has run, we'll go into no_context(), which calls fixup_exception().
Acked-by: Masami Hiramatsu
Signed-off-by:
something crazy like changing RIP
so that it suddenly points to an instruction that does userspace access.)
For #PF on a kernel address from kernel space, after the kprobe fault
handler has run, we'll go into no_context(), which calls fixup_exception().
Acked-by: Masami Hiramatsu
Signed-off-by:
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
arch/x86
6 is the main semantic change.
Patch 7 is a small testcase for verifying that patch 6 works.
Jann Horn (7):
x86: refactor kprobes_fault() like kprobe_exceptions_notify()
x86: inline kprobe_exceptions_notify() into do_general_protection()
x86: stop calling fixup_exception() from kprobe_fault_hand
6 is the main semantic change.
Patch 7 is a small testcase for verifying that patch 6 works.
Jann Horn (7):
x86: refactor kprobes_fault() like kprobe_exceptions_notify()
x86: inline kprobe_exceptions_notify() into do_general_protection()
x86: stop calling fixup_exception() from kprobe_fault_hand
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
arch/x86
Also, use X86_TRAP_PF instead of 14.
Signed-off-by: Jann Horn
---
v3:
- avoid unnecessary branch on return value and split up the checks
(Borislav Petkov)
arch/x86/mm/fault.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/fault.c b/a
Also, use X86_TRAP_PF instead of 14.
Signed-off-by: Jann Horn
---
v3:
- avoid unnecessary branch on return value and split up the checks
(Borislav Petkov)
arch/x86/mm/fault.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/fault.c b/a
interesting if vmapped stacks and KASAN were
compatible, since then handle_stack_overflow() would oops from exception
stack context.
Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before
do_exit()")
Signed-off-by: Jann Horn
---
v2:
- Rewrite, do it in C from oops_end
interesting if vmapped stacks and KASAN were
compatible, since then handle_stack_overflow() would oops from exception
stack context.
Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before
do_exit()")
Signed-off-by: Jann Horn
---
v2:
- Rewrite, do it in C from oops_end
On Tue, Aug 28, 2018 at 6:25 PM Borislav Petkov wrote:
>
> On Tue, Aug 28, 2018 at 05:49:01PM +0200, Jann Horn wrote:
> > show_opcodes() is used both for dumping kernel instructions and for dumping
> > user instructions. If userspace causes #PF by jumping to a kernel address
On Tue, Aug 28, 2018 at 6:25 PM Borislav Petkov wrote:
>
> On Tue, Aug 28, 2018 at 05:49:01PM +0200, Jann Horn wrote:
> > show_opcodes() is used both for dumping kernel instructions and for dumping
> > user instructions. If userspace causes #PF by jumping to a kernel address
ing kernel memory into dmesg.
Cc: sta...@vger.kernel.org
Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function")
Reviewed-by: Kees Cook
Signed-off-by: Jann Horn
---
v2: Andy pointed out that I probably shouldn't be doing wrapping
arithmetic on pointers.
arch/x86/include/asm/stac
ing kernel memory into dmesg.
Cc: sta...@vger.kernel.org
Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function")
Reviewed-by: Kees Cook
Signed-off-by: Jann Horn
---
v2: Andy pointed out that I probably shouldn't be doing wrapping
arithmetic on pointers.
arch/x86/include/asm/stac
ing kernel memory into dmesg.
Cc: sta...@vger.kernel.org
Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function")
Signed-off-by: Jann Horn
---
arch/x86/include/asm/stacktrace.h | 2 +-
arch/x86/kernel/dumpstack.c | 13 ++---
arch/x86/mm/fault.c |
ing kernel memory into dmesg.
Cc: sta...@vger.kernel.org
Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function")
Signed-off-by: Jann Horn
---
arch/x86/include/asm/stacktrace.h | 2 +-
arch/x86/kernel/dumpstack.c | 13 ++---
arch/x86/mm/fault.c |
On Tue, Aug 28, 2018 at 1:33 PM Andrey Ryabinin wrote:
> 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(), b
On Tue, Aug 28, 2018 at 1:33 PM Andrey Ryabinin wrote:
> 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(), b
On Tue, Aug 28, 2018 at 11:04 AM Andrey Ryabinin
wrote:
>
> 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
On Tue, Aug 28, 2018 at 11:04 AM Andrey Ryabinin
wrote:
>
> 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
On Mon, Aug 27, 2018 at 8:58 PM Jann Horn wrote:
>
> There have been multiple kernel vulnerabilities that permitted userspace to
> pass completely unchecked pointers through to userspace accessors:
>
> - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
>
On Mon, Aug 27, 2018 at 8:58 PM Jann Horn wrote:
>
> There have been multiple kernel vulnerabilities that permitted userspace to
> pass completely unchecked pointers through to userspace accessors:
>
> - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
>
On Tue, Aug 28, 2018 at 1:26 AM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 4:12 PM, Jann Horn wrote:
> > On Tue, Aug 28, 2018 at 1:04 AM Andy Lutomirski wrote:
> >>
> >> In NMI context, we might be in the middle of context switching or in
> &g
On Tue, Aug 28, 2018 at 1:26 AM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 4:12 PM, Jann Horn wrote:
> > On Tue, Aug 28, 2018 at 1:04 AM Andy Lutomirski wrote:
> >>
> >> In NMI context, we might be in the middle of context switching or in
> &g
On Tue, Aug 28, 2018 at 1:04 AM Andy Lutomirski wrote:
>
> In NMI context, we might be in the middle of context switching or in
> the middle of switch_mm_irqs_off(). In either case, CR3 might not
> match current->mm, which could cause copy_from_user_nmi() and
> friends to read the wrong memory.
On Tue, Aug 28, 2018 at 1:04 AM Andy Lutomirski wrote:
>
> In NMI context, we might be in the middle of context switching or in
> the middle of switch_mm_irqs_off(). In either case, CR3 might not
> match current->mm, which could cause copy_from_user_nmi() and
> friends to read the wrong memory.
On Mon, Aug 27, 2018 at 9:09 PM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> > This is preparation for looking at trap number and fault address in the
> > handlers for uaccess errors.
> > This patch should not change any behavior.
>
On Mon, Aug 27, 2018 at 9:09 PM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> > This is preparation for looking at trap number and fault address in the
> > handlers for uaccess errors.
> > This patch should not change any behavior.
>
On Mon, Aug 27, 2018 at 9:02 PM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> > This removes the call into exception fixup that was added in
> > commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
>
On Mon, Aug 27, 2018 at 9:02 PM Andy Lutomirski wrote:
>
> On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> > This removes the call into exception fixup that was added in
> > commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
>
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Should normally be used in "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/l
(in particular, checking whether the fault address is actually in
userspace), introduce a new exception table handler ex_handler_uaccess()
and wire it up to all the user access fixups (excluding ones that
already use _ASM_EXTABLE_EX).
Signed-off-by: Jann Horn
---
NOTE: I haven't touched the two
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Should normally be used in "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/l
(in particular, checking whether the fault address is actually in
userspace), introduce a new exception table handler ex_handler_uaccess()
and wire it up to all the user access fixups (excluding ones that
already use _ASM_EXTABLE_EX).
Signed-off-by: Jann Horn
---
NOTE: I haven't touched the two
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
refusing to do a fixup in the pagefault handler code when a userspace
accessor causes #PF on a kernel address and the current context isn't
whitelisted.
Signed-off-by: Jann Horn
---
arch/x86/mm/exta
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
refusing to do a fixup in the pagefault handler code when a userspace
accessor causes #PF on a kernel address and the current context isn't
whitelisted.
Signed-off-by: Jann Horn
---
arch/x86/mm/exta
something crazy like changing RIP
so that it suddenly points to an instruction that does userspace access.)
For #PF on a kernel address from kernel space, after the kprobe fault
handler has run, we'll go into no_context(), which calls fixup_exception().
Signed-off-by: Jann Horn
---
arch/
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/extable.h | 3 ++-
arch/x86/include/asm/ptrace.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce.c | 2
something crazy like changing RIP
so that it suddenly points to an instruction that does userspace access.)
For #PF on a kernel address from kernel space, after the kprobe fault
handler has run, we'll go into no_context(), which calls fixup_exception().
Signed-off-by: Jann Horn
---
arch/
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/extable.h | 3 ++-
arch/x86/include/asm/ptrace.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce.c | 2
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
arch/x86
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
arch/x86
y based on code
from the v1 patch. They've changed quite a bit though.
Patch 6 is the main semantic change.
Patch 7 is a small testcase for verifying that patch 6 works.
Jann Horn (7):
x86: refactor kprobes_fault() like kprobe_exceptions_notify()
x86: inline kprobe_exceptions_notify() into d
Also, use X86_TRAP_PF instead of 14.
Signed-off-by: Jann Horn
---
arch/x86/mm/fault.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index b9123c497e0a..2254a30533b9 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/
Also, use X86_TRAP_PF instead of 14.
Signed-off-by: Jann Horn
---
arch/x86/mm/fault.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index b9123c497e0a..2254a30533b9 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/
y based on code
from the v1 patch. They've changed quite a bit though.
Patch 6 is the main semantic change.
Patch 7 is a small testcase for verifying that patch 6 works.
Jann Horn (7):
x86: refactor kprobes_fault() like kprobe_exceptions_notify()
x86: inline kprobe_exceptions_notify() into d
On Mon, Aug 27, 2018 at 10:13 AM Peter Zijlstra wrote:
>
> On Mon, Aug 27, 2018 at 12:03:05PM +0900, Masami Hiramatsu wrote:
> > On Sun, 26 Aug 2018 11:09:58 +0200
> > Peter Zijlstra wrote:
>
> > > FWIW, before text_poke_bp(), text_poke() would only be used from
> > > stop_machine, so all the
On Mon, Aug 27, 2018 at 10:13 AM Peter Zijlstra wrote:
>
> On Mon, Aug 27, 2018 at 12:03:05PM +0900, Masami Hiramatsu wrote:
> > On Sun, 26 Aug 2018 11:09:58 +0200
> > Peter Zijlstra wrote:
>
> > > FWIW, before text_poke_bp(), text_poke() would only be used from
> > > stop_machine, so all the
On Sun, Aug 26, 2018 at 6:21 AM Andy Lutomirski wrote:
>
> On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote:
> > On Fri, 24 Aug 2018 21:23:26 -0700
> > Andy Lutomirski wrote:
> >> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3?
> >
> > No, since kmap_atomic()
On Sun, Aug 26, 2018 at 6:21 AM Andy Lutomirski wrote:
>
> On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote:
> > On Fri, 24 Aug 2018 21:23:26 -0700
> > Andy Lutomirski wrote:
> >> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3?
> >
> > No, since kmap_atomic()
On Mon, Aug 27, 2018 at 12:11 AM Kees Cook wrote:
>
> On Sun, Aug 26, 2018 at 1:15 PM, Thomas Gleixner wrote:
> > On Sun, 26 Aug 2018, Andy Lutomirski wrote:
> >> > On Aug 26, 2018, at 9:47 AM, Kees Cook wrote:
> >> >> On Sun, Aug 26, 2018 at 7:20 AM, Andy Lutomirski
> >> >> wrote:
> >> >>> I
On Mon, Aug 27, 2018 at 12:11 AM Kees Cook wrote:
>
> On Sun, Aug 26, 2018 at 1:15 PM, Thomas Gleixner wrote:
> > On Sun, 26 Aug 2018, Andy Lutomirski wrote:
> >> > On Aug 26, 2018, at 9:47 AM, Kees Cook wrote:
> >> >> On Sun, Aug 26, 2018 at 7:20 AM, Andy Lutomirski
> >> >> wrote:
> >> >>> I
likely have bigger things to worry
about. It'd be more interesting if vmapped stacks and KASAN were
compatible, since then handle_stack_overflow() would oops from exception
stack context.
Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before
do_exit()")
Signed-of
likely have bigger things to worry
about. It'd be more interesting if vmapped stacks and KASAN were
compatible, since then handle_stack_overflow() would oops from exception
stack context.
Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before
do_exit()")
Signed-of
Some while back (commit 2deb4be28077 ("x86/dumpstack: When OOPSing,
rewind the stack before do_exit()")), Andy added
rewind_stack_do_exit(), which is used in kernel oops handling to
discard the current stack contents and reset the stack pointer,
ensuring that the whole kernel stack is available
Some while back (commit 2deb4be28077 ("x86/dumpstack: When OOPSing,
rewind the stack before do_exit()")), Andy added
rewind_stack_do_exit(), which is used in kernel oops handling to
discard the current stack contents and reset the stack pointer,
ensuring that the whole kernel stack is available
On Thu, Aug 23, 2018 at 2:28 AM Andy Lutomirski wrote:
>
> On Wed, Aug 22, 2018 at 4:53 PM, Jann Horn wrote:
> > On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> >> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> >> > There have been multiple k
On Thu, Aug 23, 2018 at 2:28 AM Andy Lutomirski wrote:
>
> On Wed, Aug 22, 2018 at 4:53 PM, Jann Horn wrote:
> > On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> >> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> >> > There have been multiple k
On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> > There have been multiple kernel vulnerabilities that permitted userspace to
> > pass completely unchecked pointers through to userspace accessors:
> >
> &g
On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> > There have been multiple kernel vulnerabilities that permitted userspace to
> > pass completely unchecked pointers through to userspace accessors:
> >
> &g
On Mon, Aug 13, 2018 at 7:42 PM Will Deacon wrote:
>
> Hi Jann,
>
> On Fri, Aug 10, 2018 at 05:19:38AM +0200, Jann Horn wrote:
> > On Thu, Aug 2, 2018 at 5:16 PM Jann Horn wrote:
> > >
> > > This fixes the following issues:
> > >
> > >
On Mon, Aug 13, 2018 at 7:42 PM Will Deacon wrote:
>
> Hi Jann,
>
> On Fri, Aug 10, 2018 at 05:19:38AM +0200, Jann Horn wrote:
> > On Thu, Aug 2, 2018 at 5:16 PM Jann Horn wrote:
> > >
> > > This fixes the following issues:
> > >
> > >
On Thu, Aug 2, 2018 at 5:16 PM Jann Horn wrote:
>
> This fixes the following issues:
>
> - When a buffer size is supplied to reiserfs_listxattr() such that each
>individual name fits, but the concatenation of all names doesn't
>fit, reiserfs_listxattr() overflows t
On Thu, Aug 2, 2018 at 5:16 PM Jann Horn wrote:
>
> This fixes the following issues:
>
> - When a buffer size is supplied to reiserfs_listxattr() such that each
>individual name fits, but the concatenation of all names doesn't
>fit, reiserfs_listxattr() overflows t
On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> >
> > There have been multiple kernel vulnerabilities that permitted userspace to
> > pass completely unchecked pointers through to userspace accessors:
> >
&
On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
> >
> > There have been multiple kernel vulnerabilities that permitted userspace to
> > pass completely unchecked pointers through to userspace accessors:
> >
&
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
WARN()ing in the pagefault handler code when a userspace accessor causes
#PF on a kernel address and the current context isn't whitelisted.
Signed-off-by: Jann Horn
---
This is a hacky, quickly thrown-together
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Test with "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/lkdtm/usercopy.c | 13 ++
least
WARN().
This patch attempts to make such misbehaving code a bit more visible by
WARN()ing in the pagefault handler code when a userspace accessor causes
#PF on a kernel address and the current context isn't whitelisted.
Signed-off-by: Jann Horn
---
This is a hacky, quickly thrown-together
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Test with "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/lkdtm/usercopy.c | 13 ++
look at this code goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Signed-off-by: Jann Horn
---
I have tested this by manually patching error injection into
fill_with_dentries().
Opinions? Is this a sensible change?
Because the chan
look at this code goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Signed-off-by: Jann Horn
---
I have tested this by manually patching error injection into
fill_with_dentries().
Opinions? Is this a sensible change?
Because the chan
tor calling convention is suboptimal and should be
changed.
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Triggering the bug:
root@debian:/home/user# mount -o user_xattr reiserimg reisermount/
root@debian:/
tor calling convention is suboptimal and should be
changed.
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Triggering the bug:
root@debian:/home/user# mount -o user_xattr reiserimg reisermount/
root@debian:/
On Wed, Aug 1, 2018 at 9:44 AM Jürg Billeter wrote:
>
> On Tue, 2018-07-31 at 18:26 +0200, Jann Horn wrote:
> > On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote:
> >
> > [...]
> > > diff --git a/kernel/sys.c b/kernel/sys.c
> > > index 38509dc1f7
On Wed, Aug 1, 2018 at 9:44 AM Jürg Billeter wrote:
>
> On Tue, 2018-07-31 at 18:26 +0200, Jann Horn wrote:
> > On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote:
> >
> > [...]
> > > diff --git a/kernel/sys.c b/kernel/sys.c
> > > index 38509dc1f7
On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote:
>
> PR_SET_KILLABLE clears the SIGNAL_UNKILLABLE flag. This allows
> CLONE_NEWPID tasks to restore normal signal behavior, opting out of the
> special signal protection for init processes.
>
> This is required for job control in a shell that
On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote:
>
> PR_SET_KILLABLE clears the SIGNAL_UNKILLABLE flag. This allows
> CLONE_NEWPID tasks to restore normal signal behavior, opting out of the
> special signal protection for init processes.
>
> This is required for job control in a shell that
On Sun, Jul 29, 2018 at 10:50 AM David Howells wrote:
>
> Jann Horn wrote:
>
> > [...]
> > > + case fsconfig_set_binary:
> > > + param.type = fs_value_is_blob;
> > > + param.size = aux;
> > > +
On Sun, Jul 29, 2018 at 10:50 AM David Howells wrote:
>
> Jann Horn wrote:
>
> > [...]
> > > + case fsconfig_set_binary:
> > > + param.type = fs_value_is_blob;
> > > + param.size = aux;
> > > +
On Sat, Jul 28, 2018 at 1:51 AM David Howells wrote:
> David Howells wrote:
>
> > One thing I'm confused about is that fat has both a codepage and a charset
> > and
> > I'm not sure of the difference.
>
> In fact, it's not clear that the codepage is actually used.
>
> warthog>git grep
On Sat, Jul 28, 2018 at 1:51 AM David Howells wrote:
> David Howells wrote:
>
> > One thing I'm confused about is that fat has both a codepage and a charset
> > and
> > I'm not sure of the difference.
>
> In fact, it's not clear that the codepage is actually used.
>
> warthog>git grep
On Fri, Jul 27, 2018 at 7:36 PM David Howells wrote:
>
> Add a system call to allow filesystem information to be queried. A request
> value can be given to indicate the desired attribute. Support is provided
> for enumerating multi-value attributes.
[...]
> +static int fsinfo_generic_ids(struct
On Fri, Jul 27, 2018 at 7:36 PM David Howells wrote:
>
> Add a system call to allow filesystem information to be queried. A request
> value can be given to indicate the desired attribute. Support is provided
> for enumerating multi-value attributes.
[...]
> +static int fsinfo_generic_ids(struct
On Fri, Jul 27, 2018 at 7:34 PM David Howells wrote:
>
> Add a syscall for configuring a filesystem creation context and triggering
> actions upon it, to be used in conjunction with fsopen, fspick and fsmount.
>
> long fsconfig(int fs_fd, unsigned int cmd, const char *key,
>
On Fri, Jul 27, 2018 at 7:34 PM David Howells wrote:
>
> Add a syscall for configuring a filesystem creation context and triggering
> actions upon it, to be used in conjunction with fsopen, fspick and fsmount.
>
> long fsconfig(int fs_fd, unsigned int cmd, const char *key,
>
+cc jeffv
On Fri, Jul 27, 2018 at 8:47 PM Jann Horn wrote:
>
> On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
> >
> > Any system can chose to change the permissions of a sysfs node, default,
> > DAC (and MAC) is just layers of multi-level security (or lac
+cc jeffv
On Fri, Jul 27, 2018 at 8:47 PM Jann Horn wrote:
>
> On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
> >
> > Any system can chose to change the permissions of a sysfs node, default,
> > DAC (and MAC) is just layers of multi-level security (or lac
On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
>
> Any system can chose to change the permissions of a sysfs node, default, DAC
> (and MAC) is just layers of multi-level security (or lack thereof). As well
> intentioned as a default DAC is in the kernel, leaking kernel addresses is
>
On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
>
> Any system can chose to change the permissions of a sysfs node, default, DAC
> (and MAC) is just layers of multi-level security (or lack thereof). As well
> intentioned as a default DAC is in the kernel, leaking kernel addresses is
>
On Fri, Jul 27, 2018 at 2:07 PM Jordan Glover
wrote:
>
> On July 27, 2018 12:15 AM, Steven Rostedt wrote:
>
> > On Thu, 26 Jul 2018 09:52:11 -0700
> > Nick Desaulniers ndesaulni...@google.com wrote:
> >
> > > See the section "Kernel addresses" in
> > > Documentation/security/self-protection.
On Fri, Jul 27, 2018 at 2:07 PM Jordan Glover
wrote:
>
> On July 27, 2018 12:15 AM, Steven Rostedt wrote:
>
> > On Thu, 26 Jul 2018 09:52:11 -0700
> > Nick Desaulniers ndesaulni...@google.com wrote:
> >
> > > See the section "Kernel addresses" in
> > > Documentation/security/self-protection.
+Linus, Andy, Al from the other thread
On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > b
901 - 1000 of 1477 matches
Mail list logo
