On Mon, Nov 06, 2017 at 10:19:51PM -0800, Eric Biggers wrote:
From: Eric Biggers ebiggers@google.com
On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the largest permitted inputs (16384 bits), the kernel spends 10+ seconds doing modular exponentiation in mpi_powm() without rescheduling. If all threads do it, it locks up the system. Moreover, it can cause rcu_sched-stall warnings.
Notwithstanding the insanity of doing this calculation in kernel mode rather than in userspace, fix it by calling cond_resched() as each bit from the exponent is processed. It's still noninterruptible, but at least it's preemptible now.
Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Eric Biggers ebiggers@google.com
Patch applied. Thanks.
On Fri, Nov 10, 2017 at 10:37:30PM +1100, Herbert Xu wrote:
On Mon, Nov 06, 2017 at 10:19:51PM -0800, Eric Biggers wrote:
From: Eric Biggers ebiggers@google.com
On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the largest permitted inputs (16384 bits), the kernel spends 10+ seconds doing modular exponentiation in mpi_powm() without rescheduling. If all threads do it, it locks up the system. Moreover, it can cause rcu_sched-stall warnings.
Notwithstanding the insanity of doing this calculation in kernel mode rather than in userspace, fix it by calling cond_resched() as each bit from the exponent is processed. It's still noninterruptible, but at least it's preemptible now.
Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Eric Biggers ebiggers@google.com
Patch applied. Thanks.
If it's not too late can you fix the stable line to be just
Cc: stable@vger.kernel.org
As Mat pointed out KEYCTL_DH_COMPUTE was actually introduced in v4.7. Also I think the code is also reachable through RSA by adding an x509 certificate using the "asymmetric" key type, although that appears to be limited to 4096-bit inputs rather than 16384 bits.
Eric
linux-stable-mirror@lists.linaro.org