Re: [PATCH 2/2] kcov: make kcov work properly with KASLR enabled

On Mon, Dec 12, 2016 at 07:58:03AM +0100, Dmitry Vyukov wrote: > On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov > wrote: > > On 11.12.2016 12:32, Dmitry Vyukov wrote: > >> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov > >> wrote: > >>> Subtract

Re: [PATCH 2/2] kcov: make kcov work properly with KASLR enabled

On Mon, Dec 12, 2016 at 07:58:03AM +0100, Dmitry Vyukov wrote: > On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov > wrote: > > On 11.12.2016 12:32, Dmitry Vyukov wrote: > >> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov > >> wrote: > >>> Subtract KASLR offset from the kernel addresses

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Tue, Nov 29, 2016 at 10:32:29AM +0100, Miklos Szeredi wrote: > On Mon, Nov 28, 2016 at 12:06:09PM +0100, Quentin Casasnovas wrote: > > > > > > But it looks like it was re-introduced in: > > > > > > > > > > 2d902671ce1c ("vfs: merge .

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Tue, Nov 29, 2016 at 10:32:29AM +0100, Miklos Szeredi wrote: > On Mon, Nov 28, 2016 at 12:06:09PM +0100, Quentin Casasnovas wrote: > > > > > > But it looks like it was re-introduced in: > > > > > > > > > > 2d902671ce1c ("vfs: merge .

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Mon, Nov 28, 2016 at 10:45:18AM +0100, Miklos Szeredi wrote: > On Fri, Nov 25, 2016 at 08:28:47PM +0100, Quentin Casasnovas wrote: > > On Fri, Nov 25, 2016 at 06:09:23PM +0100, Quentin Casasnovas wrote: > > > If two overlayfs filesystems are stacked on top of each other, t

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Mon, Nov 28, 2016 at 10:45:18AM +0100, Miklos Szeredi wrote: > On Fri, Nov 25, 2016 at 08:28:47PM +0100, Quentin Casasnovas wrote: > > On Fri, Nov 25, 2016 at 06:09:23PM +0100, Quentin Casasnovas wrote: > > > If two overlayfs filesystems are stacked on top of each other, t

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Fri, Nov 25, 2016 at 06:09:23PM +0100, Quentin Casasnovas wrote: > If two overlayfs filesystems are stacked on top of each other, then we need > to recurse when opening a file. This used to work and was first broken by: > > 4bacc9c9234c ("overlayfs: Make f_path always poi

Re: [PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

On Fri, Nov 25, 2016 at 06:09:23PM +0100, Quentin Casasnovas wrote: > If two overlayfs filesystems are stacked on top of each other, then we need > to recurse when opening a file. This used to work and was first broken by: > > 4bacc9c9234c ("overlayfs: Make f_path always poi

[PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

ut this patch it returned zero so I am assuming it does not contain any tests with stacked overlayfs. Fixes: 2d902671ce1c ("vfs: merge .d_select_inode() into .d_real()") Cc: Al Viro <v...@zeniv.linux.org.uk> Cc: Miklos Szeredi <mik...@szeredi.hu> Signed-off-by: Quentin Casas

[PATCH] ovl: tentative fix for broken vfs_open() on stacked overlayfs.

ut this patch it returned zero so I am assuming it does not contain any tests with stacked overlayfs. Fixes: 2d902671ce1c ("vfs: merge .d_select_inode() into .d_real()") Cc: Al Viro Cc: Miklos Szeredi Signed-off-by: Quentin Casasnovas --- fs/overlayfs/super.c | 12 +--- 1

opening a file on a stacked overlayfs is broken.

Hi, Stacking an overlayfs on top of an overlayfs doens't work when it used to (tested on v4.9-rc5): #!/bin/bash -xeu tmpdir=$(mktemp -d) pushd ${tmpdir} mkdir -p {upper,lower,work} echo 'foo' > lower/bar mount -t overlay level_zero upper -o

opening a file on a stacked overlayfs is broken.

Hi, Stacking an overlayfs on top of an overlayfs doens't work when it used to (tested on v4.9-rc5): #!/bin/bash -xeu tmpdir=$(mktemp -d) pushd ${tmpdir} mkdir -p {upper,lower,work} echo 'foo' > lower/bar mount -t overlay level_zero upper -o

[PATCH 2/2] kcov: add AFL-style tracing

printf("%02x ", mem2[i]); if (i % 32 == 31) printf("\n"); } close(fd); return 0; } This patch is a collaboration between Quentin Casasnovas and Vegard Nossum. v2

[PATCH 1/2] kcov: size of arena is now given in bytes.

field expressed in unsigned long in order to save an unecessary bitshift/division in the hot path when using KCOV_MODE_TRACE. Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Michal Zalewski <lcam...@gmail.com> Cc: Kees Cook <keesc...@chromium.org> Signed-off-by: Quentin Casasnova

[PATCH 2/2] kcov: add AFL-style tracing

printf("%02x ", mem2[i]); if (i % 32 == 31) printf("\n"); } close(fd); return 0; } This patch is a collaboration between Quentin Casasnovas and Vegard Nossum. v2

[PATCH 1/2] kcov: size of arena is now given in bytes.

field expressed in unsigned long in order to save an unecessary bitshift/division in the hot path when using KCOV_MODE_TRACE. Cc: Dmitry Vyukov Cc: Michal Zalewski Cc: Kees Cook Signed-off-by: Quentin Casasnovas Signed-off-by: Vegard Nossum --- kernel/kcov.c | 10 -- 1 file changed, 4

[PATCH v2 0/2] kcov: add AFL-style tracing

Hi Dmitry, Sorry it took so long to implement the small suggestions you had, we've been very busy with other projects (or at least that's our excuse!). The changes to afl.git in order to use kcov were sent to Michal so hopefully people can start fuzzing their kernel with AFL without

[PATCH v2 0/2] kcov: add AFL-style tracing

Hi Dmitry, Sorry it took so long to implement the small suggestions you had, we've been very busy with other projects (or at least that's our excuse!). The changes to afl.git in order to use kcov were sent to Michal so hopefully people can start fuzzing their kernel with AFL without

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote: > On 24/06/2016 15:04, Quentin Casasnovas wrote: > > On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 18/06/2016 11:01, Quentin Casasnovas wrote: > >>>

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote: > On 24/06/2016 15:04, Quentin Casasnovas wrote: > > On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 18/06/2016 11:01, Quentin Casasnovas wrote: > >>>

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: > > > On 18/06/2016 11:01, Quentin Casasnovas wrote: > > Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software > > Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine

Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote: > > > On 18/06/2016 11:01, Quentin Casasnovas wrote: > > Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software > > Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine

[PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

or #GP/#SS exceptions") Signed-off-by: Quentin Casasnovas <quentin.casasno...@oracle.com> Cc: Eugene Korenevsky <ekorenev...@gmail.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ing

[PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

or #GP/#SS exceptions") Signed-off-by: Quentin Casasnovas Cc: Eugene Korenevsky Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: linux-stable --- arch/x86/kvm/vmx.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-

Re: [RFC 1/2] [RFC] mm: Account anon mappings as RLIMIT_DATA

On Mon, Dec 14, 2015 at 06:11:16PM +0300, Cyrill Gorcunov wrote: > On Mon, Dec 14, 2015 at 03:51:26PM +0100, Quentin Casasnovas wrote: > ... > > > > Do we want to fold may_expand_anon_vm() into may_expand_vm() (potentially > > passing it the flags/struct file if need

Re: [RFC 1/2] [RFC] mm: Account anon mappings as RLIMIT_DATA

expand_anon_vm helper > - call for RLIMIT_DATA test in mremap and do_brk > > CC: Quentin Casasnovas > CC: Vegard Nossum > CC: Linus Torvalds > CC: Willy Tarreau > CC: Andy Lutomirski > CC: Kees Cook > CC: Vladimir Davydov > CC: Konstantin Kh

Re: [RFC 1/2] [RFC] mm: Account anon mappings as RLIMIT_DATA

On Mon, Dec 14, 2015 at 06:11:16PM +0300, Cyrill Gorcunov wrote: > On Mon, Dec 14, 2015 at 03:51:26PM +0100, Quentin Casasnovas wrote: > ... > > > > Do we want to fold may_expand_anon_vm() into may_expand_vm() (potentially > > passing it the flags/struct file if need

Re: [RFC 1/2] [RFC] mm: Account anon mappings as RLIMIT_DATA

expand_anon_vm helper > - call for RLIMIT_DATA test in mremap and do_brk > > CC: Quentin Casasnovas <quentin.casasno...@oracle.com> > CC: Vegard Nossum <vegard.nos...@oracle.com> > CC: Linus Torvalds <torva...@linux-foundation.org> > CC: Willy Tarreau <w...

[PATCH] isofs: memory leaks when reading corrupted filesystems.

. Cc: Cc: Jan Kara Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading...") Signed-off-by: Quentin Casasnovas Signed-off-by: Vegard Nossum Tested-by: Vegard Nossum --- fs/isofs/dir.c | 1 + fs/isofs/namei.c | 1 + 2 files changed, 2 insertions(+) diff --git a

[PATCH] isofs: memory leaks when reading corrupted filesystems.

Cc: <sta...@vger.kernel.org> Cc: Jan Kara <j...@suse.cz> Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading...") Signed-off-by: Quentin Casasnovas <quentin.casasno...@oracle.com> Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> Tested

Re: [Resend PATCH] RDS: fix race condition when sending a message on unbound socket

On Wed, Nov 25, 2015 at 12:21:45PM +, David Laight wrote: > From: Santosh Shilimkar > > Sent: 24 November 2015 22:13 > ... > > Sasha's found a NULL pointer dereference in the RDS connection code when > > sending a message to an apparently unbound socket. The problem is caused > > by the code

Re: [Resend PATCH] RDS: fix race condition when sending a message on unbound socket

On Wed, Nov 25, 2015 at 12:21:45PM +, David Laight wrote: > From: Santosh Shilimkar > > Sent: 24 November 2015 22:13 > ... > > Sasha's found a NULL pointer dereference in the RDS connection code when > > sending a message to an apparently unbound socket. The problem is caused > > by the code

Re: [PATCH] RDS: fix race condition when sending a message on unbound socket.

On Fri, Oct 16, 2015 at 10:47:49AM -0700, santosh shilimkar wrote: > On 10/16/2015 8:11 AM, Quentin Casasnovas wrote: > > Sasha's found a NULL pointer dereference in the RDS connection code when > > sending a message to an apparently unbound socket. The problem is caused > >

Re: [PATCH] RDS: fix race condition when sending a message on unbound socket.

On Fri, Oct 16, 2015 at 10:47:49AM -0700, santosh shilimkar wrote: > On 10/16/2015 8:11 AM, Quentin Casasnovas wrote: > > Sasha's found a NULL pointer dereference in the RDS connection code when > > sending a message to an apparently unbound socket. The problem is caused > >

[PATCH] RDS: fix race condition when sending a message on unbound socket.

the NULL pointer dereference using Vegard's reproducer with this patch, whereas I could without. Complete earlier incomplete fix to CVE-2015-6937: 74e98eb08588 ("RDS: verify the underlying transport exists before creating a connection") Signed-off-by: Quentin Casasnovas Reviewed-

[PATCH] RDS: fix race condition when sending a message on unbound socket.

the NULL pointer dereference using Vegard's reproducer with this patch, whereas I could without. Complete earlier incomplete fix to CVE-2015-6937: 74e98eb08588 ("RDS: verify the underlying transport exists before creating a connection") Signed-off-by: Quentin Casasnovas <qu

Re: [PATCH v2] cdc-acm: prevent infinite loop when parsing CDC headers.

On Tue, Apr 14, 2015 at 11:25:43AM +0200, Quentin Casasnovas wrote: > Phil and I found out a problem with commit: > > 7e860a6e7aa6 ("cdc-acm: add sanity checks") > Any comment on v2? Thanks, Quentin -- To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH v2] cdc-acm: prevent infinite loop when parsing CDC headers.

On Tue, Apr 14, 2015 at 11:25:43AM +0200, Quentin Casasnovas wrote: Phil and I found out a problem with commit: 7e860a6e7aa6 (cdc-acm: add sanity checks) Any comment on v2? Thanks, Quentin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Fri, Apr 17, 2015 at 10:52:43PM -0700, Guenter Roeck wrote: > Hi Quentin, Hi Guenter, > > it looks like there is another failure in linux-next, this time with > sparc64:allmodconfig: > > WARNING: arch/sparc/kernel/built-in.o(__ex_table+0x3b4): Section mismatch in > reference from the

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Fri, Apr 17, 2015 at 10:52:43PM -0700, Guenter Roeck wrote: Hi Quentin, Hi Guenter, it looks like there is another failure in linux-next, this time with sparc64:allmodconfig: WARNING: arch/sparc/kernel/built-in.o(__ex_table+0x3b4): Section mismatch in reference from the (unknown

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Thu, Apr 16, 2015 at 05:47:08AM -0700, Guenter Roeck wrote: > On 04/16/2015 01:21 AM, Quentin Casasnovas wrote: > > On Wed, Apr 15, 2015 at 06:43:11PM -0700, Guenter Roeck wrote: > >> Let me know if you can find a score toolchain - otherwise I'll make a copy > >> o

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:43:11PM -0700, Guenter Roeck wrote: > > For > > >From 2e9abac9cbde18af48951c54d52c9c515f9883a7 Mon Sep 17 00:00:00 2001 > From: Quentin Casasnovas > Date: Wed, 15 Apr 2015 22:39:50 +0200 > Subject: [PATCH] modpost: do not try to match the SHT_

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:43:11PM -0700, Guenter Roeck wrote: For From 2e9abac9cbde18af48951c54d52c9c515f9883a7 Mon Sep 17 00:00:00 2001 From: Quentin Casasnovas quentin.casasno...@oracle.com Date: Wed, 15 Apr 2015 22:39:50 +0200 Subject: [PATCH] modpost: do not try to match the SHT_NUL

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Thu, Apr 16, 2015 at 05:47:08AM -0700, Guenter Roeck wrote: On 04/16/2015 01:21 AM, Quentin Casasnovas wrote: On Wed, Apr 15, 2015 at 06:43:11PM -0700, Guenter Roeck wrote: Let me know if you can find a score toolchain - otherwise I'll make a copy of mine available. I could not find

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:26:58AM -0700, Guenter Roeck wrote: > On 04/15/2015 01:54 AM, Quentin Casasnovas wrote: > > The following two patches might (hopefully) fix the build breakage on score > > and some other architectures. I've checked the new __ex_table checker > >

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 08:31:50AM -0700, Guenter Roeck wrote: > On Wed, Apr 15, 2015 at 03:46:37PM +0200, Quentin Casasnovas wrote: > > > > > > While I agree that those should get fixed (if they are real problems, > > > especially the ones for pari

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:26:58AM -0700, Guenter Roeck wrote: > On 04/15/2015 01:54 AM, Quentin Casasnovas wrote: > > > > Let me know if this makes things better.. > > Hi Guenter, > > the crash is fixed, but now I get > That's a first step.. :) > FATAL:

[PATCH 2/2] modpost: fix extable entry size calculation.

the problem by moving that check in the caller (since we can deal with different types of relocations) and add is_second_extable_reloc() to make the whole thing more readable. Signed-off-by: Quentin Casasnovas Reported-by: Guenter Roeck CC: Rusty Russell --- scripts/mod/modpost.c | 16

[PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

The following two patches might (hopefully) fix the build breakage on score and some other architectures. I've checked the new __ex_table checker still works on x86-64 with them (it still detects an entry pointing to .altinstr_rplacement) and they should apply cleanly on top of Rusty's

[PATCH 1/2] modpost: fix inverted logic in is_extable_fault_address().

. This was leading to a divide-by-zero on some architectures and make the build fail. Signed-off-by: Quentin Casasnovas Reported-by: Guenter Roeck CC: Rusty Russell --- scripts/mod/modpost.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/scripts/mod/modpost.c b/scripts/mod

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

tries. Unfortunately, it > wasn't tested with -ffunction-sections, which some architectures > use. > > Reported-by: kbuild test robot > Cc: Quentin Casasnovas > Signed-off-by: Rusty Russell > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index cbd53

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:26:58AM -0700, Guenter Roeck wrote: On 04/15/2015 01:54 AM, Quentin Casasnovas wrote: Let me know if this makes things better.. Hi Guenter, the crash is fixed, but now I get That's a first step.. :) FATAL: The relocation at __ex_table+0x4 references

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 08:31:50AM -0700, Guenter Roeck wrote: On Wed, Apr 15, 2015 at 03:46:37PM +0200, Quentin Casasnovas wrote: While I agree that those should get fixed (if they are real problems, especially the ones for parisc and mn10300), I don't think it is a good idea

Re: [PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

On Wed, Apr 15, 2015 at 06:26:58AM -0700, Guenter Roeck wrote: On 04/15/2015 01:54 AM, Quentin Casasnovas wrote: The following two patches might (hopefully) fix the build breakage on score and some other architectures. I've checked the new __ex_table checker still works on x86-64 with them

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

, it wasn't tested with -ffunction-sections, which some architectures use. Reported-by: kbuild test robot fengguang...@intel.com Cc: Quentin Casasnovas quentin.casasno...@oracle.com Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index

[PATCH 2/2] modpost: fix extable entry size calculation.

the problem by moving that check in the caller (since we can deal with different types of relocations) and add is_second_extable_reloc() to make the whole thing more readable. Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com Reported-by: Guenter Roeck li...@roeck-us.net CC: Rusty

[PATCH 0/2] Tentative fix for the divide-by-zero on score/paris/..

The following two patches might (hopefully) fix the build breakage on score and some other architectures. I've checked the new __ex_table checker still works on x86-64 with them (it still detects an entry pointing to .altinstr_rplacement) and they should apply cleanly on top of Rusty's

[PATCH 1/2] modpost: fix inverted logic in is_extable_fault_address().

. This was leading to a divide-by-zero on some architectures and make the build fail. Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com Reported-by: Guenter Roeck li...@roeck-us.net CC: Rusty Russell ru...@rustcorp.com.au --- scripts/mod/modpost.c | 7 ++- 1 file changed, 6 insertions

Re: linux-next: Tree for Apr 14 (crash due to modpost patch)

On Tue, Apr 14, 2015 at 09:11:14AM -0700, Guenter Roeck wrote: > On Tue, Apr 14, 2015 at 06:42:44PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Please do not add any v4.2 material to your linux-next included trees > > until after v4.1-rc1 is released. > > > > Changes since 20150413: > >

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

On Tue, Apr 14, 2015 at 02:14:14PM +0200, Thierry Reding wrote: > On Tue, Mar 17, 2015 at 01:40:02PM +0100, Quentin Casasnovas wrote: > > If one of these addresses point to a non-executable section, something is > > seriously wrong since it either means the kernel will n

[PATCH v2] cdc-acm: prevent infinite loop when parsing CDC headers.

hil Turnbull Signed-off-by: Quentin Casasnovas CC: Sergei Shtylyov CC: Oliver Neukum CC: Adam Lee CC: --- drivers/usb/class/cdc-acm.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index 6836177..220c0fd 1006

[PATCH v2] cdc-acm: prevent infinite loop when parsing CDC headers.

...@oracle.com Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com CC: Sergei Shtylyov sergei.shtyl...@cogentembedded.com CC: Oliver Neukum oneu...@suse.de CC: Adam Lee adam8...@gmail.com CC: sta...@vger.kernel.org --- drivers/usb/class/cdc-acm.c | 7 ++- 1 file changed, 6 insertions

Re: linux-next: Tree for Apr 14 (crash due to modpost patch)

On Tue, Apr 14, 2015 at 09:11:14AM -0700, Guenter Roeck wrote: On Tue, Apr 14, 2015 at 06:42:44PM +1000, Stephen Rothwell wrote: Hi all, Please do not add any v4.2 material to your linux-next included trees until after v4.1-rc1 is released. Changes since 20150413: Dropped tree:

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

On Tue, Apr 14, 2015 at 02:14:14PM +0200, Thierry Reding wrote: On Tue, Mar 17, 2015 at 01:40:02PM +0100, Quentin Casasnovas wrote: If one of these addresses point to a non-executable section, something is seriously wrong since it either means the kernel will never fault from

Re: [PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

On Mon, Apr 13, 2015 at 11:48:27PM +0800, Adam Lee wrote: > On Mon, Apr 13, 2015 at 05:24:04PM +0200, Quentin Casasnovas wrote: > > Phil and I found out a problem with commit: > > > > 7e860a6e ("cdc-acm: add sanity checks") > > > > It added some sanit

Re: [PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

Adding Greg on CC as suggested by Oliver. On Mon, Apr 13, 2015 at 05:24:04PM +0200, Quentin Casasnovas wrote: > Phil and I found out a problem with commit: > > 7e860a6e ("cdc-acm: add sanity checks") > > It added some sanity checks to ignore potential garbage

[PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

ld be used to trigger this infinite loop. Fixes: 7e860a6e ("cdc-acm: add sanity checks") Signed-off-by: Phil Turnbull Signed-off-by: Quentin Casasnovas CC: Oliver Neukum CC: Adam Lee --- drivers/usb/class/cdc-acm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

On Mon, Apr 13, 2015 at 08:48:56PM +0930, Rusty Russell wrote: > Quentin Casasnovas writes: > > __ex_table is a simple table section where each entry is a pair of > > addresses - the first address is an address which can fault in kernel > > space, and the second address point

Re: [PATCH 1/7] modpost: add strict white-listing when referencing sections.

On Fri, Mar 20, 2015 at 11:59:41AM +1030, Rusty Russell wrote: > Quentin Casasnovas writes: > > Prints a warning when a section references a section outside a strict > > white-list. This will be useful to print a warning if __ex_table > > references a non-executable sec

Re: [PATCH 1/7] modpost: add strict white-listing when referencing sections.

On Fri, Mar 20, 2015 at 11:59:41AM +1030, Rusty Russell wrote: Quentin Casasnovas quentin.casasno...@oracle.com writes: Prints a warning when a section references a section outside a strict white-list. This will be useful to print a warning if __ex_table references a non-executable section

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

On Mon, Apr 13, 2015 at 08:48:56PM +0930, Rusty Russell wrote: Quentin Casasnovas quentin.casasno...@oracle.com writes: __ex_table is a simple table section where each entry is a pair of addresses - the first address is an address which can fault in kernel space, and the second address

[PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

this infinite loop. Fixes: 7e860a6e (cdc-acm: add sanity checks) Signed-off-by: Phil Turnbull phil.turnb...@oracle.com Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com CC: Oliver Neukum oneu...@suse.de CC: Adam Lee adam8...@gmail.com --- drivers/usb/class/cdc-acm.c | 3 ++- 1 file

Re: [PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

Adding Greg on CC as suggested by Oliver. On Mon, Apr 13, 2015 at 05:24:04PM +0200, Quentin Casasnovas wrote: Phil and I found out a problem with commit: 7e860a6e (cdc-acm: add sanity checks) It added some sanity checks to ignore potential garbage in CDC headers but also introduced

Re: [PATCH] cdc-acm: prevent infinite loop when parsing CDC headers.

On Mon, Apr 13, 2015 at 11:48:27PM +0800, Adam Lee wrote: On Mon, Apr 13, 2015 at 05:24:04PM +0200, Quentin Casasnovas wrote: Phil and I found out a problem with commit: 7e860a6e (cdc-acm: add sanity checks) It added some sanity checks to ignore potential garbage in CDC headers

Re: [PATCH] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly

On Sat, Apr 04, 2015 at 03:34:43PM +0200, Borislav Petkov wrote: > From: Borislav Petkov > > Quentin caught a corner case with the generation of instruction padding > in the ALTERNATIVE_2 macro: if len(orig_insn) < len(alt1) < len(alt2), > then not enough padding gets added and that is not

Re: [PATCH] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly

On Sat, Apr 04, 2015 at 03:34:43PM +0200, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Quentin caught a corner case with the generation of instruction padding in the ALTERNATIVE_2 macro: if len(orig_insn) len(alt1) len(alt2), then not enough padding gets added and that is not

Re: [PATCH] x86/xsave: Robustify and merge macros

On Sat, Apr 04, 2015 at 11:25:36AM +0200, Borislav Petkov wrote: > On Sat, Apr 04, 2015 at 10:36:11AM +0200, Quentin Casasnovas wrote: > > Since all of these are compile time constants, could we not use the safe > > variant on that same page? Not that I'm too worried about t

Re: [PATCH] x86/xsave: Robustify and merge macros

On Sat, Apr 04, 2015 at 09:34:54AM +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 10:42:17PM +0200, Quentin Casasnovas wrote: > > If you're happy with the extra padding in such cases then your second > > approach looks okay to me. But IMO, even if taking the '.if' directi

Re: [PATCH] x86/xsave: Robustify and merge macros

On Sat, Apr 04, 2015 at 09:34:54AM +0200, Borislav Petkov wrote: On Fri, Apr 03, 2015 at 10:42:17PM +0200, Quentin Casasnovas wrote: If you're happy with the extra padding in such cases then your second approach looks okay to me. But IMO, even if taking the '.if' directive approach

Re: [PATCH] x86/xsave: Robustify and merge macros

On Sat, Apr 04, 2015 at 11:25:36AM +0200, Borislav Petkov wrote: On Sat, Apr 04, 2015 at 10:36:11AM +0200, Quentin Casasnovas wrote: Since all of these are compile time constants, could we not use the safe variant on that same page? Not that I'm too worried about the signed right shift

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 07:48:24PM +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote: > > > Basically, the idea was: > > > > > > .skip len(repl1) - len(orig), 0x90 > > > .skip len(repl2) - len(repl1), 0x

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 07:06:25PM +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 05:40:55PM +0200, Quentin Casasnovas wrote: > > So yeah I still think we're not properly padding, if you take my earlier > > example where repl2 = 5 bytes, repl1 = 4 bytes and orin_insn = 3

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 05:23:24PM +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 04:14:26PM +0200, Quentin Casasnovas wrote: > > > This is obviously completely un-tested and not even compiled! :) > > > > > > > Told you! > > :-) > >

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 04:06:30PM +0200, Quentin Casasnovas wrote: > On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: > > On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: > > > I've tried compiling this on top of v4.0-rc5 and I get a compile e

Re: [PATCH] x86/xsave: Robustify and merge macros

On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: > On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: > > I've tried compiling this on top of v4.0-rc5 and I get a compile error > > because alt_end_marker isn't defined. Which other patches should I t

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 07:06:25PM +0200, Borislav Petkov wrote: On Fri, Apr 03, 2015 at 05:40:55PM +0200, Quentin Casasnovas wrote: So yeah I still think we're not properly padding, if you take my earlier example where repl2 = 5 bytes, repl1 = 4 bytes and orin_insn = 3. I'll let you re

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 07:48:24PM +0200, Borislav Petkov wrote: On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote: Basically, the idea was: .skip len(repl1) - len(orig), 0x90 .skip len(repl2) - len(repl1), 0x90 BUT!, for some reason I changed it to what's

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 04:06:30PM +0200, Quentin Casasnovas wrote: On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: I've tried compiling this on top of v4.0-rc5 and I get a compile error because

Re: [PATCH] x86/xsave: Robustify and merge macros

On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: I've tried compiling this on top of v4.0-rc5 and I get a compile error because alt_end_marker isn't defined. Which other patches should I take to test

Re: [PATCH] x86/xsave: Robustify and merge macros

On Fri, Apr 03, 2015 at 05:23:24PM +0200, Borislav Petkov wrote: On Fri, Apr 03, 2015 at 04:14:26PM +0200, Quentin Casasnovas wrote: This is obviously completely un-tested and not even compiled! :) Told you! :-) So all clear or we need to do more discussing? Basically

Re: [PATCH] x86/xsave: Robustify and merge macros

On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: > On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: > > FWIW I think this looks much nicer! I have a couple of comments though, > > apologies in advance if they aren't relevant :) > > No

Re: [PATCH] x86/xsave: Robustify and merge macros

where I'm not wrong about this, having a nicely named helper altinstr_are_applied() instead of manually checking the system_state variable would probably help! But maybe we're pretty confident this will not happen anyway? > Cleanup comments. > > Signed-off-by: Borislav Petkov > Cc: "H. Peter An

Re: [PATCH] x86/xsave: Robustify and merge macros

...@linutronix.de Cc: Quentin Casasnovas quentin.casasno...@oracle.com Cc: Oleg Nesterov o...@redhat.com Cc: Andy Lutomirski l...@amacapital.net --- arch/x86/include/asm/xsave.h | 141 ++- 1 file changed, 73 insertions(+), 68 deletions(-) diff --git

Re: [PATCH] x86/xsave: Robustify and merge macros

On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote: On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote: FWIW I think this looks much nicer! I have a couple of comments though, apologies in advance if they aren't relevant :) No worries, I very much appreciate

Re: Oops with tip/x86/fpu

On Thu, Mar 26, 2015 at 10:48:18PM +, Yu, Fenghua wrote: > > > sctxt->fpstate=(void *)1 changes the fpstate pointer in the > > > sigcontext. It will generate segfault and bad frame info in kernel. > > > > > > This is expected behavior, right? Is this still a valid test? > > > > Just to be

Re: Oops with tip/x86/fpu

On Thu, Mar 26, 2015 at 10:48:18PM +, Yu, Fenghua wrote: sctxt-fpstate=(void *)1 changes the fpstate pointer in the sigcontext. It will generate segfault and bad frame info in kernel. This is expected behavior, right? Is this still a valid test? Just to be clear, I saw a

Re: [PATCH 1/7] modpost: add strict white-listing when referencing sections.

On Tue, Mar 17, 2015 at 09:25:07AM -0700, Linus Torvalds wrote: > On Tue, Mar 17, 2015 at 5:39 AM, Quentin Casasnovas > wrote: > > Prints a warning when a section references a section outside a strict > > white-list. This will be useful to print a warning if __ex_table &g

Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.

Adding Rusty and Michal to CC. On Tue, Mar 17, 2015 at 01:40:02PM +0100, Quentin Casasnovas wrote: > __ex_table is a simple table section where each entry is a pair of > addresses - the first address is an address which can fault in kernel > space, and the second address points

Re: [PATCH 5/7] modpost: mismatch_handler: retrieve tosym information only when needed.

Adding Rusty and Michal to CC. On Tue, Mar 17, 2015 at 01:40:00PM +0100, Quentin Casasnovas wrote: > Signed-off-by: Quentin Casasnovas > --- > scripts/mod/modpost.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/scripts/mod/modpost.c b/scr

Re: [PATCH 4/7] modpost: factorize symbol pretty print in get_pretty_name().

Adding Rusty and Michal to CC. On Tue, Mar 17, 2015 at 01:39:59PM +0100, Quentin Casasnovas wrote: > Signed-off-by: Quentin Casasnovas > --- > scripts/mod/modpost.c | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) > > diff --git a/scrip

  1   2   >