On Wed, Sep 19, 2018 at 6:13 PM Cyrill Gorcunov wrote:
>
> On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote:
> ...
> > >
> > > Heh, actually not :) It is due to commit
> > >
> > > commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> > >
stack")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Resending because I forgot to send this to akpm the first time.
fs/proc/base.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ccf86f16d9f0..7e9f07bf260d 100644
--- a/fs/p
stack")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Resending because I forgot to send this to akpm the first time.
fs/proc/base.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ccf86f16d9f0..7e9f07bf260d 100644
--- a/fs/p
On Thu, Sep 13, 2018 at 4:39 PM Kees Cook wrote:
> On Thu, Sep 13, 2018 at 4:55 AM, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
> >>
> >> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> >> > +linux-api, I guess
> >&g
On Thu, Sep 13, 2018 at 4:39 PM Kees Cook wrote:
> On Thu, Sep 13, 2018 at 4:55 AM, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
> >>
> >> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> >> > +linux-api, I guess
> >&g
On Fri, Sep 21, 2018 at 3:39 PM Tycho Andersen wrote:
> On Thu, Sep 20, 2018 at 07:18:45PM -0700, Andy Lutomirski wrote:
> > On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen wrote:
> > > On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > > > On Wed, Sep 19, 2018 at 7:38 AM, Tycho
On Fri, Sep 21, 2018 at 3:39 PM Tycho Andersen wrote:
> On Thu, Sep 20, 2018 at 07:18:45PM -0700, Andy Lutomirski wrote:
> > On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen wrote:
> > > On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > > > On Wed, Sep 19, 2018 at 7:38 AM, Tycho
aa_label *label = aa_current_raw_label();
> >
> > --> might_sleep();
> >
> > Take a look please, once time permit.
>
> Heh, actually not :) It is due to commit
>
> commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> Author: Jann Horn
> Date: Thu Sep
aa_label *label = aa_current_raw_label();
> >
> > --> might_sleep();
> >
> > Take a look please, once time permit.
>
> Heh, actually not :) It is due to commit
>
> commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> Author: Jann Horn
> Date: Thu Sep
On Tue, Sep 18, 2018 at 2:05 AM Hugh Dickins wrote:
>
> Hi Jann,
>
> On Mon, 17 Sep 2018, Jann Horn wrote:
>
> > [I'm not sure who the best people to ask about this are, I hope the
> > recipient list resembles something reasonable...]
> >
> > I have no
On Tue, Sep 18, 2018 at 2:05 AM Hugh Dickins wrote:
>
> Hi Jann,
>
> On Mon, 17 Sep 2018, Jann Horn wrote:
>
> > [I'm not sure who the best people to ask about this are, I hope the
> > recipient list resembles something reasonable...]
> >
> > I have no
[I'm not sure who the best people to ask about this are, I hope the
recipient list resembles something reasonable...]
I have noticed that the dup_mmap() logic on fork() doesn't handle
pages with active direct I/O properly: dup_mmap() seems to assume that
making the PTE referencing a page readonly
[I'm not sure who the best people to ask about this are, I hope the
recipient list resembles something reasonable...]
I have noticed that the dup_mmap() logic on fork() doesn't handle
pages with active direct I/O properly: dup_mmap() seems to assume that
making the PTE referencing a page readonly
On Sun, Sep 16, 2018 at 3:14 AM Kees Cook wrote:
> In order to adjust LSM selection logic in the future, this moves the
> selection logic up out of the individual LSMs, making their init functions
> only run when actually enabled.
[...]
> +/* Is an LSM allowed to be enabled? */
> +static bool
On Sun, Sep 16, 2018 at 3:14 AM Kees Cook wrote:
> In order to adjust LSM selection logic in the future, this moves the
> selection logic up out of the individual LSMs, making their init functions
> only run when actually enabled.
[...]
> +/* Is an LSM allowed to be enabled? */
> +static bool
On Sun, Sep 16, 2018 at 3:11 AM Kees Cook wrote:
> Split initialization loop into two phases: "exclusive" LSMs and "minor"
> LSMs.
>
> Signed-off-by: Kees Cook
> ---
> include/linux/lsm_hooks.h | 6 ++
> security/security.c | 8 +---
> 2 files changed, 11 insertions(+), 3
On Sun, Sep 16, 2018 at 3:11 AM Kees Cook wrote:
> Split initialization loop into two phases: "exclusive" LSMs and "minor"
> LSMs.
>
> Signed-off-by: Kees Cook
> ---
> include/linux/lsm_hooks.h | 6 ++
> security/security.c | 8 +---
> 2 files changed, 11 insertions(+), 3
On Fri, Sep 14, 2018 at 8:08 PM Prakash Sangappa
wrote:
> On 9/14/18 5:49 AM, Jann Horn wrote:
> > On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
> >> On Fri 14-09-18 03:33:28, Jann Horn wrote:
> >>> On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
> >&
On Fri, Sep 14, 2018 at 8:08 PM Prakash Sangappa
wrote:
> On 9/14/18 5:49 AM, Jann Horn wrote:
> > On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
> >> On Fri 14-09-18 03:33:28, Jann Horn wrote:
> >>> On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
> >&
On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
> On Fri 14-09-18 03:33:28, Jann Horn wrote:
> > On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
> > wrote:
> > > On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > > > On 05/07/2018 06:16 PM, prakash.sanga
On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
> On Fri 14-09-18 03:33:28, Jann Horn wrote:
> > On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
> > wrote:
> > > On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > > > On 05/07/2018 06:16 PM, prakash.sanga
On Fri, Sep 14, 2018 at 1:14 PM My Name <18650033...@163.com> wrote:
> Adversaries often attack the Linux kernel via using
> commit_creds(prepare_kernel_cred(0)) to submit ROOT
> credential for the purpose of privilege escalation.
> For processes inside the Linux container, the above
> approach
On Fri, Sep 14, 2018 at 1:14 PM My Name <18650033...@163.com> wrote:
> Adversaries often attack the Linux kernel via using
> commit_creds(prepare_kernel_cred(0)) to submit ROOT
> credential for the purpose of privilege escalation.
> For processes inside the Linux container, the above
> approach
On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
wrote:
> On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > On 05/07/2018 06:16 PM, prakash.sangappa wrote:
> >> It will be /proc//numa_vamaps. Yes, the behavior will be
> >> different with respect to seeking. Output will still be text and
> >> the
On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
wrote:
> On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > On 05/07/2018 06:16 PM, prakash.sangappa wrote:
> >> It will be /proc//numa_vamaps. Yes, the behavior will be
> >> different with respect to seeking. Output will still be text and
> >> the
+cc keyrings list
On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi wrote:
> This patch adds a snapshot keys handler for using the key retention
> service api to create keys for snapshot image encryption and
> authentication.
>
> This handler uses TPM trusted key as the snapshot master key, and the
>
+cc keyrings list
On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi wrote:
> This patch adds a snapshot keys handler for using the key retention
> service api to create keys for snapshot image encryption and
> authentication.
>
> This handler uses TPM trusted key as the snapshot master key, and the
>
On Thu, Sep 13, 2018 at 3:01 PM Peter Zijlstra wrote:
> Provide a generic tlb_flush() implementation that relies on
> flush_tlb_range(). This is a little awkward because flush_tlb_range()
> assumes a VMA for range invalidation, but we no longer have one.
>
> Audit of all flush_tlb_range()
On Thu, Sep 13, 2018 at 3:01 PM Peter Zijlstra wrote:
> Provide a generic tlb_flush() implementation that relies on
> flush_tlb_range(). This is a little awkward because flush_tlb_range()
> assumes a VMA for range invalidation, but we no longer have one.
>
> Audit of all flush_tlb_range()
On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
>
> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> > +linux-api, I guess
> >
> > On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
> >>
> >> Restrict the ability to inspect kernel stacks of arbitr
On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
>
> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> > +linux-api, I guess
> >
> > On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
> >>
> >> Restrict the ability to inspect kernel stacks of arbitr
+linux-api, I guess
On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
>
> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> in order to prevent a local attacker from exploiting racy stack unwinding
> to leak kernel task stack contents.
> See the added comme
+linux-api, I guess
On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
>
> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> in order to prevent a local attacker from exploiting racy stack unwinding
> to leak kernel task stack contents.
> See the added comme
stack")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
fs/proc/base.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ccf86f16d9f0..7e9f07bf260d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -407,6 +407,20 @@
stack")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
fs/proc/base.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ccf86f16d9f0..7e9f07bf260d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -407,6 +407,20 @@
On Thu, Sep 6, 2018 at 8:30 PM Tycho Andersen wrote:
> On Thu, Sep 06, 2018 at 10:22:46AM -0600, Tycho Andersen wrote:
> > On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> > > On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > > > The idea here
On Thu, Sep 6, 2018 at 8:30 PM Tycho Andersen wrote:
> On Thu, Sep 06, 2018 at 10:22:46AM -0600, Tycho Andersen wrote:
> > On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> > > On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > > > The idea here
On Sat, Sep 8, 2018 at 2:28 AM Dave Hansen wrote:
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right now, we handle vsyscall emulation
On Sat, Sep 8, 2018 at 2:28 AM Dave Hansen wrote:
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right now, we handle vsyscall emulation
On Sat, Sep 8, 2018 at 2:25 AM Dave Hansen wrote:
> We will shortly be using this check in two locations. Put it in
> a helper before we do so.
[...]
> +/*
> + * The (legacy) vsyscall page is the long page in the kernel portion
> + * of the address space that has user-accessible permissions.
> +
On Sat, Sep 8, 2018 at 2:25 AM Dave Hansen wrote:
> We will shortly be using this check in two locations. Put it in
> a helper before we do so.
[...]
> +/*
> + * The (legacy) vsyscall page is the long page in the kernel portion
> + * of the address space that has user-accessible permissions.
> +
On Sat, Sep 8, 2018 at 2:22 AM Dave Hansen wrote:
> +* Kernel-mode access to the user address space should only occur
> +* inside well-defined areas of code listed in the exception
Actually, not areas, but single whitelisted instructions. It would
probably be nice to say that
On Sat, Sep 8, 2018 at 2:22 AM Dave Hansen wrote:
> +* Kernel-mode access to the user address space should only occur
> +* inside well-defined areas of code listed in the exception
Actually, not areas, but single whitelisted instructions. It would
probably be nice to say that
On Fri, Sep 7, 2018 at 4:28 PM Wei Wang wrote:
> This patch adds support to KVM to save/restore the lbr stack on vCPU
> context switching.
>
> When the guest sets the ACTIVE bit of MSR_KVM_PV_LBR_CTRL, a perf event
> is created on the host for the related vCPU. This perf event ensures the
> LBR
On Fri, Sep 7, 2018 at 4:28 PM Wei Wang wrote:
> This patch adds support to KVM to save/restore the lbr stack on vCPU
> context switching.
>
> When the guest sets the ACTIVE bit of MSR_KVM_PV_LBR_CTRL, a perf event
> is created on the host for the related vCPU. This perf event ensures the
> LBR
Hi!
I noticed the following check in smk_ptrace_rule_check():
if (tracer_known->smk_known == tracee_known->smk_known)
rc = 0;
else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)
rc = -EACCES;
else
Hi!
I noticed the following check in smk_ptrace_rule_check():
if (tracer_known->smk_known == tracee_known->smk_known)
rc = 0;
else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)
rc = -EACCES;
else
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> The idea here is that the userspace handler should be able to pass an fd
> back to the trapped task, for example so it can be returned from socket().
[...]
> diff --git a/Documentation/userspace-api/seccomp_filter.rst
>
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> The idea here is that the userspace handler should be able to pass an fd
> back to the trapped task, for example so it can be returned from socket().
[...]
> diff --git a/Documentation/userspace-api/seccomp_filter.rst
>
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
serves as documentation for the reader.
Signed-off-by: Jann Horn
---
security/yama/yama_lsm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index ffda91a4a1aa..3b18e4455f53 100644
--- a/security/yama/yama_lsm.c
+++ b
serves as documentation for the reader.
Signed-off-by: Jann Horn
---
security/yama/yama_lsm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index ffda91a4a1aa..3b18e4455f53 100644
--- a/security/yama/yama_lsm.c
+++ b
Commit-ID: 9fe6299dde587788f245e9f7a5a1b296fad4e8c7
Gitweb: https://git.kernel.org/tip/9fe6299dde587788f245e9f7a5a1b296fad4e8c7
Author: Jann Horn
AuthorDate: Fri, 31 Aug 2018 21:41:51 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 6 Sep 2018 14:33:12 +0200
x86/process: Don't mix
Commit-ID: 9fe6299dde587788f245e9f7a5a1b296fad4e8c7
Gitweb: https://git.kernel.org/tip/9fe6299dde587788f245e9f7a5a1b296fad4e8c7
Author: Jann Horn
AuthorDate: Fri, 31 Aug 2018 21:41:51 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 6 Sep 2018 14:33:12 +0200
x86/process: Don't mix
On Fri, Aug 31, 2018 at 10:12 PM Andy Lutomirski wrote:
>
> On Fri, Aug 31, 2018 at 12:41 PM, Jann Horn wrote:
> > When the kernel.print-fatal-signals sysctl has been enabled (I don't know
> > whether anyone actually enables it), a simple userspace crash will cause
>
On Fri, Aug 31, 2018 at 10:12 PM Andy Lutomirski wrote:
>
> On Fri, Aug 31, 2018 at 12:41 PM, Jann Horn wrote:
> > When the kernel.print-fatal-signals sysctl has been enabled (I don't know
> > whether anyone actually enables it), a simple userspace crash will cause
>
, some filesystems just
cram numbers in there.
Check the type of the supplied file descriptor to be safe, analogous to how
other places in the kernel do it.
Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
Signed-off-by: Jann Horn
---
Only compile-tested, because I don't hav
, some filesystems just
cram numbers in there.
Check the type of the supplied file descriptor to be safe, analogous to how
other places in the kernel do it.
Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
Signed-off-by: Jann Horn
---
Only compile-tested, because I don't hav
On Thu, Aug 2, 2018 at 6:33 PM Jann Horn wrote:
>
> fill_with_dentries() failed to propagate errors up to
> reiserfs_for_each_xattr() properly. Plumb them through.
>
> Note that reiserfs_for_each_xattr() is only used by
> reiserfs_delete_xattrs() and reiserfs_chown_xatt
On Thu, Aug 2, 2018 at 6:33 PM Jann Horn wrote:
>
> fill_with_dentries() failed to propagate errors up to
> reiserfs_for_each_xattr() properly. Plumb them through.
>
> Note that reiserfs_for_each_xattr() is only used by
> reiserfs_delete_xattrs() and reiserfs_chown_xatt
On Fri, Jul 6, 2018 at 5:16 PM Jann Horn wrote:
> In general, accessing userspace memory beyond the length of the supplied
> buffer in VFS read/write handlers can lead to both kernel memory corruption
> (via kernel_read()/kernel_write(), which can e.g. be triggered via
>
On Fri, Jul 6, 2018 at 5:16 PM Jann Horn wrote:
> In general, accessing userspace memory beyond the length of the supplied
> buffer in VFS read/write handlers can lead to both kernel memory corruption
> (via kernel_read()/kernel_write(), which can e.g. be triggered via
>
On Mon, Sep 3, 2018 at 3:33 PM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x slower
On Mon, Sep 3, 2018 at 3:33 PM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x slower
Commit-ID: bef459026b161fbc39d20dcba698ed0cfffbac38
Gitweb: https://git.kernel.org/tip/bef459026b161fbc39d20dcba698ed0cfffbac38
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:21 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:10 +0200
lkdtm: Test copy_to_user
Commit-ID: bef459026b161fbc39d20dcba698ed0cfffbac38
Gitweb: https://git.kernel.org/tip/bef459026b161fbc39d20dcba698ed0cfffbac38
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:21 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:10 +0200
lkdtm: Test copy_to_user
Commit-ID: 9da3f2b74054406f87dff7101a569217ffceb29b
Gitweb: https://git.kernel.org/tip/9da3f2b74054406f87dff7101a569217ffceb29b
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:20 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/fault: BUG() when
Commit-ID: 81fd9c18444ed1199b5a6f6776a395292d4256fb
Gitweb: https://git.kernel.org/tip/81fd9c18444ed1199b5a6f6776a395292d4256fb
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:19 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/fault: Plumb error
Commit-ID: 9da3f2b74054406f87dff7101a569217ffceb29b
Gitweb: https://git.kernel.org/tip/9da3f2b74054406f87dff7101a569217ffceb29b
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:20 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/fault: BUG() when
Commit-ID: 81fd9c18444ed1199b5a6f6776a395292d4256fb
Gitweb: https://git.kernel.org/tip/81fd9c18444ed1199b5a6f6776a395292d4256fb
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:19 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/fault: Plumb error
Commit-ID: 75045f77f7a73e617494d7a1fcf4e9c1849cec39
Gitweb: https://git.kernel.org/tip/75045f77f7a73e617494d7a1fcf4e9c1849cec39
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:18 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/extable: Introduce
Commit-ID: 75045f77f7a73e617494d7a1fcf4e9c1849cec39
Gitweb: https://git.kernel.org/tip/75045f77f7a73e617494d7a1fcf4e9c1849cec39
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:18 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:09 +0200
x86/extable: Introduce
Commit-ID: 76dee4a72849561f6ffacc357cfd0aa6081a
Gitweb: https://git.kernel.org/tip/76dee4a72849561f6ffacc357cfd0aa6081a
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:16 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Inline
Commit-ID: e3e4d5019c2dd0f91600f6df377b215a73d506fe
Gitweb: https://git.kernel.org/tip/e3e4d5019c2dd0f91600f6df377b215a73d506fe
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:17 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Stop calling
Commit-ID: 76dee4a72849561f6ffacc357cfd0aa6081a
Gitweb: https://git.kernel.org/tip/76dee4a72849561f6ffacc357cfd0aa6081a
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:16 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Inline
Commit-ID: e3e4d5019c2dd0f91600f6df377b215a73d506fe
Gitweb: https://git.kernel.org/tip/e3e4d5019c2dd0f91600f6df377b215a73d506fe
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:17 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Stop calling
Commit-ID: a980c0ef9f6d8c45445d6ed0f5836bb6941c8c91
Gitweb: https://git.kernel.org/tip/a980c0ef9f6d8c45445d6ed0f5836bb6941c8c91
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:15 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Refactor
Commit-ID: a980c0ef9f6d8c45445d6ed0f5836bb6941c8c91
Gitweb: https://git.kernel.org/tip/a980c0ef9f6d8c45445d6ed0f5836bb6941c8c91
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 22:14:15 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 3 Sep 2018 15:12:08 +0200
x86/kprobes: Refactor
, FS_BASE and KERNEL_GS_BASE
in this case.
This also moves the bitness-specific logic from show_regs() into
process_{32,64}.c.
Signed-off-by: Jann Horn
Fixes: 45807a1df9f5 ("vdso: print fatal signals")
---
@Andy: Does this look like what you had in mind?
Does this need a CC stable tag? I h
, FS_BASE and KERNEL_GS_BASE
in this case.
This also moves the bitness-specific logic from show_regs() into
process_{32,64}.c.
Signed-off-by: Jann Horn
Fixes: 45807a1df9f5 ("vdso: print fatal signals")
---
@Andy: Does this look like what you had in mind?
Does this need a CC stable tag? I h
Commit-ID: 342db04ae71273322f0011384a9ed414df8bdae4
Gitweb: https://git.kernel.org/tip/342db04ae71273322f0011384a9ed414df8bdae4
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 17:49:01 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 31 Aug 2018 17:08:22 +0200
x86/dumpstack: Don't
Commit-ID: 342db04ae71273322f0011384a9ed414df8bdae4
Gitweb: https://git.kernel.org/tip/342db04ae71273322f0011384a9ed414df8bdae4
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 17:49:01 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 31 Aug 2018 17:08:22 +0200
x86/dumpstack: Don't
__chk_range_not_ok directly.
Fixes: a644cf538b11 ("x86/dumpstack: Don't dump kernel memory based on usermode
RIP")
Signed-off-by: Jann Horn
---
arch/x86/kernel/dumpstack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/
__chk_range_not_ok directly.
Fixes: a644cf538b11 ("x86/dumpstack: Don't dump kernel memory based on usermode
RIP")
Signed-off-by: Jann Horn
---
arch/x86/kernel/dumpstack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/
On Fri, Aug 31, 2018 at 10:27 AM Luc Van Oostenryck
wrote:
>
> On Thu, Aug 30, 2018 at 09:47:36PM +0200, Jann Horn wrote:
> > I sloppily passed a kernel-typed pointer to __range_not_ok(), and sparse
> > doesn't like that.
> > Make `prologue` a __user pointer (to pr
On Fri, Aug 31, 2018 at 10:27 AM Luc Van Oostenryck
wrote:
>
> On Thu, Aug 30, 2018 at 09:47:36PM +0200, Jann Horn wrote:
> > I sloppily passed a kernel-typed pointer to __range_not_ok(), and sparse
> > doesn't like that.
> > Make `prologue` a __user pointer (to pr
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel
On Thu, Aug 30, 2018 at 11:01 PM Jann Horn wrote:
>
> On Thu, Aug 30, 2018 at 10:57 PM Yu-cheng Yu wrote:
> >
> > On Thu, 2018-08-30 at 22:44 +0200, Jann Horn wrote:
> > > On Thu, Aug 30, 2018 at 10:25 PM Yu-cheng Yu
> > > wrote:
> > ...
>
On Thu, Aug 30, 2018 at 11:01 PM Jann Horn wrote:
>
> On Thu, Aug 30, 2018 at 10:57 PM Yu-cheng Yu wrote:
> >
> > On Thu, 2018-08-30 at 22:44 +0200, Jann Horn wrote:
> > > On Thu, Aug 30, 2018 at 10:25 PM Yu-cheng Yu
> > > wrote:
> > ...
>
pointer.
Fixes: a644cf538b11 ("x86/dumpstack: Don't dump kernel memory based on usermode
RIP")
Signed-off-by: Jann Horn
---
arch/x86/kernel/dumpstack.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpsta
pointer.
Fixes: a644cf538b11 ("x86/dumpstack: Don't dump kernel memory based on usermode
RIP")
Signed-off-by: Jann Horn
---
arch/x86/kernel/dumpstack.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpsta
Commit-ID: a644cf538b1125410421584c68b2013fdbecbd79
Gitweb: https://git.kernel.org/tip/a644cf538b1125410421584c68b2013fdbecbd79
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 17:49:01 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 13:10:09 +0200
x86/dumpstack: Don't
Commit-ID: a644cf538b1125410421584c68b2013fdbecbd79
Gitweb: https://git.kernel.org/tip/a644cf538b1125410421584c68b2013fdbecbd79
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 17:49:01 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 13:10:09 +0200
x86/dumpstack: Don't
Commit-ID: f12d11c5c184626b4befdee3d573ec8237405a33
Gitweb: https://git.kernel.org/tip/f12d11c5c184626b4befdee3d573ec8237405a33
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 20:40:33 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 11:37:09 +0200
x86/entry/64: Wipe KASAN
Commit-ID: f12d11c5c184626b4befdee3d573ec8237405a33
Gitweb: https://git.kernel.org/tip/f12d11c5c184626b4befdee3d573ec8237405a33
Author: Jann Horn
AuthorDate: Tue, 28 Aug 2018 20:40:33 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 11:37:09 +0200
x86/entry/64: Wipe KASAN
On Wed, Aug 29, 2018 at 9:10 AM 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 Wed, Aug 29, 2018 at 9:10 AM 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
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 +
801 - 900 of 1477 matches
Mail list logo
