From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.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 8C03931DDBB for ; Sun, 14 Jun 2026 13:06:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781442391; cv=none; b=cJA5oSc8lXQQwlOUtBsI50FtpgjBRK2GSct3iVVBiS9QgWb/Z4RgwUngMXLsO/GfehqJYxutv9hNfxICYUey9g0BK1Jd1Ytgam734IEeQztYvoRPOpHYhDy3Jw2Ct1ZpjIhfOntj0H5R5VKuTj94iNIs7g/txZzDegXVaGAv9gk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781442391; c=relaxed/simple; bh=F8nefapGpq1hkNr3dR953PbBEi8lHQKnLkLvosnH5/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U+SbalHXswfCA3Ofo4HzBsdZchICqguQhIrKypadjHaE7FWubXUmfiXhrFjmfT9r+b+ur6OFZ82KtGwIAcR4VihgMk5Rp5MjSp3ld8deh2d0GE0lEA7b8ANdNIB2DD5b50OBT/+t9EAhdgL9EwFTnaB7zQvYvUkwCPOxfRUeX2E= 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=HHQLSkWM; arc=none smtp.client-ip=209.85.219.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="HHQLSkWM" Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-8ccdf8d4ac5so31140176d6.1 for ; Sun, 14 Jun 2026 06:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781442389; x=1782047189; 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=LaU8/SkUlaCNRKpR7Ka7OTF4Zk+4rJg57uFLh3oSqoI=; b=HHQLSkWMJmNQDNEckbs6WiS9bLNmOImbTP4hPpd1VnjAAsuN+wsRCpAocV2Sm4yaZc 5x/YnbV7TOcz4YzKagJabG3MEV/jRkxCYTa/jnx8EUoxH8PuzzunECU51kJx/pXlHBbV b+vAtxB5z8tUAUjhM6/YNNtTJXcvNJePduoWBjw/CCeHNeOHGdpbawGrTdalZs3rf+qM KPcfbuqxSHuqHUN8Li5a+4gsVOD34kzwQ4J3BS1UAs8Bl2AYgjJ95gxFjK56ELGQroxP DsaNM5oIXP31DwU5RSloTe+i5w3ty6c5RkqnmV87v08NdGCQWFpAdQnZQlim3gBB1iBi OKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781442389; x=1782047189; 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=LaU8/SkUlaCNRKpR7Ka7OTF4Zk+4rJg57uFLh3oSqoI=; b=sGSfcqNi/Okvs+j73GpoIGIYa8J+b2Qc8nWsJw/qEdWrCSkFjh/UIY3fZqc59pq2my 0eJMt8/xW9wlOR0eyASI/xD45IPqF51qMOrN0OWt4mvUnbQUKAdYWGLOrcYgwme/De6D EVllM31chrQexdGsP3tCrlGlRhBbVqxHxyh3wCCjfU5JnKqhZJH3+Ii5brMaHI5LvQjC rZz4HLdaZRXTHbv07x+ZAf35Wk4re7bT0ZgsfnFdXXhvhdQs/58cbXQLgGKEtXlsCXYL ZlkgEB8mHzVlGRJHBpTDGxa3tJJIj1G54iQEZfIStNRFimHLSUi2ys11J3EI4F+cYQAg eCYg== X-Forwarded-Encrypted: i=1; AFNElJ/LmWQPd7Wtdc+qUUGq229agt5Wk0I65PxBvCVFa3CdzpHHifCrTY7H6PcD0papqXpZAd/jJ+07h9VKlH8=@vger.kernel.org X-Gm-Message-State: AOJu0Ywk7pqJhFBJmyNzsXqWjZvZWGjFJlTxeODHbt59lJjVtRepgpkE 3+L2Dg4sTtrkV7pvgm+6a5Op3BPVkQwY1vVX21t/SiSnIbw4suzCXVqM X-Gm-Gg: Acq92OF88q5qbT24RMy8YH32gm/2dsfrFXqjy6YAWjxo2qUjwwKyuLZmyQUS9mlRMFI xsQqfTaf/KhCIJ3hDIOQTy4WKRK0nag0FZA08/voKgaoGd1CHZNXgS+BljBE8hwQAeQEU5gUQOj wncoBx0KOaAv1cvdhTgOFXpumYZHVfLa7mDu1D7knHxyUeLVOK8dZoHyzyxJxnHG1xvGvG9qrzw 6xBmbLFdeT72eZ0vo16O/G0kFe/wHsfEoGCUVZXeRCxkrsHQYYL3KDXfYf3qu14BkLgA3Tt3WWV izXU4GMULqn2oZghGHS8wjerMBc7hq4FEYkqPTmh+fRHwzkR53AF86BPiwNxzEsBT6jbL2u8W9T kN4mVvqpdRiJv0wmGpBCF4thFIgWMyfwdLc/I+fV9UzYip7m34e2ZgM46/cNP0MSCBqgf0u1R03 LhloPxKEF4ieYFPw09awxy/UfWpuoG2XFVvlg1XP44lmdhOJVb1KXnXLnb+kq3LhSm6uWs4s0Ee LVQ9MYYBldzpmEV02CC0MAFWNo1J0a7bTDbwkLVQXA= X-Received: by 2002:a05:6214:1d07:b0:8ce:cfb3:2800 with SMTP id 6a1803df08f44-8d32b47adcamr190019316d6.2.1781442389443; Sun, 14 Jun 2026 06:06:29 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8d301a32d5csm77937106d6.12.2026.06.14.06.06.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2026 06:06:28 -0700 (PDT) From: Michael Bommarito To: Giovanni Cabiddu , Herbert Xu Cc: "David S . Miller" , Kees Cook , qat-linux@intel.com, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] crypto: qat - validate migration section header is in bounds Date: Sun, 14 Jun 2026 09:06:18 -0400 Message-ID: <20260614130619.2519534-2-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260614130619.2519534-1-michael.bommarito@gmail.com> References: <20260614130619.2519534-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit adf_mstate_mgr_init_from_remote() sets the section-walk cursor to mgr->buf + preh_len from the remote migration preamble. The default preamble checker only rejects preh_len > mgr->size, so preh_len == mgr->size (the 4096-byte QAT VF state buffer) puts mgr->state one region past the allocation while n_sects is still honoured. adf_mstate_sect_validate() then reads sect->size from that cursor before proving the section header is in the buffer. The remote stream reaches this parser from the destination-host VFIO migration path (qat_vf_resume_write), so a malformed import reads out of bounds. Reject section headers not fully contained in the state buffer before dereferencing any of their fields. Reproduced under KASAN on QEMU via the KUnit case in patch 2; the slab-out-of-bounds read is gone after this change. Fixes: f0bbfc391aa7 ("crypto: qat - implement interface for live migration") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- The patch 2 KUnit case drives the real parser on a kmalloc(4096) buffer under KASAN on QEMU x86_64. Trigger {preh_len=4096, n_sects=1}: stock tree reports BUG: KASAN: slab-out-of-bounds in qat_mstate_remote_run reading sect->size 8 bytes past the allocation; patched it returns -EINVAL and KASAN is silent. Two benign controls (empty preamble, in-bounds section header) drive the same path with no OOB and pass on both trees. No in-tree selftest exercises adf_mstate_mgr.c; patch 2 is the coverage offered. KASAN build of the touched object is warning clean. .../crypto/intel/qat/qat_common/adf_mstate_mgr.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c b/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c index f9017e03ec0f2..7370b87f72a2f 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c +++ b/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c @@ -231,8 +231,18 @@ static int adf_mstate_sect_validate(struct adf_mstate_mgr *mgr) end = (uintptr_t)mgr->buf + mgr->size; for (i = 0; i < mgr->n_sects; i++) { - uintptr_t s_start = (uintptr_t)sect->state; - uintptr_t s_end = s_start + sect->size; + uintptr_t s_start, s_end; + + /* The section header must be in the buffer before it is read. */ + if ((uintptr_t)sect < (uintptr_t)mgr->buf || + (uintptr_t)sect > end - sizeof(*sect)) { + pr_debug("QAT: LM - Section header out of bounds (index=%u) in state_mgr (size=%u, secs=%u)\n", + i, mgr->size, mgr->n_sects); + return -EINVAL; + } + + s_start = (uintptr_t)sect->state; + s_end = s_start + sect->size; if (s_end < s_start || s_end > end) { pr_debug("QAT: LM - Corrupted state section (index=%u, size=%u) in state_mgr (size=%u, secs=%u)\n", -- 2.53.0