All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Hannes Reinecke <hare@kernel.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: [hare-nvme:dhchap-keyring.v3 2/8] drivers/nvme/common/keyring.c:347:19: warning: variable 'keylen' is uninitialized when used here
Date: Fri, 20 Mar 2026 07:21:42 +0800	[thread overview]
Message-ID: <202603200745.dOgeJiFP-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/hare/nvme.git dhchap-keyring.v3
head:   7ffdb5e32339cf1e1ba50b8caefaca6dbab4d882
commit: 04e4f1368f8ff23feef8b02cba8c03732228faa7 [2/8] nvme-keyring: add 'dhchap' key type
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260320/202603200745.dOgeJiFP-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260320/202603200745.dOgeJiFP-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603200745.dOgeJiFP-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/nvme/common/keyring.c:347:19: warning: variable 'keylen' is uninitialized when used here [-Wuninitialized]
           prep->quotalen = keylen;
                            ^~~~~~
   drivers/nvme/common/keyring.c:309:40: note: initialize the variable 'keylen' to silence this warning
           size_t datalen = prep->datalen, keylen;
                                                 ^
                                                  = 0
   1 warning generated.


vim +/keylen +347 drivers/nvme/common/keyring.c

   292	
   293	/**
   294	 * nvme_dhchap_psk_preparse - prepare DH-HMAC-CHAP key data
   295	 * @prep: preparsed payload of the key data
   296	 *
   297	 * Decode the DH-HMAC-CHAP key data passed in in @prep and
   298	 * store the resulting binary data. The binary data includes
   299	 * space for the CRC, the version, and the hmac identifier,
   300	 * but the data length is just the key data without the CRC.
   301	 * This allows the user to read the key data via the
   302	 * 'user_read()' function. The additional 'version' ahd 'hmac'
   303	 * data is used in the ->read() callback to generate the
   304	 * base64 encoded key.
   305	 */
   306	static int nvme_dhchap_psk_preparse(struct key_preparsed_payload *prep)
   307	{
   308		struct user_key_payload *upayload;
   309		size_t datalen = prep->datalen, keylen;
   310		int ret;
   311		u32 crc;
   312		u8 version, hmac;
   313	
   314		if (!prep->data) {
   315			pr_debug("%s: Empty data", __func__);
   316			prep->payload.data[0] = NULL;
   317			prep->quotalen = 0;
   318			return -EINVAL;
   319		}
   320	
   321		if (sscanf(prep->data, "DHHC-%01hhu:%02hhu:%*s",
   322			   &version, &hmac) != 2) {
   323			pr_debug("%s: invalid key data '%s'\n", __func__,
   324				 (char *)prep->data);
   325			prep->payload.data[0] = NULL;
   326			prep->quotalen = 0;
   327			return -EINVAL;
   328		}
   329	
   330		/* skip header and final ':' character */
   331		datalen -= 11;
   332	
   333		/*
   334		 * payload is < key | version | hmac >
   335		 * base64 decode will always return less data
   336		 * than the encoded data, so allocating the size
   337		 * of the encoded data will be large enough.
   338		 */
   339		upayload = kzalloc(sizeof(*upayload) + datalen, GFP_KERNEL);
   340		if (!upayload) {
   341			prep->payload.data[0] = NULL;
   342			prep->quotalen = 0;
   343			return -ENOMEM;
   344		}
   345	
   346		/* decode the data */
 > 347		prep->quotalen = keylen;
   348		prep->payload.data[0] = upayload;
   349		ret = base64_decode(prep->data + 10, datalen, upayload->data,
   350				    true, BASE64_STD);
   351		if (ret < 0) {
   352			pr_debug("%s: Failed to decode key %s\n",
   353				 __func__, (char *)prep->data + 10);
   354			return ret;
   355		}
   356		ret -= 4;
   357		crc = ~crc32(~0, upayload->data, ret);
   358		if (get_unaligned_le32(upayload->data + ret) != crc) {
   359			pr_debug("%s: CRC mismatch for key\n", __func__);
   360			/* CRC mismatch */
   361			return -EKEYREJECTED;
   362		}
   363		/* append version and hmac to the payload */
   364		upayload->data[ret + 4] = version;
   365		upayload->data[ret + 5] = hmac;
   366		upayload->datalen = ret;
   367		return 0;
   368	}
   369	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

                 reply	other threads:[~2026-03-19 23:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202603200745.dOgeJiFP-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=hare@kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.