[PATCH AUTOSEL 6.17-6.1] scsi: ufs: host: mediatek: Fix invalid access in vccqx handling

Sasha Levin sashal at kernel.org
Sat Oct 25 08:55:39 PDT 2025


From: Alice Chao <alice.chao at mediatek.com>

[ Upstream commit 5863638598f5e4f64d2f85b03f376383ca1f2ab7 ]

Add a NULL check before accessing the 'vccqx' pointer to prevent invalid
memory access. This ensures that the function safely handles cases where
'vccq' and 'vccq2' are not initialized, improving the robustness of the
power management code.

Signed-off-by: Alice Chao <alice.chao at mediatek.com>
Reviewed-by: Peter Wang <peter.wang at mediatek.com>
Signed-off-by: Peter Wang <peter.wang at mediatek.com>
Link: https://lore.kernel.org/r/20250811131423.3444014-11-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen <martin.petersen at oracle.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

Rationale
- The patch adds a defensive NULL guard in `ufs_mtk_vccqx_set_lpm()` so
  it immediately returns if both `vccq` and `vccq2` are absent. This
  prevents a NULL dereference on `vccqx->reg` when neither rail is
  defined in DT or has been released earlier.
- Specifically, the change adds: `if (!hba->vreg_info.vccq &&
  !hba->vreg_info.vccq2) return;` before dereferencing `vccqx` in
  `drivers/ufs/host/ufs-mediatek.c:1506`.
- Without this guard, the function selects `vccqx` from
  `hba->vreg_info.vccq` or `...vccq2` and unconditionally does
  `regulator_set_mode(vccqx->reg, ...)` (drivers/ufs/host/ufs-
  mediatek.c:1515), which is unsafe if both are NULL.
- The UFS core explicitly allows these supplies to be optional, meaning
  NULL is a valid state when a supply is not provided in DT: parsing
  populates `vccq`/`vccq2` optionally (drivers/ufs/host/ufshcd-
  pltfrm.c:168).
- The Mediatek driver also clears the pointer to NULL when it
  deliberately disables a VCCQx rail (e.g., after freeing the vreg in
  `ufs_mtk_vreg_fix_vccqx()`, drivers/ufs/host/ufs-mediatek.c:1072).
  That makes the callee’s NULL-robustness important.

Why this matters despite caller checks
- Today, `ufs_mtk_dev_vreg_set_lpm()` computes `skip_vccqx` and only
  calls `ufs_mtk_vccqx_set_lpm()` when appropriate
  (drivers/ufs/host/ufs-mediatek.c:1537, 1555, 1560). However, this is a
  single call site and relies on all future call paths being equally
  careful.
- The new guard makes `ufs_mtk_vccqx_set_lpm()` itself robust,
  eliminating a class of NULL deref crashes if it is ever called without
  prior checks, or if future refactors change the call sites.

Stable backport criteria
- Bug fix that prevents kernel NULL deref (user-visible reliability
  issue).
- Change is minimal, localized, and has no architectural impact.
- No functional side effects when supplies exist; when both are absent,
  early return is the correct behavior (nothing to configure).
- Touches a specific host driver (MediaTek UFS), keeping risk of
  regression low and scope confined.

Conclusion
- This is a safe, targeted fix to avoid invalid memory access in a power
  management path. It improves robustness with negligible risk and
  should be backported to stable.

 drivers/ufs/host/ufs-mediatek.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 82160da8ec71b..bb0be6bed1bca 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -1589,6 +1589,9 @@ static void ufs_mtk_vccqx_set_lpm(struct ufs_hba *hba, bool lpm)
 {
 	struct ufs_vreg *vccqx = NULL;
 
+	if (!hba->vreg_info.vccq && !hba->vreg_info.vccq2)
+		return;
+
 	if (hba->vreg_info.vccq)
 		vccqx = hba->vreg_info.vccq;
 	else
-- 
2.51.0




More information about the linux-arm-kernel mailing list