From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8CD137BE6C for ; Tue, 31 Mar 2026 18:26:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774981581; cv=none; b=mRPTIRfsKHz+tiIgevudv/BjdvSqMkSJsfSoICjXJehXi8BYgXVSi8oR5XXterwOdfiacNi4e1yKgrUZn52qVeBT202pKZX+1D/RqZD2KsGaBEsoY6F08J21xyZj37EWzk3KsGCQwwGSRFdkwo9SLEUn/v5e25B4jdk7LoUI7FU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774981581; c=relaxed/simple; bh=mHiRyPCnLDjJVk9PoLWPprhk2YfclD7sCEPrI/pJ9ZE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=loQnUqfb/3YzmFLztUPgUi3JwaeMelSkN/Sez6Rt7ztjvqxGA8oaJqafxyqnNkyuqnnHAh+1iSAcqVhf1ES2TRU2GKAZ4UjUNaJLSyUeSqLdwBoi+1IFYaU4N3lvf5dN8ASY1O+1JxXODvHPZUlBL27YVXLWLE+TRiEuaG0qf3s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mu1Dri5A; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mu1Dri5A" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-486fba7ce4cso60647355e9.3 for ; Tue, 31 Mar 2026 11:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774981578; x=1775586378; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mHiRyPCnLDjJVk9PoLWPprhk2YfclD7sCEPrI/pJ9ZE=; b=mu1Dri5AQn80g33OP8u3NqIqbWVCBbTRe4IcmWHkmAKun4JvZDs7O0hFnDSCCwbFHb qqj+VfHiwb00L2HyqXYtACJJEIDdU0J+9zO/H6aEzwqVbS1GNWTkgJn/2A9cPDA0MuYp bfrOpqfxbvcSRsQdTWq8RUBXmO+fACTNRodgIYcWlaE2eL+mFlectjM28nPhpDhcx63s D9AIYfpzw2GMIKPodULIaIMRAvRg09ZIbd8nCjr5GtRBfOLoXAPl8Z5jKKa5DsZtF2q2 Hp0TJZQS/fy83i8GRn2UL0QdkwN2iRbiA7XtS2XmWzTtpRn5QtWdybLDTFFjA8LiFjxu Bplg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774981578; x=1775586378; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mHiRyPCnLDjJVk9PoLWPprhk2YfclD7sCEPrI/pJ9ZE=; b=l9Qb0W8NmSV3TRqSLabVyFSPuCAJZ9ZcvFBieFqSmBYUq0oFowxtOk2/by26gKjihS ESUnxufgspms0+nVFmBhvCF7mzMJT+MpYbD2JNEExP2Za6FAb+c5xICraMtjx2IqoaPX 2xHnCaYE4gGKIpBKcXs6Z9wlaFkEMj4LnI5Z2+NrQ+/xfdLWhTwqVgxN3aQqXfICOFzE 5dzP4/hMHAVuLx2Vn/WArzvOlPD48vmvGloh+RkweDzCpVEwkoYuaKJLlm0uFzKl7JGs f6vwFA4O8xnkhgXoYuhRa+KMRSAA1cfNVkwjOsE8hwRgJh8tF/KlcXZmz7utb6u+9G42 NawQ== X-Forwarded-Encrypted: i=1; AJvYcCVeccT+81AH8kWRVRpoBa9AdHuge5jQV6QZkEB8nnpw/t5HsfVzM7kCLkMfqErgW+f7j2QBtz5iVDQnTY4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4s79FP2BRITVMEQb7iTmbRzQA8B35UhLsE3AmPuDcF8Dr1ju2 TLpdEx6ML2QbfI3CI7z+j/skcC3nLxTEh/u1VlEOyyCvzds6cS8Is7YS X-Gm-Gg: ATEYQzwGEbTvGK6WR5QvYVE0oxyqUX1SDNjs3Jjri5KSylz5NztFKVnvJpPWzM19oo0 CD64J4Ep+e7OvYUwz4hpyIWeyNtyDIn6HRC5cMb7NrieeTXUmEphvaMt2PnmpQWdfz6ObD0hnq/ f8l4L3d5yQQKfzUcp2u6yhOhqs2M/HphbCLzAAaKCyOE3SNVVnReWFASMjwsAkydqBQ9UV59c8n LGY3RDLG77G0BkIjWEl9aTVKDFbDOOzoVr6w4pDqom034wktORAkd88bQltvAPcZ/01RqY8s0tk 2rUdd/KNcbTizHDburQL5Is/Tq5IjY3FXcyJibfuANj7lfpj8FK8E3N6INQDAegTvpCNmeQ6Ut7 MYFPexdXfKa5Eqglw8ZjQRJf9TrOcA3xCtYForMqlWTxiXCuDTScXyRwIK+lThkT2EgSYTn94et iqfoplwn6HzW8LmCSL4q4MFNd6UYGBKY8kMAJBgy1FKgFFJGJhsDecbRCfg1b/ED71liClJyD8C WK/zkT+cqjLgpzG7A/PJF96VbwfPHLANp8JSyRIJVmw66f9 X-Received: by 2002:a05:600c:a016:b0:485:3f30:6250 with SMTP id 5b1f17b1804b1-4888359d87amr7002765e9.20.1774981578028; Tue, 31 Mar 2026 11:26:18 -0700 (PDT) Received: from DESKTOP-NQ2T5I7.localdomain (heme-13-b2-v4wan-167795-cust403.vm32.cable.virginm.net. [81.108.45.148]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887c884b5dsm20051105e9.18.2026.03.31.11.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 11:26:17 -0700 (PDT) From: Prathamesh Deshpande To: leon@kernel.org Cc: dledford@redhat.com, haggaie@mellanox.com, jgg@ziepe.ca, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, prathameshdeshpande7@gmail.com Subject: Re: [PATCH] IB/mlx5: Fix potential NULL dereference in query_device Date: Tue, 31 Mar 2026 19:25:56 +0100 Message-ID: <20260331182615.16983-1-prathameshdeshpande7@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260331134955.GF814676@unreal> References: <20260331134955.GF814676@unreal> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, Mar 31, 2026 at 04:49:55PM +0300, Leon Romanovsky wrote: > On Tue, Mar 31, 2026 at 02:44:27AM +0100, Prathamesh Deshpande wrote: > > Smatch reported an inconsistent NULL check for 'uhw' in > > mlx5_ib_query_device(). While 'uhw_outlen' is checked at the end of > > the function before calling ib_copy_to_udata(), 'uhw' is explicitly > > checked for NULL earlier in the same function. > > > > If a caller provides a non-zero 'uhw_outlen' but a NULL 'uhw' pointer, > > ib_copy_to_udata() will attempt to dereference 'uhw', > > How is it possible? Hi Leon, You are right that in the current uverbs paths, 'uhw_outlen' and 'uhw' should stay in sync. However, Smatch flags this as an inconsistency because 'uhw' is explicitly checked for NULL earlier in this same function (at line 968). If the code assumes 'uhw' could be NULL there, it is safer and more consistent to check the pointer directly before passing it to ib_copy_to_udata() at line 1357. This prevents any future refactoring or unconventional kernel-space callers from accidentally triggering a NULL dereference. What do you think? Thanks, Prathamesh