public inbox for llvm@lists.linux.dev
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox