linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [PATCH 4.9 04/24] signal: Better detection of synchronous signals
Date: Wed, 13 Feb 2019 19:38:01 +0100	[thread overview]
Message-ID: <20190213183647.653529106@linuxfoundation.org> (raw)
In-Reply-To: <20190213183647.333441569@linuxfoundation.org>

4.9-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric W. Biederman <ebiederm@xmission.com>

commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
to deliver SIGHUP but always trying.

When the stack overflows delivery of SIGHUP fails and force_sigsegv is
called.  Unfortunately because SIGSEGV is numerically higher than
SIGHUP next_signal tries again to deliver a SIGHUP.

>From a quality of implementation standpoint attempting to deliver the
timer SIGHUP signal is wrong.  We should attempt to deliver the
synchronous SIGSEGV signal we just forced.

We can make that happening in a fairly straight forward manner by
instead of just looking at the signal number we also look at the
si_code.  In particular for exceptions (aka synchronous signals) the
si_code is always greater than 0.

That still has the potential to pick up a number of asynchronous
signals as in a few cases the same si_codes that are used
for synchronous signals are also used for asynchronous signals,
and SI_KERNEL is also included in the list of possible si_codes.

Still the heuristic is much better and timer signals are definitely
excluded.  Which is enough to prevent all known ways for someone
sending a process signals fast enough to cause unexpected and
arguably incorrect behavior.

Cc: stable@vger.kernel.org
Fixes: a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/signal.c |   52 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -696,6 +696,48 @@ static inline bool si_fromuser(const str
 		(!is_si_special(info) && SI_FROMUSER(info));
 }
 
+static int dequeue_synchronous_signal(siginfo_t *info)
+{
+	struct task_struct *tsk = current;
+	struct sigpending *pending = &tsk->pending;
+	struct sigqueue *q, *sync = NULL;
+
+	/*
+	 * Might a synchronous signal be in the queue?
+	 */
+	if (!((pending->signal.sig[0] & ~tsk->blocked.sig[0]) & SYNCHRONOUS_MASK))
+		return 0;
+
+	/*
+	 * Return the first synchronous signal in the queue.
+	 */
+	list_for_each_entry(q, &pending->list, list) {
+		/* Synchronous signals have a postive si_code */
+		if ((q->info.si_code > SI_USER) &&
+		    (sigmask(q->info.si_signo) & SYNCHRONOUS_MASK)) {
+			sync = q;
+			goto next;
+		}
+	}
+	return 0;
+next:
+	/*
+	 * Check if there is another siginfo for the same signal.
+	 */
+	list_for_each_entry_continue(q, &pending->list, list) {
+		if (q->info.si_signo == sync->info.si_signo)
+			goto still_pending;
+	}
+
+	sigdelset(&pending->signal, sync->info.si_signo);
+	recalc_sigpending();
+still_pending:
+	list_del_init(&sync->list);
+	copy_siginfo(info, &sync->info);
+	__sigqueue_free(sync);
+	return info->si_signo;
+}
+
 /*
  * called with RCU read lock from check_kill_permission()
  */
@@ -2216,7 +2258,15 @@ relock:
 			goto relock;
 		}
 
-		signr = dequeue_signal(current, &current->blocked, &ksig->info);
+		/*
+		 * Signals generated by the execution of an instruction
+		 * need to be delivered before any other pending signals
+		 * so that the instruction pointer in the signal stack
+		 * frame points to the faulting instruction.
+		 */
+		signr = dequeue_synchronous_signal(&ksig->info);
+		if (!signr)
+			signr = dequeue_signal(current, &current->blocked, &ksig->info);
 
 		if (!signr)
 			break; /* will return 0 */



  parent reply	other threads:[~2019-02-13 18:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 18:37 [PATCH 4.9 00/24] 4.9.157-stable review Greg Kroah-Hartman
2019-02-13 18:37 ` [PATCH 4.9 01/24] mtd: rawnand: gpmi: fix MX28 bus master lockup problem Greg Kroah-Hartman
2019-02-13 18:37 ` [PATCH 4.9 02/24] iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 03/24] signal: Always notice exiting tasks Greg Kroah-Hartman
2019-02-13 18:38 ` Greg Kroah-Hartman [this message]
2019-02-13 18:38 ` [PATCH 4.9 05/24] misc: vexpress: Off by one in vexpress_syscfg_exec() Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 06/24] samples: mei: use /dev/mei0 instead of /dev/mei Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 07/24] debugfs: fix debugfs_rename parameter checking Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 08/24] mips: cm: reprime error cause Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 09/24] MIPS: OCTEON: dont set octeon_dma_bar_type if PCI is disabled Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 10/24] MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 11/24] ARM: iop32x/n2100: fix PCI IRQ mapping Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 12/24] ARM: tango: Improve ARCH_MULTIPLATFORM compatibility Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 13/24] mac80211: ensure that mgmt tx skbs have tailroom for encryption Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 14/24] drm/modes: Prevent division by zero htotal Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 15/24] drm/vmwgfx: Fix setting of dma masks Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 16/24] drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 17/24] nfsd4: fix cached replies to solo SEQUENCE compounds Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 18/24] nfsd4: catch some false session retries Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 19/24] HID: debug: fix the ring buffer implementation Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 20/24] Revert "cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)" Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 21/24] libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive() Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 22/24] xfrm: refine validation of template and selector families Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 23/24] batman-adv: Avoid WARN on net_device without parent in netns Greg Kroah-Hartman
2019-02-13 18:38 ` [PATCH 4.9 24/24] batman-adv: Force mac header to start of data on xmit Greg Kroah-Hartman
2019-02-14  3:39 ` [PATCH 4.9 00/24] 4.9.157-stable review kernelci.org bot
2019-02-14 10:04 ` Jon Hunter
2019-02-14 16:30 ` Dan Rue
2019-02-14 19:16 ` Guenter Roeck
2019-02-14 22:22 ` shuah

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=20190213183647.653529106@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).