linux-kernel - RE: [PATCH] drbd: do not ignore signals in threads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6259de605e9246b095233e3984262b93@AcuMS.aculab.com>
Date:   Mon, 29 Jul 2019 08:50:04 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Christoph Böhmwalder' 
        <christoph.boehmwalder@...bit.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "Eric W . Biederman" <ebiederm@...ssion.com>,
        Jens Axboe <axboe@...nel.dk>,
        Philipp Reisner <philipp.reisner@...bit.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] drbd: do not ignore signals in threads

From: Christoph Böhmwalder
> Sent: 29 July 2019 09:33
> Fix a regression introduced by upstream commit fee109901f39
> ('signal/drbd: Use send_sig not force_sig').
> 
> Currently, when a thread is initialized, all signals are set to be
> ignored by default. DRBD uses SIGHUP to end its threads, which means it
> is now no longer possible to bring down a DRBD resource because the
> signals do not make it through to the thread in question.
> 
> This circumstance was previously hidden by the fact that DRBD used
> force_sig() to kill its threads. The aforementioned upstream commit
> changed this to send_sig(), which means the effects of the signals being
> ignored by default are now becoming visible.
> 
> Thus, issue an allow_signal() at the start of the thread to explicitly
> allow the desired signals.

Doesn't unmasking the signals and using send_sig() instead  of force_sig()
have the (probably unwanted) side effect of allowing userspace to send
the signal?

I've certainly got some driver code that uses force_sig() on a kthread
that it doesn't (ever) want userspace to signal.

The origina1 commit says:
> Further force_sig is for delivering synchronous signals (aka exceptions).
> The locking in force_sig is not prepared to deal with running processes, as
> tsk->sighand may change during exec for a running process.

I think a lot of code has assumed that the only real difference between
send_sig() and force_sig() is that the latter ignores the signal mask.

If you need to unblock a kernel thread (eg one blocked in kernel_accept())
in order to unload a driver, then you really don't want it to be possible
for anything else to signal the kthread.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)