Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-13 Thread Christian Brauner
On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > On Wed, Sep 11, 2019 at 06:48:52AM -0700, Andrew Morton wrote: > > On Tue, 10 Sep 2019 18:58:52 +0100 Eugene Syromiatnikov > > wrote: > > > > > Previously, higher 32 bits of exit_signal fields were lost when > > > copied to the

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Eric W. Biederman
Eugene Syromiatnikov writes: > Previously, higher 32 bits of exit_signal fields were lost when > copied to the kernel args structure (that uses int as a type for the > respective field). Moreover, as Oleg has noted[1], exit_signal is used > unchecked, so it has to be checked for sanity before us

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Christian Brauner
On Wed, Sep 11, 2019 at 04:20:48PM +0100, Eugene Syromiatnikov wrote: > On Wed, Sep 11, 2019 at 04:54:47PM +0200, Christian Brauner wrote: > > On Wed, Sep 11, 2019 at 03:32:13PM +0100, Eugene Syromiatnikov wrote: > > > On Wed, Sep 11, 2019 at 04:16:36PM +0200, Christian Brauner wrote: > > > > On We

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Eugene Syromiatnikov
On Wed, Sep 11, 2019 at 04:54:47PM +0200, Christian Brauner wrote: > On Wed, Sep 11, 2019 at 03:32:13PM +0100, Eugene Syromiatnikov wrote: > > On Wed, Sep 11, 2019 at 04:16:36PM +0200, Christian Brauner wrote: > > > On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > > > > On Wed,

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Dmitry V. Levin
On Wed, Sep 11, 2019 at 04:54:47PM +0200, Christian Brauner wrote: > On Wed, Sep 11, 2019 at 03:32:13PM +0100, Eugene Syromiatnikov wrote: > > On Wed, Sep 11, 2019 at 04:16:36PM +0200, Christian Brauner wrote: > > > On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > > > > On Wed,

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Christian Brauner
On Wed, Sep 11, 2019 at 03:32:13PM +0100, Eugene Syromiatnikov wrote: > On Wed, Sep 11, 2019 at 04:16:36PM +0200, Christian Brauner wrote: > > On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > > > On Wed, Sep 11, 2019 at 06:48:52AM -0700, Andrew Morton wrote: > > > > What are the

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Eugene Syromiatnikov
On Wed, Sep 11, 2019 at 04:16:36PM +0200, Christian Brauner wrote: > On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > > On Wed, Sep 11, 2019 at 06:48:52AM -0700, Andrew Morton wrote: > > > What are the user-visible runtime effects of this bug? The userspace can set -1 as an exi

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Christian Brauner
On Wed, Sep 11, 2019 at 03:52:36PM +0200, Christian Brauner wrote: > On Wed, Sep 11, 2019 at 06:48:52AM -0700, Andrew Morton wrote: > > On Tue, 10 Sep 2019 18:58:52 +0100 Eugene Syromiatnikov > > wrote: > > > > > Previously, higher 32 bits of exit_signal fields were lost when > > > copied to the

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Christian Brauner
On Wed, Sep 11, 2019 at 06:48:52AM -0700, Andrew Morton wrote: > On Tue, 10 Sep 2019 18:58:52 +0100 Eugene Syromiatnikov > wrote: > > > Previously, higher 32 bits of exit_signal fields were lost when > > copied to the kernel args structure (that uses int as a type for the > > respective field).

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Andrew Morton
On Tue, 10 Sep 2019 18:58:52 +0100 Eugene Syromiatnikov wrote: > Previously, higher 32 bits of exit_signal fields were lost when > copied to the kernel args structure (that uses int as a type for the > respective field). Moreover, as Oleg has noted[1], exit_signal is used > unchecked, so it has

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Christian Brauner
On Wed, Sep 11, 2019 at 03:31:20PM +0200, Oleg Nesterov wrote: > On 09/10, Eugene Syromiatnikov wrote: > > > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -2338,6 +2338,8 @@ struct mm_struct *copy_init_mm(void) > > * > > * It copies the process, and if successful kick-starts > > * it a

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-11 Thread Oleg Nesterov
On 09/10, Eugene Syromiatnikov wrote: > > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -2338,6 +2338,8 @@ struct mm_struct *copy_init_mm(void) > * > * It copies the process, and if successful kick-starts > * it and waits for it to finish using the VM if required. > + * > + * args->exit_sign

[PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-10 Thread Eugene Syromiatnikov
Hello. After some consideration, I've decided to utilise Oleg's proposal[1] "(args.exit_signal & ~((u64)CSIGNAL))" as a check. I still don't like it, as it mixes argument copy check (I'm not sure if it's ever needed, however, as I'm not sure if there's a reason for exit_signal field of struct kern

[PATCH v2] fork: check exit_signal passed in clone3() call

2019-09-10 Thread Eugene Syromiatnikov
Previously, higher 32 bits of exit_signal fields were lost when copied to the kernel args structure (that uses int as a type for the respective field). Moreover, as Oleg has noted[1], exit_signal is used unchecked, so it has to be checked for sanity before use; for the legacy syscalls, applying CS