From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 064BF225A38 for ; Mon, 22 Jun 2026 16:37:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782146232; cv=none; b=YTEgwRW7kmUPOjJDOiQaDJM4sriLQm2ifgIgaK806qwMSHqi5+vmS/vMeR7UZFHZgxqREcRcC9Vj839R1Zqi+jVPezEwmoaCG0jgUzY3e9IgGHO1ebsdz1v6KWnIy9vDg+OkvBGa21swVR+aN+SStDjr/NRjVXZrw8yp1/zz6k0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782146232; c=relaxed/simple; bh=eJCNM22FWjYNfaU/daveGmD12ufPw4KFtvwawl9WsrM=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=HjxrXG3+E2Ut0z9Lo1AQrIQhD3vqZn8GDzDzxj3kpw7o6uv5sLWo9V9FK5VI5eDeT3nL76evAguFjNPZdrG2lqhj1M26s/HKnk3Oa3tWRHukZkfgAgfmyMdifGsPsZE6YacaHicukbIZtpeahDMg+GcP042nFSffynyCdtUNVZs= 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=iSHyiqVU; arc=none smtp.client-ip=209.85.216.42 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="iSHyiqVU" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-36d5fd50d20so3159982a91.1 for ; Mon, 22 Jun 2026 09:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782146230; x=1782751030; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yj2TH32Y5BL6HWxUhaxiYTaucxWSaRbNj1yzBP5WCS0=; b=iSHyiqVUhzAJUgTC82QQtz7+pIJyvOLUPy42C3aZe82httawuAk2rDt4Fx+1W1ODtI xeX40SvGFdsjbFcipoJko5gjD72w+CNEZcK5/0d1WjiGJisohjZhNUjk2fBLwhBUprNU 1fjmN3dF2Nc4DqpMk7tGxag3F12/IVM41cYgp2788Ic82J2VTyjpcc0fvZiBB1/LJ7xV OY91rMuMbqX+S7kIH15jpRxWNECqBnI+SLyn6p/DxVk80cGQ7FmSFIB/8JX3Y/SKQaJh U0HNYL4sv10xtNf6Y0Xo/UmCDjFy18+i1qPf1RLVdoJZdxoubC2v+5lN+Twvt9dXyrT4 C4Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782146230; x=1782751030; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yj2TH32Y5BL6HWxUhaxiYTaucxWSaRbNj1yzBP5WCS0=; b=QV7uP9TbEz3r2OsXg4KtlK0HFF22S6HM5UFJGc0R1Pzp/A0oSEDmy4OAwX0IeiLfuk QP0Kz+gew23wI0Rdcts8g6rrEjF8EE+B6yg2dYe2mGjFSQZe0kFebxNV807VZH1iFYlP 9flwxtkdfCU7vP4MV/gOiQWUYWbsCT2K3sDTQU+W+Ixj/AmWp6zUwkHVgH0lZ02ebM9Y E8DWAsUvo2prTUcruiDiPujcY2m8PR8DZnbZvDu81wBCcKW8N0btKcu4hMJvx5FuBPO8 Cbddq1jTAGdJpJnop4H5zsThsMk9Ew6z1RPLIjWXNa+NkedkqoSpq3Re5zSpw4NDAYCX XPOg== X-Forwarded-Encrypted: i=1; AHgh+RrzieRZwJWB4dE05F35H4wOomPH3p8F00KrtHpPKJLvnh5jHbdQJns4e3JBEFjHb0G0VnQvmqfM+KNe45w=@vger.kernel.org X-Gm-Message-State: AOJu0Yx85TEp8OZqYfgyDP6Rf39sJo8Gl+kVhqds9GjPGeo+/TbjEvN8 6HEQHqYmr5Zgk6jJU37KtcBkaf4EFsL2r6+eX4qyEHOjDc6tjMVPzqzqJUePzQ== X-Gm-Gg: AfdE7cl6ADQqRcQWlkS6019Tas/krNDcZy3TDWfgoIZd6BmKz2bgSDVjyqLc31sp3nm gtbRNc7TrJ6HuSL4z+BuuXGCp/TKhTIhUdnhN9DPkDWbMw4yiu5yNmwike2ypLpCZMIu8Peywkt NfAZYWyek3x33qZvnKL9QDkcxVt6z9QsM9OOPQ8mPfULshdQw7ZcvCDfatAfXlRgurJJY+c44vr BvGDcANu01B0Vq73dOzTcP50whbSlXVnjYo74LD4QWlfAvqpMLNAG9xGo+ceH9ycitFrgPWjZSg PeIhrWrgCo1ZaGgcEUDzGkwWUeteR+8fRLlzrriYBiZO4izjy7rIvEcbp9k83aP9TKGRXwKPacX zmvflGrh7edDMMwbvyTdtq3m6e1bRVRRqwJWyQWR1JqgTe1KLQ5rKqG/wvM4a2kFfCJ94HAdXrP pJ09CTjpLIt61wW5FO7KE9bAzf61BwJyJ7RvXj9g== X-Received: by 2002:a17:90b:1f83:b0:369:73a:326a with SMTP id 98e67ed59e1d1-37d1e8c9bbemr13858288a91.13.1782146230121; Mon, 22 Jun 2026 09:37:10 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37d4f008779sm7320273a91.6.2026.06.22.09.37.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 09:37:09 -0700 (PDT) From: Maoyi Xie To: Justin Tee , Paul Ely Cc: "Martin K. Petersen" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: lpfc: unbounded QFPA response length in lpfc_cmpl_els_qfpa() Date: Tue, 23 Jun 2026 00:37:06 +0800 Message-ID: <178214622623.2376914.7843191393281628987@maoyixie.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi all, I think lpfc_cmpl_els_qfpa() in drivers/scsi/lpfc/lpfc_els.c can overflow the qfpa_res buffer when the fabric returns a large length in the QFPA response. I would appreciate it if you could take a look. The completion handler allocates qfpa_res to a fixed size, then copies the response using a length taken straight from the response payload. if (!vport->qfpa_res) { max_desc = FCELSSIZE / sizeof(*vport->qfpa_res); vport->qfpa_res = kzalloc_objs(*vport->qfpa_res, max_desc); ... } len = *((u32 *)(pcmd + 4)); len = be32_to_cpu(len); memcpy(vport->qfpa_res, pcmd, len + 8); pcmd is the QFPA ELS response from the fabric. len is a 32 bit field read out of it with no validation. The memcpy then copies len + 8 bytes into qfpa_res, which was sized for FCELSSIZE. Nothing checks that len + 8 stays within that. A fabric or target that returns a large len overflows the qfpa_res heap buffer. The loop just below also walks vmid_range for len iterations with no clamp against MAX_PRIORITY_DESC. This runs when the VMID feature is negotiated. The attacker is a malicious or compromised fabric switch or target answering the QFPA request. I reproduced the overflow on 7.1-rc7. I ran the same copy with a 1020 byte qfpa_res buffer and a len that makes len + 8 larger than it. The copy runs past the buffer and faults. BUG: unable to handle page fault ... in memcpy_orig A check that len + 8 stays within the qfpa_res allocation, and that the descriptor count stays within MAX_PRIORITY_DESC, would close it. Does this look like a real bug to you, and is bounding len the right approach? If so I am happy to send a proper patch with a Fixes tag and Cc stable. Kaixuan Li and I found this together. Thanks, Maoyi https://maoyixie.com/