fscrypt: drop patch n/a for 4.8.x

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

2 files changed, 0 insertions, 167 deletions

diff --git a/queue/fscrypt-fix-context-consistency-check-when-key-s-una.patch b/queue/fscrypt-fix-context-consistency-check-when-key-s-una.patch
deleted file mode 100644
index 4a569dc..0000000
--- a/queue/fscrypt-fix-context-consistency-check-when-key-s-una.patch
+++ /dev/null
@@ -1,166 +0,0 @@
-From 272f98f6846277378e1758a49a49d7bf39343c02 Mon Sep 17 00:00:00 2001
-From: Eric Biggers <ebiggers@google.com>
-Date: Fri, 7 Apr 2017 10:58:37 -0700
-Subject: [PATCH] fscrypt: fix context consistency check when key(s)
- unavailable
-
-commit 272f98f6846277378e1758a49a49d7bf39343c02 upstream.
-
-To mitigate some types of offline attacks, filesystem encryption is
-designed to enforce that all files in an encrypted directory tree use
-the same encryption policy (i.e. the same encryption context excluding
-the nonce).  However, the fscrypt_has_permitted_context() function which
-enforces this relies on comparing struct fscrypt_info's, which are only
-available when we have the encryption keys.  This can cause two
-incorrect behaviors:
-
-1. If we have the parent directory's key but not the child's key, or
-   vice versa, then fscrypt_has_permitted_context() returned false,
-   causing applications to see EPERM or ENOKEY.  This is incorrect if
-   the encryption contexts are in fact consistent.  Although we'd
-   normally have either both keys or neither key in that case since the
-   master_key_descriptors would be the same, this is not guaranteed
-   because keys can be added or removed from keyrings at any time.
-
-2. If we have neither the parent's key nor the child's key, then
-   fscrypt_has_permitted_context() returned true, causing applications
-   to see no error (or else an error for some other reason).  This is
-   incorrect if the encryption contexts are in fact inconsistent, since
-   in that case we should deny access.
-
-To fix this, retrieve and compare the fscrypt_contexts if we are unable
-to set up both fscrypt_infos.
-
-While this slightly hurts performance when accessing an encrypted
-directory tree without the key, this isn't a case we really need to be
-optimizing for; access *with* the key is much more important.
-Furthermore, the performance hit is barely noticeable given that we are
-already retrieving the fscrypt_context and doing two keyring searches in
-fscrypt_get_encryption_info().  If we ever actually wanted to optimize
-this case we might start by caching the fscrypt_contexts.
-
-Cc: stable@vger.kernel.org # 4.0+
-Signed-off-by: Eric Biggers <ebiggers@google.com>
-Signed-off-by: Theodore Ts'o <tytso@mit.edu>
-
-diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c
-index d71ec3780d0c..210976e7a269 100644
---- a/fs/crypto/policy.c
-+++ b/fs/crypto/policy.c
-@@ -137,27 +137,61 @@ int fscrypt_ioctl_get_policy(struct file *filp, void __user *arg)
- }
- EXPORT_SYMBOL(fscrypt_ioctl_get_policy);
- 
-+/**
-+ * fscrypt_has_permitted_context() - is a file's encryption policy permitted
-+ *				     within its directory?
-+ *
-+ * @parent: inode for parent directory
-+ * @child: inode for file being looked up, opened, or linked into @parent
-+ *
-+ * Filesystems must call this before permitting access to an inode in a
-+ * situation where the parent directory is encrypted (either before allowing
-+ * ->lookup() to succeed, or for a regular file before allowing it to be opened)
-+ * and before any operation that involves linking an inode into an encrypted
-+ * directory, including link, rename, and cross rename.  It enforces the
-+ * constraint that within a given encrypted directory tree, all files use the
-+ * same encryption policy.  The pre-access check is needed to detect potentially
-+ * malicious offline violations of this constraint, while the link and rename
-+ * checks are needed to prevent online violations of this constraint.
-+ *
-+ * Return: 1 if permitted, 0 if forbidden.  If forbidden, the caller must fail
-+ * the filesystem operation with EPERM.
-+ */
- int fscrypt_has_permitted_context(struct inode *parent, struct inode *child)
- {
--	struct fscrypt_info *parent_ci, *child_ci;
-+	const struct fscrypt_operations *cops = parent->i_sb->s_cop;
-+	const struct fscrypt_info *parent_ci, *child_ci;
-+	struct fscrypt_context parent_ctx, child_ctx;
- 	int res;
- 
--	if ((parent == NULL) || (child == NULL)) {
--		printk(KERN_ERR	"parent %p child %p\n", parent, child);
--		BUG_ON(1);
--	}
--
- 	/* No restrictions on file types which are never encrypted */
- 	if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
- 	    !S_ISLNK(child->i_mode))
- 		return 1;
- 
--	/* no restrictions if the parent directory is not encrypted */
--	if (!parent->i_sb->s_cop->is_encrypted(parent))
-+	/* No restrictions if the parent directory is unencrypted */
-+	if (!cops->is_encrypted(parent))
- 		return 1;
--	/* if the child directory is not encrypted, this is always a problem */
--	if (!parent->i_sb->s_cop->is_encrypted(child))
-+
-+	/* Encrypted directories must not contain unencrypted files */
-+	if (!cops->is_encrypted(child))
- 		return 0;
-+
-+	/*
-+	 * Both parent and child are encrypted, so verify they use the same
-+	 * encryption policy.  Compare the fscrypt_info structs if the keys are
-+	 * available, otherwise retrieve and compare the fscrypt_contexts.
-+	 *
-+	 * Note that the fscrypt_context retrieval will be required frequently
-+	 * when accessing an encrypted directory tree without the key.
-+	 * Performance-wise this is not a big deal because we already don't
-+	 * really optimize for file access without the key (to the extent that
-+	 * such access is even possible), given that any attempted access
-+	 * already causes a fscrypt_context retrieval and keyring search.
-+	 *
-+	 * In any case, if an unexpected error occurs, fall back to "forbidden".
-+	 */
-+
- 	res = fscrypt_get_encryption_info(parent);
- 	if (res)
- 		return 0;
-@@ -166,17 +200,32 @@ int fscrypt_has_permitted_context(struct inode *parent, struct inode *child)
- 		return 0;
- 	parent_ci = parent->i_crypt_info;
- 	child_ci = child->i_crypt_info;
--	if (!parent_ci && !child_ci)
--		return 1;
--	if (!parent_ci || !child_ci)
-+
-+	if (parent_ci && child_ci) {
-+		return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
-+			      FS_KEY_DESCRIPTOR_SIZE) == 0 &&
-+			(parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
-+			(parent_ci->ci_filename_mode ==
-+			 child_ci->ci_filename_mode) &&
-+			(parent_ci->ci_flags == child_ci->ci_flags);
-+	}
-+
-+	res = cops->get_context(parent, &parent_ctx, sizeof(parent_ctx));
-+	if (res != sizeof(parent_ctx))
-+		return 0;
-+
-+	res = cops->get_context(child, &child_ctx, sizeof(child_ctx));
-+	if (res != sizeof(child_ctx))
- 		return 0;
- 
--	return (memcmp(parent_ci->ci_master_key,
--			child_ci->ci_master_key,
--			FS_KEY_DESCRIPTOR_SIZE) == 0 &&
--		(parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
--		(parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
--		(parent_ci->ci_flags == child_ci->ci_flags));
-+	return memcmp(parent_ctx.master_key_descriptor,
-+		      child_ctx.master_key_descriptor,
-+		      FS_KEY_DESCRIPTOR_SIZE) == 0 &&
-+		(parent_ctx.contents_encryption_mode ==
-+		 child_ctx.contents_encryption_mode) &&
-+		(parent_ctx.filenames_encryption_mode ==
-+		 child_ctx.filenames_encryption_mode) &&
-+		(parent_ctx.flags == child_ctx.flags);
- }
- EXPORT_SYMBOL(fscrypt_has_permitted_context);
- 
--- 
-2.12.0
-
diff --git a/queue/series b/queue/series
index 49b7f63..9973235 100644
--- a/queue/series
+++ b/queue/series
@@ -190,7 +190,6 @@ CIFS-fix-oplock-break-deadlocks.patch
 cifs-fix-CIFS_IOC_GET_MNT_INFO-oops.patch
 CIFS-add-misssing-SFM-mapping-for-doublequote.patch
 padata-free-correct-variable.patch
-fscrypt-fix-context-consistency-check-when-key-s-una.patch
 serial-samsung-Use-right-device-for-DMA-mapping-call.patch
 serial-omap-fix-runtime-pm-handling-on-unbind.patch
 serial-omap-suspend-device-on-probe-errors.patch