On Wed Jan 24, 2024 at 8:21 PM EET, Verma, Vishal L wrote:

On Wed, 2023-11-08 at 07:36 +0000, Chen Ni wrote:

quoted

Add check for strsep() in order to transfer the error.

Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-
provided decrypted data")
Signed-off-by: Chen Ni <redacted>
---
 security/keys/encrypted-keys/encrypted.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/security/keys/encrypted-keys/encrypted.c

b/security/keys/encrypted-keys/encrypted.c
index 8af2136069d2..76f55dd13cb8 100644

--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c

@@ -237,6 +237,10 @@ static int datablob_parse(char *datablob, const

char **format,
 			break;
 		}
 		*decrypted_data = strsep(&datablob, " \t");
+		if (!*decrypted_data) {
+			pr_info("encrypted_key: decrypted_data is
missing\n");
+			break;
+		}

Hello,

This patch seems to break keyring usage in CXL and NVDIMM, with the
"decrypted_data is missing" error path being hit. Reverting this commit
fixes the tests. I'm not sure if there are valid scenarios where this is
expected to be empty?

Here's an strace snippet of where the error occurs:

   keyctl(KEYCTL_SEARCH, KEY_SPEC_USER_KEYRING, "user", "nvdimm-master", 0) = 76300785
   openat(AT_FDCWD, "/sys/devices/platform/cxl_acpi.0/root0/nvdimm-bridge0/ndbus0/nmem0/state", O_RDONLY|O_CLOEXEC) = 3
   read(3, "idle\n", 1024)                 = 5
   close(3)                                = 0
   keyctl(KEYCTL_SEARCH, KEY_SPEC_USER_KEYRING, "encrypted", "nvdimm:0", 0) = -1 ENOKEY (Required key not available)
   uname({sysname="Linux", nodename="fedora", ...}) = 0
   newfstatat(AT_FDCWD, "/etc/ndctl/keys/nvdimm_0_fedora.blob", 0x7fff23fbc210, 0) = -1 ENOENT (No such file or directory)
   add_key("encrypted", "nvdimm:0", "new enc32 user:nvdimm-master 32", 31, KEY_SPEC_USER_KEYRING) = -1 EINVAL (Invalid argument)
   

I think removing the klog message does not make sense meaning
that the recent revert was wrong action taken.

Instead necessary actions to retain backwards compatibility
must be taken, meaning that the branch should set "ret = 0;".

Motivation to keep it is dead obvious: your examples show that
it can reveal potentially incorrect behaviour in user space
software packages. It is info-level to mark that it can be
also false positive. I.e. the revert commit takes away
functionality that previously caused kernel masking a
potential bug.

Please revert the revert.

BR, Jarkko