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:
> > 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 <nichen@xxxxxxxxxxx>
> > ---
> > 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
