On Sun, Mar 31, 2019 at 6:08 AM Joel Fernandes wrote:
> On Sun, Mar 31, 2019 at 04:34:57AM +0200, Jann Horn wrote:
> > On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes
> > wrote:
> > > As I said I don't really care about "pidfd" solving any racing issues with
&
On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes wrote:
> As I said I don't really care about "pidfd" solving any racing issues with
> /proc//* accesses - because I still find it hard to imagine that the pid
> number can be reused easily from the time you know which to deal with,
> to the time
On Sat, Mar 30, 2019 at 6:24 PM Linus Torvalds
wrote:
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea was that
: 3eb39f47934f ("signal: add pidfd_send_signal() syscall")
Signed-off-by: Jann Horn
---
kernel/signal.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index b7953934aa99..f98448cf2def 100644
--- a/kernel/signal.c
+++ b/kerne
On Fri, Mar 29, 2019 at 4:54 PM Christian Brauner wrote:
> With the addition of pidfd_open() it is possible for users to reference a
> specific thread by doing:
>
> int pidfd = pidfd_open(, 0);
>
> This means we can extend pidfd_send_signal() to signal a specific thread.
> As promised in the
ooks good to me, overall. Apart from a few nits below:
Reviewed-by: Jann Horn
[...]
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 20881598bdfa..8c9e15e0e463 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
[...]
> +static struct file *pidfd_open_proc_pid(const
to complain when a userspace pointer is written into
them. The casts are okay because the pointers always point to
pointer-sized values.
Thanks to Luc Van Oostenryck and Al Viro for explaining this to me.
Signed-off-by: Jann Horn
---
arch/x86/kernel/fpu/signal.c | 6 +++---
arch/x86/kernel/signal.c | 4
as intended.
Reviewed-by: Mukesh Ojha
Signed-off-by: Jann Horn
---
include/linux/kernel.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 34a5036debd3..2d14e21c16c0 100644
--- a/include/linux/kernel.h
+++ b/include/linux
inside the macro, just get rid of __uval and use `(uval)`
directly.
Reviewed-by: Mukesh Ojha
Signed-off-by: Jann Horn
---
arch/x86/include/asm/uaccess.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index
that these address space conversions are intentional.
Signed-off-by: Jann Horn
---
arch/x86/kernel/cpu/microcode/intel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index
+sparse list
On Fri, Mar 29, 2019 at 7:03 PM Luc Van Oostenryck
wrote:
>
> On Fri, Mar 29, 2019 at 05:30:46PM +0100, Jann Horn wrote:
> > In save_xstate_epilog(), use __user when type-casting userspace pointers.
> >
> > In setup_sigcontext() and x32_setup_rt_frame(),
as intended.
Reviewed-by: Mukesh Ojha
Signed-off-by: Jann Horn
---
include/linux/kernel.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 34a5036debd3..2d14e21c16c0 100644
--- a/include/linux/kernel.h
+++ b/include/linux
that these address space conversions are intentional.
Signed-off-by: Jann Horn
---
arch/x86/kernel/cpu/microcode/intel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index
for conversions from userspace pointers to numbers.
Signed-off-by: Jann Horn
---
arch/x86/kernel/fpu/signal.c | 6 +++---
arch/x86/kernel/signal.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index
inside the macro, just get rid of __uval and use `(uval)`
directly.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/uaccess.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 1954dd5552a2..a21f2a2f17bf
On Fri, Mar 29, 2019 at 2:39 PM Borislav Petkov wrote:
>
> On Thu, Mar 28, 2019 at 10:23:21PM +0100, Jann Horn wrote:
> > Fix __user annotations in various places across the x86 tree:
> >
> > - cast to wrong pointer type in __user_atomic_cmpxchg_inatomic()
> > -
On Fri, Mar 29, 2019 at 2:57 PM Borislav Petkov wrote:
>
> > Subject: Re: [PATCH] x86: define LOADED_MM_SWITCHING with pointer-sized
> > number
>
> For the future:
>
> The tip tree preferred format for patch subject prefixes is
> 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:',
Commit-ID: a72a19327b92e09dab0eb9fd2bc83466465cbffb
Gitweb: https://git.kernel.org/tip/a72a19327b92e09dab0eb9fd2bc83466465cbffb
Author: Jann Horn
AuthorDate: Fri, 29 Mar 2019 00:09:39 +0100
Committer: Borislav Petkov
CommitDate: Fri, 29 Mar 2019 14:55:31 +0100
x86/mm/tlb: Define
sparse complains that LOADED_MM_SWITCHING's definition casts an int to a
pointer:
arch/x86/mm/tlb.c:409:17: warning: non size-preserving integer to pointer
cast
Use a pointer-sized integer constant instead.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/tlbflush.h | 2 +-
1 file changed, 1
to unsigned long
- xen_hvm_config() has missing __user
This patch removes all sparse warnings about the asn:1 address space
(__user) in arch/x86/ for my kernel config.
Signed-off-by: Jann Horn
---
This patch requires the previous one, "[PATCH 1/2] kernel.h: use
parentheses around arg
as intended.
Fixes: f09174c501f8 ("x86: add user_atomic_cmpxchg_inatomic at uaccess.h")
Signed-off-by: Jann Horn
---
Can we take this patch through the x86 tree with the following one, or
do we need to get this one through akpm's tree first?
include/linux/kernel.h | 4 ++--
1 file
Commit-ID: f6027c81099e87516d27d123867f10abd04b2d38
Gitweb: https://git.kernel.org/tip/f6027c81099e87516d27d123867f10abd04b2d38
Author: Jann Horn
AuthorDate: Thu, 28 Mar 2019 16:49:48 +0100
Committer: Borislav Petkov
CommitDate: Thu, 28 Mar 2019 17:03:11 +0100
x86/cpufeature: Fix
_info.x86_capability is __percpu, and the second argument of
x86_this_cpu_test_bit() is expected to be __percpu. Don't cast the __percpu
away and then implicitly add it again.
This gets rid of 106 lines of sparse warnings with the kernel config I'm
using.
Signed-off-by: Jann Horn
---
arch/x86
Since we're just talking about RCU stuff now, adding Paul McKenney to
the thread.
On Thu, Mar 28, 2019 at 3:37 PM Joel Fernandes wrote:
> On Thu, Mar 28, 2019 at 03:57:44AM +0100, Jann Horn wrote:
> > On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes
> > wrote:
> > > On Th
On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes wrote:
> On Thu, Mar 28, 2019 at 01:59:45AM +0100, Jann Horn wrote:
> > On Thu, Mar 28, 2019 at 1:06 AM Kees Cook wrote:
> > > On Wed, Mar 27, 2019 at 7:53 AM Joel Fernandes (Google)
> > > wrote:
> > > >
&g
On Thu, Mar 28, 2019 at 1:06 AM Kees Cook wrote:
> On Wed, Mar 27, 2019 at 7:53 AM Joel Fernandes (Google)
> wrote:
> >
> > struct pid's count is an atomic_t field used as a refcount. Use
> > refcount_t for it which is basically atomic_t but does additional
> > checking to prevent use-after-free
to
integer
Fixes: 3d3539018d2c ("mm: create the new vm_fault_t type")
Signed-off-by: Jann Horn
---
include/linux/mm_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 7eade9132f02..4ef4bbe78a1d 100644
--- a/inc
On Wed, Mar 27, 2019 at 5:22 PM Christian Brauner wrote:
> pidfd_open() allows to retrieve pidfds for processes and removes the
> dependency of pidfd on procfs. Multiple people have expressed a desire to
> do this even when pidfd_send_signal() was merged. It is even recorded in
[...]
> IF
issues.
Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings
unless they're accessed")
Signed-off-by: Jann Horn
---
include/linux/sched/user.h | 7 +++
security/keys/process_keys.c | 31 +--
security/keys/request_key.c |
writes are before the creds are committed; therefore,
cred->session_keyring doesn't need RCU protection.
Remove the __rcu annotation and fix up all existing users that use __rcu.
Signed-off-by: Jann Horn
---
include/linux/cred.h | 2 +-
security/keys/process_keys.c | 12
sparse complains that Yama defines functions and a variable as non-static
even though they don't exist in any header. Fix it by making them static.
Signed-off-by: Jann Horn
---
security/yama/yama_lsm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/security/yama
On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes wrote:
> On Mon, Mar 25, 2019 at 09:15:45PM +0100, Christian Brauner wrote:
> > On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> > > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > > > On Mon, Mar 25, 2019 at
On Mon, Mar 25, 2019 at 9:40 PM Jonathan Kowalski wrote:
> On Mon, Mar 25, 2019 at 8:34 PM Jann Horn wrote:
> >
> > [...SNIP...]
> >
> > Please don't do that. /proc/$pid/fd refers to the set of file
> > descriptors the process has open, and semanti
On Mon, Mar 25, 2019 at 9:15 PM Daniel Colascione wrote:
> On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski
> wrote:
> > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione wrote:
[...]
> > Yes, but everything in /proc is not equivalent to an attribute, or an
> > option, and depending on its
On Mon, Mar 25, 2019 at 8:44 PM Andy Lutomirski wrote:
> On Wed, Mar 20, 2019 at 12:40 PM Daniel Colascione wrote:
> > On Wed, Mar 20, 2019 at 12:14 PM Christian Brauner
> > wrote:
> > > On Wed, Mar 20, 2019 at 11:58:57AM -0700, Andy Lutomirski wrote:
> > > > On Wed, Mar 20, 2019 at 11:52 AM
On Mon, Mar 25, 2019 at 5:21 PM Christian Brauner wrote:
> Let pidfd_send_signal() use pidfds retrieved via pidctl(). With this patch
> pidfd_send_signal() becomes independent of procfs. This fullfils the
> request made when we merged the pidfd_send_signal() patchset. The
> pidfd_send_signal()
On Mon, Mar 25, 2019 at 5:21 PM Christian Brauner wrote:
> The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> I quote Konstantins original patchset first that has already been acked and
> picked up by Eric before and whose functionality is preserved in this
> syscall:
ake -s C=2 security/device_cgroup.o
./include/linux/rcupdate.h:647:9: warning: context imbalance in
'propagate_exception' - unexpected unlock
Fixes: d591fb56618f ("device_cgroup: simplify cgroup tree walk in
propagate_exception()")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Commit-ID: ac5ceccce5501e43d217c596e4ee859f2a3fef79
Gitweb: https://git.kernel.org/tip/ac5ceccce5501e43d217c596e4ee859f2a3fef79
Author: Jann Horn
AuthorDate: Fri, 1 Mar 2019 04:12:01 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 6 Mar 2019 23:03:26 +0100
x86/unwind: Add hardcoded
Commit-ID: f4f34e1b82eb4219d8eaa1c7e2e17ca219a6a2b5
Gitweb: https://git.kernel.org/tip/f4f34e1b82eb4219d8eaa1c7e2e17ca219a6a2b5
Author: Jann Horn
AuthorDate: Fri, 1 Mar 2019 04:12:00 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 6 Mar 2019 23:03:26 +0100
x86/unwind: Handle NULL
On Tue, Mar 5, 2019 at 5:22 PM Linus Torvalds
wrote:
> On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov wrote:
> > We can at least deprecate it on x86...
>
> I'd prefer to try to deprecate a.out core dumping first.. That's the
> part that is actually broken, no?
>
> In fact, I'd be happy to
On Fri, Mar 1, 2019 at 9:10 PM Jann Horn wrote:
>
> get_ds() is a legacy name for KERNEL_DS; all architectures #define it to
> KERNEL_DS, and almost every user of set_fs() uses the name KERNEL_DS.
>
> Let the integrity subsystem also use KERNEL_DS so that we can get rid of
>
On Mon, Mar 4, 2019 at 4:16 PM Masami Hiramatsu wrote:
>
> Hello,
>
> On Mon, 4 Mar 2019 18:06:10 +0900
> Masami Hiramatsu wrote:
>
> > On Sun, 3 Mar 2019 18:37:59 -0800
> > Linus Torvalds wrote:
> >
> > > On Sun, Mar 3, 2019 at 5:14 PM Masami Hiramatsu
> > > wrote:
> > > >
> > > > I think it
In theory, Linux can dump cores for a.out binaries. In practice, that
code is pretty bitrotten and buggy. Does anyone want that code so much
that they'd like to fix it, or can we just delete it?
Here's a shell script that will give you a minimal a.out binary that
Linux will execute (and that then
Replace the manual call to f_op->read() under KERNEL_DS with kernel_read().
This also reduces the number of users of the legacy alias get_ds() for
KERNEL_DS.
Signed-off-by: Jann Horn
---
.../staging/rtl8723bs/os_dep/osdep_service.c | 23 ++-
1 file changed, 7 insertions(+),
get_ds() is a legacy name for KERNEL_DS; all architectures #define it to
KERNEL_DS, and almost every user of set_fs() uses the name KERNEL_DS.
Let the integrity subsystem also use KERNEL_DS so that we can get rid of
get_ds() at some point.
Signed-off-by: Jann Horn
---
security/integrity/iint.c
get_ds() is a legacy name for KERNEL_DS; all architectures #define it to
KERNEL_DS, and almost every user of set_fs() uses the name KERNEL_DS.
Let the VFS also use KERNEL_DS so that we can get rid of get_ds() at some
point.
Signed-off-by: Jann Horn
---
fs/read_write.c | 6 +++---
fs/splice.c
On Fri, Mar 1, 2019 at 5:29 PM Josh Poimboeuf wrote:
>
> On Fri, Mar 01, 2019 at 10:24:18AM -0600, Josh Poimboeuf wrote:
> > > Is there a reason why the top-level Makefile only sets
> > > -fno-optimize-sibling-calls if CONFIG_FRAME_POINTER is set?
> > > I suspect that this is just a historical
On Fri, Mar 1, 2019 at 4:33 PM Sean Christopherson
wrote:
> On Fri, Mar 01, 2019 at 04:12:00AM +0100, Jann Horn wrote:
> > When the frame unwinder is invoked for an oops caused by a call to NULL,
> > it currently skips the parent function because BP still points to the
> >
x50
__x64_sys_prctl+0x457/0x6f0
? __ia32_sys_prctl+0x750/0x750
do_syscall_64+0x72/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Jann Horn
---
arch/x86/include/asm/unwind.h | 6 ++
arch/x86/kernel/unwind_frame.c | 25 ++---
2 files changed, 28 inserti
+0x44/0xa9
prctl_set_seccomp() still doesn't show up in the trace because for some
reason, tail call optimization is only disabled in builds that use the
frame pointer unwinder.
Signed-off-by: Jann Horn
---
Is there a reason why the top-level Makefile only sets
-fno-optimize-sibling-calls
On Thu, Feb 28, 2019 at 5:34 PM Jann Horn wrote:
>
> On Thu, Feb 28, 2019 at 1:57 PM Thomas Gleixner wrote:
> > On Thu, 28 Feb 2019, Jann Horn wrote:
> > > +Josh for unwinding, +x86 folks
> > > On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton
> > > wrot
On Thu, Feb 28, 2019 at 1:57 PM Thomas Gleixner wrote:
> On Thu, 28 Feb 2019, Jann Horn wrote:
> > +Josh for unwinding, +x86 folks
> > On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton
> > wrote:
> > > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot
>
+Josh for unwinding, +x86 folks
On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton
wrote:
> On Thu, 21 Feb 2019 06:52:04 -0800 syzbot
> wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct..
> > git
On Fri, Feb 22, 2019 at 11:42 PM wrote:
>
> On Thu, 21 Feb 2019 14:39:27 +0100, Daniel Borkmann said:
> > Fyi, false positive and already fixed in bpf-next.
> >
> > (https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=435b3ff5b08a99a15647be32735abf8db66cea9a)
>
> Is there
On Fri, Feb 22, 2019 at 11:51 PM Alexei Starovoitov
wrote:
>
> On Fri, Feb 22, 2019 at 01:59:10PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 22, 2019 at 1:38 PM David Miller wrote:
> > >
> > > Don't be surprised if we see more separation like this in the future too.
> >
> > Yes, with the whole
On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
> > On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
> >
> >> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
> >>
> >> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> >>>> On Feb 22, 201
On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> > On Feb 22, 2019, at 1:43 PM, Jann Horn wrote:
> >
> > (adding some people from the text_poke series to the thread, removing
> > stable@)
> >
> > On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski wrote
(adding some people from the text_poke series to the thread, removing stable@)
On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski wrote:
> > On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov
> > wrote:
> >> On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
> >> On Fri, 22 Feb 2019
The listed address for the CAIF maintainer bounces with
"553 5.3.0 ... No such user here", and the
only existing email address of the maintainer in git history hasn't
responded in a week.
Therefore, remove the listed maintainer and mark CAIF as orphan.
Signed-off-by: Jann Horn
---
M
On Thu, Feb 21, 2019 at 7:02 AM Kees Cook wrote:
> On Wed, Feb 20, 2019 at 9:25 PM Tobin C. Harding wrote:
> >
> > On Wed, Feb 20, 2019 at 05:05:10PM -0800, Kees Cook wrote:
> > > So, generally speaking, I'd love to split all strncpy* uses into
> > > strscpy_zero() (when expecting to do str->str
On Thu, Feb 21, 2019 at 2:05 AM Kees Cook wrote:
> On Mon, Feb 18, 2019 at 4:52 PM Jann Horn wrote:
> > AFAICS the byte_at_a_time loop exits when max==0 is reached, and then
> > if `res >= count` (in other words, if we've copied as many bytes as
> > requested, haven't en
__sys_setsockopt() already checks for `optlen < 0`. Add an equivalent check
to the compat path for robustness. This has to be `> INT_MAX` instead of
`< 0` because the signedness of `optlen` is different here.
Signed-off-by: Jann Horn
---
net/compat.c | 6 +-
1 file changed, 5 i
: Fix perf_uprobe_init()")
Signed-off-by: Jann Horn
---
v2:
- be compatible with existing error codes (Masami Hiramatsu)
kernel/trace/trace_event_perf.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace_event_perf.c b/ke
On Tue, Feb 19, 2019 at 3:51 PM Masami Hiramatsu wrote:
> On Tue, 19 Feb 2019 20:45:02 +0900
> Masami Hiramatsu wrote:
>
> > On Mon, 18 Feb 2019 23:07:23 +0100
> > Jann Horn wrote:
> >
> > > The first version of this method was missing the check for
> &
On Wed, Feb 20, 2019 at 9:10 AM Masami Hiramatsu wrote:
> On Tue, 19 Feb 2019 14:03:30 -0500
> Steven Rostedt wrote:
>
> > > > Basically, a kprobe is mostly used for debugging what's happening in a
> > > > live kernel, to read any address.
> > >
> > > My point is that "any address" is not
On Wed, Feb 20, 2019 at 1:55 AM Kees Cook wrote:
> Several recent exploits have used direct calls to the native_write_cr4()
> function to disable SMEP and SMAP before then continuing their exploits
> using userspace memory access. This pins bits of cr4 so that they cannot
> be changed through a
On Tue, Feb 19, 2019 at 12:25 AM Tobin C. Harding wrote:
> Currently we have strncpy_from_userspace(). If the user string is
> longer than the destination kernel buffer we get an error code -EFAULT.
> We are unable to recover from here because this is the same error
> returned if the access to
On Tue, Feb 19, 2019 at 12:25 AM Tobin C. Harding wrote:
> Currently we have strncpy_from_userspace(). If the user string is
> longer than the destination kernel buffer we get an error code -EFAULT.
No, see the other thread. If the user string is too long,
strncpy_from_userspace() fills the
+cc Andy because he's also preparing a patch for this function
On Tue, Feb 19, 2019 at 12:25 AM Tobin C. Harding wrote:
> Current function documentation for strncpy_from_user() is incorrect. If
> @count (size of destination buffer) is less than the length of the user
> string the function does
: Fix perf_uprobe_init()")
Signed-off-by: Jann Horn
---
compile-tested only
kernel/trace/trace_event_perf.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index 76217bbef815..c744b0208
.
Just use memdup_user_nul(), which is designed precisely for things like
this.
Signed-off-by: Jann Horn
---
WARNING: completely untested patch
drivers/firmware/xilinx/zynqmp-debug.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/xilinx/zynqmp
On Mon, Feb 18, 2019 at 8:15 PM Andy Lutomirski wrote:
> On Mon, Feb 18, 2019 at 5:04 AM Thomas Gleixner wrote:
> > > Another would be to have the buffer passed to flush_buffer() (i.e.
> > > the callback of decompress_fn) allocated with 4 bytes of padding
> > > past the part where the unpacked
| cpio -o --format=newc | lz4 -l > initrd.img.lz4
>
> This places the second filename in the cpio near the allocation boundary made
> by lz4 decompression and should trigger the bug.
>
> Fixes: 9da3f2b74054 ("x86/fault: BUG() when uaccess helpers fault on kernel
> addresses&qu
On Fri, Feb 15, 2019 at 7:35 PM Alexander Duyck
wrote:
> On Fri, Feb 15, 2019 at 6:10 AM Jann Horn wrote:
> > On Thu, Feb 14, 2019 at 11:21 PM David Miller wrote:
> > > From: Jann Horn
> > > Date: Thu, 14 Feb 2019 22:26:22 +0100
> > >
> > > &
Replace an open-coded version of skb_put_zero() with a call to the helper.
This is a cleanup and is also useful for potentially adding KASAN
integration to SKBs in the future.
Signed-off-by: Jann Horn
---
drivers/staging/unisys/visornic/visornic_main.c | 4 +---
1 file changed, 1 insertion
On Fri, Feb 15, 2019 at 6:13 PM Dmitry Vyukov wrote:
> On Fri, Feb 15, 2019 at 6:10 PM Jann Horn wrote:
> > On Fri, Feb 15, 2019 at 5:45 PM Dmitry Vyukov wrote:
> > > On Fri, Feb 15, 2019 at 5:03 PM Jann Horn wrote:
> > > > On Fri, Feb 15, 2019 at 4:40 PM
On Fri, Feb 15, 2019 at 5:45 PM Dmitry Vyukov wrote:
>
> On Fri, Feb 15, 2019 at 5:03 PM Jann Horn wrote:
> >
> > On Fri, Feb 15, 2019 at 4:40 PM Dmitry Vyukov wrote:
> > > On Thu, Oct 11, 2018 at 4:18 PM Paolo Bonzini wrote:
> > > > On 10/10/2018 09:58,
On Fri, Feb 15, 2019 at 4:40 PM Dmitry Vyukov wrote:
> On Thu, Oct 11, 2018 at 4:18 PM Paolo Bonzini wrote:
> > On 10/10/2018 09:58, syzbot wrote:
> > > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> > > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
> > > RIP:
On Thu, Feb 14, 2019 at 11:21 PM David Miller wrote:
>
> From: Jann Horn
> Date: Thu, 14 Feb 2019 22:26:22 +0100
>
> > On Thu, Feb 14, 2019 at 6:13 PM David Miller wrote:
> >>
> >> From: Jann Horn
> >> Date: Wed, 13 Feb 2019 22:45:59 +0100
>
subsystem as orphan.
Signed-off-by: Jann Horn
---
There's a second email address for Nelson Castillo in git history. I'm
CC-ing that address in case the maintainer merely forgot to update his
MAINTAINERS entry.
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -
On Thu, Feb 14, 2019 at 6:13 PM David Miller wrote:
>
> From: Jann Horn
> Date: Wed, 13 Feb 2019 22:45:59 +0100
>
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath lat
(page_ref_count(page) == 0)` in the
`offset < 0` path, below the virt_to_page() call, and then repeatedly call
writev() on a TAP device with IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Signed-off-by: Jann Horn
---
sending to davem as
On Wed, Feb 13, 2019 at 11:42 PM Alexander Duyck
wrote:
> On Wed, Feb 13, 2019 at 12:42 PM Jann Horn wrote:
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath later,
> > the
F_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Signed-off-by: Jann Horn
---
Resending to davem at the request of akpm.
mm/page_alloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
ind
On Wed, Feb 13, 2019 at 9:59 PM Andrew Morton wrote:
>
> On Wed, 13 Feb 2019 21:41:57 +0100 Jann Horn wrote:
>
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath later,
> >
F_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
mm/page_alloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 35fdde041f5
On Thu, Feb 7, 2019 at 10:22 AM Christophe Leroy
wrote:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a
On Wed, Nov 21, 2018 at 8:59 PM Jann Horn wrote:
> commit 380cf5ba6b0a ("fs: Treat foreign mounts as nosuid"), in addition to
> the intended effect, also prevented suid execution of memfd files.
> (And I think that's a good change.)
Ping. Al, can you take this into your t
On Fri, Feb 1, 2019 at 3:45 PM Greg Kroah-Hartman
wrote:
> On Fri, Feb 01, 2019 at 03:08:52PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 01, 2019 at 03:00:18PM +0100, Jann Horn wrote:
> > > On Tue, Jan 29, 2019 at 12:47 PM Greg Kroah-Hartman
> > > wrote:
>
On Tue, Jan 29, 2019 at 12:47 PM Greg Kroah-Hartman
wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> [ commit 979d63d50c0c0f7bc537bf821e056cc9fe5abd38 upstream ]
>
> Jann reported that the original commit back in b2157399cc98
>
On Wed, Jan 30, 2019 at 7:22 PM Will Deacon wrote:
> On Wed, Jan 30, 2019 at 05:32:00PM +0100, Jann Horn wrote:
> > At the moment, compat tasks running on ARM64 can allocate memory up to
> > 0x1 (TASK_SIZE_32). Testing on an Android device (with an
> > admittedl
Hi!
At the moment, compat tasks running on ARM64 can allocate memory up to
0x1 (TASK_SIZE_32). Testing on an Android device (with an
admittedly somewhat old kernel):
===
$ cat mmap_filler.c
#include
#include
#include
#include
#include
int main(void) {
unsigned long size =
On Mon, Jan 28, 2019 at 11:39 PM Paul E. McKenney wrote:
> On Mon, Jan 28, 2019 at 05:07:07PM -0500, Mathieu Desnoyers wrote:
> > Jann Horn identified a racy access to p->mm in the global expedited
> > command of the membarrier system call.
> >
> > The suggeste
On Mon, Jan 28, 2019 at 7:27 PM Mathieu Desnoyers
wrote:
> Jann Horn identified a racy access to p->mm in the global expedited
> command of the membarrier system call.
>
> The suggested fix is to hold the task_lock() around the accesses to
> p->mm and to the mm_struct m
membarrier_global_expedited() runs the following code (introduced in
commit c5f58bd58f43), protected only by an RCU read-side critical
section and the cpu_hotplug_lock:
p = task_rcu_dereference(_rq(cpu)->curr);
if (p && p->mm && (atomic_read(>mm->membarrier_state) &
On Mon, Jan 21, 2019 at 11:24 PM Dave Chinner wrote:
> On Mon, Jan 21, 2019 at 04:49:45PM +0100, Jann Horn wrote:
> > On Sun, Jan 20, 2019 at 11:41 PM Dave Chinner wrote:
> > > On Fri, Jan 18, 2019 at 05:14:40PM +0100, Jann Horn wrote:
> > > > As Al Viro pointed
Al Viro pointed out that since there is only one pipe buffer type to which
new data can be appended, it isn't necessary to have a ->can_merge field in
struct pipe_buf_operations, we can just check for a magic type.
Suggested-by: Al Viro
Signed-off-by: Jann Horn
---
fs/pip
d link_pipe().
Cc:
Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
Suggested-by: Al Viro
Signed-off-by: Jann Horn
---
Al wasn't entirely happy with the approach I took for v1, so sending a
different
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
501 - 600 of 1477 matches
Mail list logo
