array_index_nospec() to prevent speculation past
the end of current->fdt.
Reported-by: Omer Tripp
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Hackmann
---
v2: include Omer Tripp's analysis in commit message, and update my email
address
fs/file.c | 2 ++
1 file changed, 2 inse
__close_fd() is reachable via the close() syscall with a
userspace-controlled fd. Ensure that it can't be used to speculatively
access past the end of current->fdt.
Reported-by: Omer Tripp
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Hackmann
---
fs/file.c | 2 ++
1 file ch
ed on top of 4.4.y, and applies to older kernels
too. 4.9.y was fixed separately. Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.
Cc: sta...@vger.kernel.org # v4.4-
Signed-off-by: Greg Hackmann
---
v2: remove Change-Id line fro
On 08/31/2018 01:27 PM, Greg Hackmann wrote:
> Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738
Sorry, please disregard the Change-Id line. This is what I get for
forgetting to re-run checkpatch after amending my commit message. :/
ed on top of 4.4.y, and applies to older kernels
too. 4.9.y was fixed separately. Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.
Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738
Cc: sta...@vger.kernel.org # v4.4-
Signed-off-b
On 08/31/2018 01:12 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 31, 2018 at 01:06:27PM -0700, Greg Hackmann wrote:
>> The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
>> times while operating on one of the client's ion_handles. This creates
>>
ed on top of 4.9.y. Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.
Cc: sta...@vger.kernel.org # v4.11-
Signed-off-by: Greg Hackmann
---
drivers/staging/android/ion/ion-ioctl.c | 12 ---
drivers/staging/android/ion/
an reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as
valid, and stable_page_flags() will try to access an address between the
user and kernel address ranges.
Fixes: c1cc1552616d ("arm64: MMU initialisation")
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Hackman
vger.kernel.org
Signed-off-by: Greg Hackmann
---
arch/arm/mm/init.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 0cc8e04295a4..bee1f2e4ecf3 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -196,7 +196,11 @@ sta
On 08/14/2018 08:29 AM, Will Deacon wrote:
> On Tue, Aug 14, 2018 at 08:17:48AM -0700, Greg Hackmann wrote:
>> On 08/14/2018 03:40 AM, Will Deacon wrote:
>>> Hi Greg,
>>>
>>> On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
>>>> ARM6
On 08/14/2018 03:40 AM, Will Deacon wrote:
> Hi Greg,
>
> On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
>> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
>> before seeing if the PFN is valid. This leads to false positives when
an reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as
valid, and stable_page_flags() will try to access an address between the
user and kernel address ranges.
Signed-off-by: Greg Hackmann
---
arch/arm64/mm/init.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-
t;Only here for backwards
compatibility".
Since this flag is a no-op on ARM64, we can safely drop it.
Signed-off-by: Greg Hackmann
---
arch/arm64/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 45272266dafb..79bd70
rting the change made the issue go away.
This reverts commit b07c12517f2aed0add8ce18146bb426b14099392.
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Hackmann
---
drivers/usb/host/xhci-plat.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host
uild a kernel with CFI' for arm64?
>>
>> From Google work on Android-4.9
>>
>> https://android.googlesource.com/kernel/common/+/00a195e7c0752ff5d65c9caadfbcc226270ca232
>>
>> I am not sure what is the plan on their side to upstream (Greg?), but
>> definitely
>
91c528cd936f
>>
>> and another by:
>>
>> Greg Hackmann :
>> https://android-review.googlesource.com/c/kernel/common/+/645181
>>
>> If you used either as a reference, you may want to credit them with a
>> `Suggested-by:` in the commit message.
>
&g
fc15c0
R10: R11: 0207 R12: 00400440
R13: 7ffe14fc16b0 R14: R15:
Signed-off-by: Greg Hackmann
---
v2: expand commit log to clarify that kernel 3.15 and later are impacted
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1
On 03/07/2018 12:21 PM, Eric Dumazet wrote:
> On Wed, 2018-03-07 at 11:24 -0800, Greg Hackmann wrote:
>> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added
>> a
>> __this_cpu_read() call inside ipcomp_alloc_tfms(). Since this call
>> was
&g
org
Signed-off-by: Greg Hackmann
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
index ccfdc7115a83..a00ec715aa46 100644
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ sta
ckdep splat [2] during a syzcaller test, this patch fixes
>>> the issue by unlocking the mutex earlier. Functionally that's Ok since
>>> we don't need to protect vfs_llseek.
>>>
>>> [1] https://patchwork.kernel.org/patch/10185031/
>>> [2] https
From: Viktor Slavkovic
A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a
race condition when mmap is called. After the !asma->file check, before
setting asma->size, asma->file can be set in mmap. That would result in
having different asma->size than the mapped memory size. C
ARM64's vDSO exports its gettimeofday() implementation with a different
name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other
architectures. Add a corresponding special-case to vdso_test.
Signed-off-by: Greg Hackmann
---
Changes since v1:
* Moved definitions outside
ARM64's vDSO exports its gettimeofday() implementation with a different
name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other
architectures. Add a corresponding special-case to vdso_test.
Signed-off-by: Greg Hackmann
---
tools/testing/selftests/vDSO/vdso_test.c
On 09/22/2017 07:41 AM, Shuah Khan wrote:
I assume you are good with this fix. I plan to apply it to linux-kselftest fixes
today. Please let me know if you have any objections.
thanks,
-- Shuah
AIUI this check was added so set-timer-lat would treat a missing
CAP_WAKE_ALARM as a skipped test
amp; errno == EINTR);
timer_delete(tm1);
I assume you are good with this fix. I plan to apply it to linux-kselftest fixes
today. Please let me know if you have any objections.
thanks,
-- Shuah
Thanks for looking into this.
Acked-by: Greg Hackmann
On 09/20/2017 04:38 PM, Shuah Khan wrote:
On 09/20/2017 06:31 AM, Prarit Bhargava wrote:
On 09/19/2017 11:36 PM, John Stultz wrote:
On Tue, Sep 19, 2017 at 6:02 PM, Shuah Khan wrote:
Hi Greg,
On 08/20/2017 03:56 AM, tip-bot for Greg Hackmann wrote:
Commit-ID
spam the console with failure messages.
The second patch actually adds the one-shot testcases.
Greg Hackmann (2):
kselftests: set-timer-lat: tweak reporting when timer fires early
kselftests: set-timer-lat: add one-shot timer test cases
tools/testing/selftests/timers/set-timer-lat.c
Rather than printing an error inside the alarm signal handler, set a
flag that we check later. This keeps the test from spamming the console
every time the alarm fires early. It also fixes the test exiting with
error code 0 if this was the only test failure.
Signed-off-by: Greg Hackmann
seconds and verify that the alarm fired exactly once.
Signed-off-by: Greg Hackmann
---
tools/testing/selftests/timers/set-timer-lat.c | 86 ++
1 file changed, 73 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/timers/set-timer-lat.c
b/tools/testing
4.12.y. Older -stable trees have a
slightly different patch, and 4.13-rc2 isn't impacted due to a later
refactoring.
Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals")
Reported-by: Ben Fennema
Signed-off-by: Greg Hackmann
Cc: sta...@vger.kernel.org
---
kernel/ti
On 07/24/2017 11:21 AM, Greg KH wrote:
On Mon, Jul 24, 2017 at 10:19:24AM -0700, Greg Hackmann wrote:
Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a
minimum bound on the alarm timer interval. This minimum bound shouldn't
be applied if the interval i
only needed in -stable trees.
4.13-rc2 isn't impacted due to a later refactoring.
Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals")
Reported-by: Ben Fennema
Signed-off-by: Greg Hackmann
Cc: sta...@vger.kernel.org
---
kernel/time/alarmtimer.c | 3 ++-
1 file change
On 07/10/2017 03:30 AM, Andrey Ryabinin wrote:
gcc now supports this too. So I think this patch should enable it.
It's off by default so you'll have to add --param asan-instrument-allocas=1
into cflags
to make it work
Thanks, will fix. For now, it looks like I'll need to build gcc from
git t
Hi,
Thanks for taking a look at this patchstack. I apologize for the delay
in responding.
On 07/10/2017 01:44 AM, Dmitry Vyukov wrote:
+
+ const void *left_redzone = (const void *)(addr -
+ KASAN_ALLOCA_REDZONE_SIZE);
+ const void *right_redzone = (const voi
On 07/06/2017 03:01 PM, Greg Hackmann wrote:
@@ -101,6 +101,9 @@ static const char *get_shadow_bug_type(struct
kasan_access_info *info)
break;
case KASAN_USE_AFTER_SCOPE:
bug_type = "use-after-scope";
+ case KASAN_ALLOCA_LEFT:
+
For now we can hard-code ASAN ABI level 5, since historical clang builds
can't build the kernel anyway. We also need to emulate gcc's
__SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented.
Signed-off-by: Greg Hackmann
---
include/linux/compiler-clang.h | 10 +++
.
Signed-off-by: Alexander Potapenko
[ghackm...@google.com: fix memset() parameters, and tweak
commit message to describe new callbacks]
Signed-off-by: Greg Hackmann
---
mm/kasan/kasan.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index
f the
dynamic stack area, so unpoisoning is simpler.
Signed-off-by: Greg Hackmann
---
lib/test_kasan.c | 22 ++
mm/kasan/kasan.c | 26 ++
mm/kasan/kasan.h | 8
mm/kasan/report.c | 3 +++
4 files changed, 59 insertions(+)
diff --git
Use cc-option to figure out whether the compiler's sanitizer uses
LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters
("--param asan-foo=bar").
Signed-off-by: Greg Hackmann
---
scripts/Makefile.kasan | 10 +-
1 file changed, 9 insertions(+),
HERE ***
Alexander Potapenko (1):
kasan: added functions for unpoisoning stack variables
Greg Hackmann (3):
kasan: support alloca() poisoning
kasan: support LLVM-style asan parameters
kasan: add compiler support for clang
include/linux/compiler-clang.h | 10 ++
lib/test_ka
On 05/11/2017 06:51 AM, Ard Biesheuvel wrote:
[snip]
In my opinion, the correct fix would be to make -fpie (as opposed to
-fpic) imply hidden visibility, given that PIE executables don't
export symbols in the first place, and so the preemption rules do not
apply. It is worth a try whether -fpie w
On 05/09/2017 12:36 PM, Matthias Kaehlcke wrote:
From: Greg Hackmann
Without any extra guidance, clang will generate libstub with either
absolute or relative ELF relocations. Use the right combination of
-fpic and -fno-pic on different files to avoid this.
Signed-off-by: Greg Hackmann
Signed
On 04/26/2017 02:24 PM, h...@zytor.com wrote:
This really feels like a "fix your compiler" issue.
We already use the other forms, what's so bad about adding mul too?
And if this lets us build under clang, all the better.
-Kees
It's not bad per se, but if this doesn't eventually gets fixed in
On 04/06/2017 10:08 AM, Greg KH wrote:
On Thu, Apr 06, 2017 at 08:30:40AM -0700, Greg Hackmann wrote:
On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote:
From: zhangshuxiao
vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add
On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote:
From: zhangshuxiao
vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.
Signed-off-by: Shuxiao Zhang
Tested-by: Greg Hackmann
---
drivers/staging
Explicit sync was renamed to CONFIG_SYNC_FILE when it was destaged, but
the Android config fragment still tries to use the old name.
Signed-off-by: Greg Hackmann
---
kernel/configs/android-base.config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/configs/android
On 04/26/2016 11:39 PM, Daniel Vetter wrote:
A (per-CRTC?) array of fences would be more flexible. And even in the cases
where you could make a 1-to-1 mapping between planes and fences, it's not
that much more work for userspace to assemble those fences into an array
anyway.
I'm ok with an arr
On 04/26/2016 01:05 PM, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
But really the reason for per-plane is hw composer from
Andro
yet and the only user is Android, but we don't expect anyone trying to
run android userspace and all it dependencies on top of upstream kernels.
Moreover Android should be converted to use upstream sync_files.
Suggested-by: Rob Clark
Signed-off-by: Gustavo Padovan
Acked-by: Greg Hackmann
, because
they don't get direct access to sync fence fds to begin with. Some
privileged system processes do, but they go through libsync, which can
be changed to deal with the ABI differences.
Anyway, for the whole series:
Acked-by: Greg Hackmann
Commit e56d82a11617 ("arm64: cpu hotplug: ensure we mask out
CPU_TASKS_FROZEN in notifiers") fixed a long-standing ARM64 bug that
broke single-stepping after a suspend/resume cycle. Add a kernel
selftest to make sure this doesn't regress or affect other platforms.
Signed-off-by
On 01/28/16 01:23, Daniel Vetter wrote:
And I think driver_data really shouldn't be there, it makes things
complicated with the array of variable-sized objects, and generic
userspace can't really use it - for debug output we already have
obj/driver_name per fence point, which I think is good enou
On 01/27/2016 12:25 PM, Gustavo Padovan wrote:
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
None from me. I'll look where we can improve the ABI.
Android has existing clients of the current ABI. Thankfully they're all
On 11/26/15 12:34 AM, Christoffer Dall wrote:
On Wed, Nov 25, 2015 at 02:24:16PM -0600, Rob Herring wrote:
The binding may be trivial, but there's a bigger question of whether
this is the right long term direction. For example is upstream QEMU
going to take all the Android pipe stuff? Couldn't
On 11/24/2015 12:53 AM, Daniel Vetter wrote:
With all the effort going on around kselftest it'd be good to integrate
the existing testsuite google has into upstream too. Should probably be
listed here too.
-Daniel
The test code's available in AOSP:
https://android.googlesource.com/platform/sys
On 11/23/15 11:41 AM, Gustavo Padovan wrote:
+ - remove sw_sync, it is used only for testing/debugging and should not be
+upstreamed.
+ - port sw_sync testcases to use debugfs somehow
A quick but important nitpick:
sw_sync itself is just an in-kernel helper for creating fences, when you
don't
On 11/17/2015 01:17 PM, Rob Herring wrote:
+- record-size: maximum size in bytes of each dump done on oops/panic
+ (defaults to 0)
Perhaps the default should be something useful.
It's kind of a weird default, but I don't have any ideas for a better one.
First, the size you want is really de
; property, since ramoops
sets dump_oops=1 by default.
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
Signed-off-by: Greg Hackmann
---
Changes in V2:
- make DT binding documentation more generic
Documentation/devicetree/bindings/misc/ramoops.txt | 40 +++
; property, since ramoops
sets dump_oops=1 by default.
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
Signed-off-by: Greg Hackmann
---
Documentation/devicetree/bindings/misc/ramoops.txt | 30 ++
Documentation/ramoops.txt | 6
On Fri, Oct 24, 2014 at 6:56 AM, Mark Rutland wrote:
> [c] Print different hwcaps for compat tasks
>
> This would allow for 32-bit and 64-bit applications to function
> correctly. Having the format differ depending on the instruction set
> of the application reading /proc/cpuinfo may b
Add CLOCK_BOOTTIME support to timerfd
Signed-off-by: Greg Hackmann
---
fs/timerfd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index 9293121..0013142 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -317,6 +317,7 @@ SYSCALL_DEFINE2(timerfd_create, int
61 matches
Mail list logo
