From patchwork Wed Mar 11 19:48:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 1253172 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=v/jab1Mt; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 48d2Zq5GWJz9sRf for ; Thu, 12 Mar 2020 06:48:51 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731165AbgCKTsn (ORCPT ); Wed, 11 Mar 2020 15:48:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:50060 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387394AbgCKTsm (ORCPT ); Wed, 11 Mar 2020 15:48:42 -0400 Received: from sol.localdomain (c-107-3-166-239.hsd1.ca.comcast.net [107.3.166.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5F6A020691; Wed, 11 Mar 2020 19:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583956122; bh=NTCCQBA/qngUM9vruihaGQpLvV8cowQXBnlryjh7duc=; h=Date:From:To:Cc:Subject:From; b=v/jab1Mtz7GdBG9uHSDV6k2H9A5ugStqAz7qXsT5oSvLW0R8a6a71HOmgfCea5clU G66Us11UI+4tNO3Dj0FH7tIcAgD6G5vzcw6dOTDobm5SYL6M1oFXxg7KIYICRZtMGR 9CaWX6LC7nIdux3wMMCMyiTs0f5kOJR5zRFuyh0M= Date: Wed, 11 Mar 2020 12:48:39 -0700 From: Eric Biggers To: Linus Torvalds Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Theodore Ts'o , Jaegeuk Kim Subject: [GIT PULL] fscrypt fix for v5.6-rc6 Message-ID: <20200311194839.GB41227@sol.localdomain> MIME-Version: 1.0 Content-Disposition: inline Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org The following changes since commit 98d54f81e36ba3bf92172791eba5ca5bd813989b: Linux 5.6-rc4 (2020-03-01 16:38:46 -0600) are available in the Git repository at: https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt-for-linus for you to fetch changes up to 2b4eae95c7361e0a147b838715c8baa1380a428f: fscrypt: don't evict dirty inodes after removing key (2020-03-07 18:43:07 -0800) ---------------------------------------------------------------- Fix a bug where if userspace is writing to encrypted files while the FS_IOC_REMOVE_ENCRYPTION_KEY ioctl (introduced in v5.4) is running, dirty inodes could be evicted, causing writes could be lost or the filesystem to hang due to a use-after-free. This was encountered during real-world use, not just theoretical. Tested with the existing fscrypt xfstests, and with a new xfstest I wrote to reproduce this bug. This fix does expose an existing bug with '-o lazytime' that Ted is working on fixing, but this fscrypt fix is more critical and is needed anyway regardless of the lazytime fix. ---------------------------------------------------------------- Eric Biggers (1): fscrypt: don't evict dirty inodes after removing key fs/crypto/keysetup.c | 9 +++++++++ 1 file changed, 9 insertions(+)