Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp69521imm; Thu, 4 Oct 2018 23:28:14 -0700 (PDT) X-Google-Smtp-Source: ACcGV617s5whcG1BXeBGnR2Ymaxy4ywG5FmQnr+3BNiUF8suz4/1yFt9ksTSGYm/2qAI4mAv63yr X-Received: by 2002:a62:9015:: with SMTP id a21-v6mr10432604pfe.49.1538720894713; Thu, 04 Oct 2018 23:28:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538720894; cv=none; d=google.com; s=arc-20160816; b=mDHvEBeCEHgwSgI2ifQTXS8kBo5k81RPeN5X/3bNp98x46GkfE9Gf+YdJtcJEBI8lb t8k54r4bxnQfoqY9Y/X5ynQG/5vt99mjkC73SWveKsvTddZsoZTg2Q4aU9/QLrbySaib 0cDx6kY4gftnMUAKcKEsQNqO2oj3el54UZjiJUMZ4alv5AWhvOy9yxukzfs4xn5IRxlP zoKrOdQA5Bskag4ExAGyUSBDAc0ku7j1ReW777o5j/AXVbDJ6o360Ps90zXTHpvfJnWA rl/rIJsa6U7UfubL8TzrrmTCx35UjOl1OPrkHSb0KkuxhHClKaeK6KmAuGBaR4/jLU58 PdFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=kH7QkVAV1mFfkdd85Unvy/dcix/BR1RxpRrFAKnHt2A=; b=PO5rLyzSyqPoQcKyyP2gOVS5xVySSeY3SE2+obFSh5VKQQ+njerZ/AJ4CuHXf9281t 22QXSW8agEuRh3qp5l4Q7y+2SK4cldNjpNcqO311hB7aN8SRuUNF5VyAQLgPcYHxXzbG J4E9Ba3dL54TRBHu4iuUB5Z4imfIhgTJ6fOO1KsvywhSWJ4Lw3RLGwFUKDB19s4FgUJ3 4Pl1ixlJaBenQLLiGL3UN53JRsn9GsuAmZsr2IXQkDsg1gu+vP9dEKpjH2ewQdzEpn/a qkBhx1t9gwLZ014MmQESm0nxPoBA5Hvb9/fcjup9JcJkdYry8YOG+H80f4V+0XgBkmPT u68w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u66-v6si7439550pgu.94.2018.10.04.23.27.58; Thu, 04 Oct 2018 23:28:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727701AbeJENZH (ORCPT + 99 others); Fri, 5 Oct 2018 09:25:07 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:34690 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726732AbeJENZG (ORCPT ); Fri, 5 Oct 2018 09:25:06 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1g8Jaa-00075N-8R; Fri, 05 Oct 2018 00:27:52 -0600 Received: from [105.184.227.67] (helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1g8JaZ-00041h-2G; Fri, 05 Oct 2018 00:27:52 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrei Vagin Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, Oleg Nesterov , Linus Torvalds References: <87h8idv6nw.fsf@xmission.com> <20180925171906.19683-2-ebiederm@xmission.com> <20181005060611.GA19061@gmail.com> Date: Fri, 05 Oct 2018 08:27:41 +0200 In-Reply-To: <20181005060611.GA19061@gmail.com> (Andrei Vagin's message of "Thu, 4 Oct 2018 23:06:13 -0700") Message-ID: <87h8i0di1u.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1g8JaZ-00041h-2G;;;mid=<87h8i0di1u.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=105.184.227.67;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19pZRjL1HtfFG/4JsByTJkhqckh7ZMpQpg= X-SA-Exim-Connect-IP: 105.184.227.67 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa04.xmission.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01, T_TooManySym_02,T_TooManySym_03,XMNoVowels,XMSubLong autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 TR_Symld_Words too many words that have symbols inside * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Andrei Vagin X-Spam-Relay-Country: X-Spam-Timing: total 355 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 4.1 (1.1%), b_tie_ro: 2.7 (0.8%), parse: 1.58 (0.4%), extract_message_metadata: 27 (7.6%), get_uri_detail_list: 4.7 (1.3%), tests_pri_-1000: 11 (3.0%), tests_pri_-950: 1.82 (0.5%), tests_pri_-900: 1.53 (0.4%), tests_pri_-400: 36 (10.1%), check_bayes: 34 (9.5%), b_tokenize: 13 (3.6%), b_tok_get_all: 9 (2.6%), b_comp_prob: 3.8 (1.1%), b_tok_touch_all: 6 (1.6%), b_finish: 0.63 (0.2%), tests_pri_-100: 8 (2.2%), check_dkim_signature: 0.75 (0.2%), check_dkim_adsp: 3.4 (0.9%), tests_pri_0: 246 (69.2%), tests_pri_10: 3.9 (1.1%), tests_pri_500: 9 (2.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [REVIEW][PATCH 2/6] signal: Fail sigqueueinfo if si_signo != sig X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrei Vagin writes: > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote: >> The kernel needs to validate that the contents of struct siginfo make >> sense as siginfo is copied into the kernel, so that the proper union >> members can be put in the appropriate locations. The field si_signo >> is a fundamental part of that validation. As such changing the >> contents of si_signo after the validation make no sense and can result >> in nonsense values in the kernel. > > Accoding to the man page, the user should not set si_signo, it has to be set > by kernel. > > $ man 2 rt_sigqueueinfo > > The uinfo argument specifies the data to accompany the signal. This > argument is a pointer to a structure of type siginfo_t, described in > sigaction(2) (and defined by including ). The caller > should set the following fields in this structure: > > si_code > This must be one of the SI_* codes in the Linux kernel source > file include/asm-generic/siginfo.h, with the restriction that > the code must be negative (i.e., cannot be SI_USER, which is > used by the kernel to indicate a signal sent by kill(2)) and > cannot (since Linux 2.6.39) be SI_TKILL (which is used by the > kernel to indicate a signal sent using tgkill(2)). > > si_pid This should be set to a process ID, typically the process ID of > the sender. > > si_uid This should be set to a user ID, typically the real user ID of > the sender. > > si_value > This field contains the user data to accompany the signal. For > more information, see the description of the last (union sigval) > argument of sigqueue(3). > > Internally, the kernel sets the si_signo field to the value specified > in sig, so that the receiver of the signal can also obtain the signal > number via that field. > >> >> As such simply fail if someone is silly enough to set si_signo out of >> sync with the signal number passed to sigqueueinfo. >> >> I don't expect a problem as glibc's sigqueue implementation sets >> "si_signo = sig" and CRIU just returns to the kernel what the kernel >> gave to it. >> >> If there is some application that calls sigqueueinfo directly that has >> a problem with this added sanity check we can revisit this when we see >> what kind of crazy that application is doing. > > > I already know two "applications" ;) > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ptrace/peeksiginfo.c > https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/sigpending.c > > Disclaimer: I'm the author of both of them. Fair enough. Then this counts as a regression. The setting in the kernel happens in an awkward place and I will see if it can be moved earlier. Eric >> Signed-off-by: "Eric W. Biederman" >> --- >> kernel/signal.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/signal.c b/kernel/signal.c >> index 7b49c31d3fdb..e445b0a63faa 100644 >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -3306,7 +3306,8 @@ static int do_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t *info) >> (task_pid_vnr(current) != pid)) >> return -EPERM; >> >> - info->si_signo = sig; >> + if (info->si_signo != sig) >> + return -EINVAL; >> >> /* POSIX.1b doesn't mention process groups. */ >> return kill_proc_info(sig, info, pid); >> @@ -3354,7 +3355,8 @@ static int do_rt_tgsigqueueinfo(pid_t tgid, pid_t pid, int sig, siginfo_t *info) >> (task_pid_vnr(current) != pid)) >> return -EPERM; >> >> - info->si_signo = sig; >> + if (info->si_signo != sig) >> + return -EINVAL; >> >> return do_send_specific(tgid, pid, sig, info); >> }