All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugene Syromiatnikov <esyr@redhat.com>
To: linux-kernel@vger.kernel.org,
	Christian Brauner <christian@brauner.io>,
	Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	Eric Biederman <ebiederm@xmission.com>
Subject: [PATCH v2] fork: check exit_signal passed in clone3() call
Date: Tue, 10 Sep 2019 18:58:39 +0100	[thread overview]
Message-ID: <20190910175839.GA27330@asgard.redhat.com> (raw)

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 kernel_clone_args to have int type) with argument sanity
check; moreover, it covers only clone3 case, and the code in
copy_process is still error-prone in the long run.  Ideally, the check
should be somewhere in the one place, but as of now this one place
is likely _do_fork, but it's kinda weir to have argument check there
as of now.

Changes since v1[2]:
 - Check changed to comparison against negated CSIGNAL to address
   the bug reported by Oleg[3].
 - Added a comment to _do_fork that exit_signal has to be checked
   by the caller.

[1] https://lkml.org/lkml/2019/9/10/581
[2] https://lkml.org/lkml/2019/9/10/411
[3] https://lkml.org/lkml/2019/9/10/467

Eugene Syromiatnikov (1):
  fork: check exit_signal passed in clone3() call

 kernel/fork.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

-- 
2.1.4


             reply	other threads:[~2019-09-10 17:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 17:58 Eugene Syromiatnikov [this message]
2019-09-10 17:58 [PATCH v2] fork: check exit_signal passed in clone3() call Eugene Syromiatnikov
2019-09-11 13:31 ` Oleg Nesterov
2019-09-11 13:47   ` Christian Brauner
2019-09-11 13:48 ` Andrew Morton
2019-09-11 13:52   ` Christian Brauner
2019-09-11 14:16     ` Christian Brauner
2019-09-11 14:32       ` Eugene Syromiatnikov
2019-09-11 14:54         ` Christian Brauner
2019-09-11 15:08           ` Dmitry V. Levin
2019-09-11 15:20           ` Eugene Syromiatnikov
2019-09-11 15:31             ` Christian Brauner
2019-09-13  9:07     ` Christian Brauner
2019-09-11 17:32 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190910175839.GA27330@asgard.redhat.com \
    --to=esyr@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian@brauner.io \
    --cc=ebiederm@xmission.com \
    --cc=ldv@altlinux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.