From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 997FB3E7BCA for ; Thu, 13 Aug 2026 22:18:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786659481; cv=none; b=tg+J8soLhWAwj6Lth7ZMyAewUfZqtmkhGe8PW1iDLDvXcX2RFOclZFbFBuhsEZmOOZc9UlpJD+pQUUKO+IbioETxKWAsF7P6iuiyTVK7cKJFLJ6xf7H2Ana9l0xir9OJb7fIqvQk8UhTJg8xCeqUE5btkLXSiYEHoozq9upJKiM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786659481; c=relaxed/simple; bh=Fx11ZzcEMDx+XWvgLsyL/NzaNa77kctud5tY5T/YvMU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BATk2FqVFW1tLSlvuH5NXUpoaTvbgT7NbFqvAlfUo0VTOftmKo5j31Knb0AIV0VQv5mjpRHZzzG+G5t7m+twpsNRAaA5iPVsSRRNpFfTMPKRg+x9nePW7+Bfx+AimX02Hfup2yQFrpeePwAzJ9EUoFj9M6erMZ5JkfbM/w1oR0U= 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=DgyAGMgu; arc=none smtp.client-ip=209.85.214.182 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="DgyAGMgu" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2cacf197759so6905605ad.2 for ; Thu, 13 Aug 2026 15:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786659480; x=1787264280; 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:content-type; bh=6kwzuj7mx25GPpnRY6pHNhOgcyjHMHZYoHK7gFZt5W0=; b=DgyAGMgucPEotkq2lpIAYvp06ZAK2t16lOcL+r2uXDhrKPpabmI5d68w3+t0D4iXbj /F95tQUB33RAhm7vhszOYNNfpf0uX0cLNn7UwgP2X/mUFWFZknSVQztEyzMJAPNlEYLE o4JuheHbQNRxJxFEUB83uVFK3YWttT+ypyX/sVSBJtke7CB28j1bUIvi6i4Gh09lqMSK pOrDwHpsgnWY/Nz7im306L/YZlqGalki3gu8NXaSA/btw8ONv+Pgp86fPgu7wklJp2Cy 117pwgPycO/zWWQuoG0fr7ReEOWRAEr7aov/MIJ+xWWyRQzTmkl4SJaCgPpxWJ7XU59s F8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786659480; x=1787264280; 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:content-type; bh=6kwzuj7mx25GPpnRY6pHNhOgcyjHMHZYoHK7gFZt5W0=; b=Gs2vdGvh+4n8xiSF7e5R4HxreBtoTyRQDLCeXigSf0jGIw21eVDOy5mJ+ZhTLMHkNT wGukrN0tNadp2X8ckBGyYZQC6tRfs9FC07ZmwQCsXMmSO3xKhBxbr+FuGKIIC58lph5v bB0tJK2ncfoN70lYru/SBcrAsks2dWUagAW/1Nr7zrpEQwyYe4k2eNTZH0bmvX5HjVy0 O0wwJmP8ZfvjxvWcZdrbBFHLqdkTRj8OLt/kHhvWEeTG6dndHyA3R8WtxuaCxAFiQiZG +FxAHsBvwgrWJVTXFMYbLs1H/ZovKrn3vMTr6BysKVxr4a0/jeceroMTGtdTYD3O7avG 5bXQ== X-Forwarded-Encrypted: i=1; AHgh+RqQ9tDXEvvcMOCr/UnIBomnPKFTsAIN0fOq9g2+qmbBAKI0WV/DYR99fseFLDqLiacjR1Fay1pJHMwopJc=@vger.kernel.org X-Gm-Message-State: AOJu0YzjOXw3O2MIqhqzyDREzqtXcP1nWSRt7W/zaDcaqy/bxPuW1ZIU j6bRwzl6in8cnCD59Zor0cMvzSs/0QwrFbDEPy5sxY8m8Pq6kdTIzjaE X-Gm-Gg: AR+sD103/IHUmWNLNja7u4dru4LWX9yRZe2YTWhGyb+oK40a8hrdunGQPFg1ud7hoNM 9m461W0hKpKxILHjk9GMl13PbVlEotp0tbzAJIxKhIj0Mm6yTI8SOM1fqY+YbtoXta3N6Lwbv4t AINmHe84aN4ijVEC+kKU0dXQY/qr2Yu9w64dBcea5XycvEn+gwT4nD8tNuJ3ScsleDclP4ixVKI TfLRer0u344+pQhNG9sYKrfiWANnY1jp3xGlKMQVYJHDGTVeidjDzUgdopOjiCdt/8cDm4x7Y1l Vs6CCfkaCvA5XYXgjQhLpeZnHG94zzi40vAhuZy35LpuUestSSeAxfm2B7dRnTXim9OeVxWvU4i EluGNguntW8hiziixW+5R7iGRuKtRRAjmApLCcPqq2SUhYtY4EBYuMqmv2wa1NYccfzoTMJAmZs qj4Z+8hOLzuZTum0cs4GVqxm3meA97WjzwUkxmH1FZEXLHSiqIhJ/VeK5lcMI7YKaZVLIVIfsLW KgQMK7UHvRBvk1wNS4= X-Received: by 2002:a05:6a21:2d4b:b0:3b2:a809:ffe with SMTP id adf61e73a8af0-3cc71a2d522mr1308747637.14.1786659479811; Thu, 13 Aug 2026 15:17:59 -0700 (PDT) Received: from sonic ([2804:18:167:9e8c:e6b5:fa0:d068:30e3]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31ebc667bfesm11463318eec.2.2026.08.13.15.17.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 15:17:59 -0700 (PDT) From: Hilgad Montelo To: kenneth.t.chan@gmail.com, hansg@kernel.org, ilpo.jarvinen@linux.intel.com Cc: platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Hilgad Montelo Subject: [PATCH v2 3/3] platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[] Date: Thu, 13 Aug 2026 19:17:44 -0300 Message-ID: <20260813221744.25668-4-hilgad.montelo@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260813221744.25668-1-hilgad.montelo@gmail.com> References: <20260813221744.25668-1-hilgad.montelo@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: 8bit acpi_pcc_retrieve_biosdata() rejects SINF packages only when pcc->num_sifr is strictly less than hkey->package.count, then unconditionally writes a trailing sentinel at pcc->sinf[hkey->package.count]. But pcc->sinf[] is allocated with exactly pcc->num_sifr elements (valid indices 0..num_sifr-1), so that write needs num_sifr strictly greater than package.count to stay in bounds -- num_sifr == package.count passes the existing check but still overflows by one element. This is exactly the case probe()'s existing num_sifr++ workaround ("Some DSDT-s have an off-by-one bug where the SINF package count is one higher than the SQTY reported value") is written to accommodate: when a DSDT's SINF package count equals SQTY+1, the workaround makes num_sifr equal to package.count, which is precisely the boundary that overflows here. Found via UBSan (array-index-out-of-bounds) on hardware where HKEY.SQTY returns 37 and HKEY.SINF()'s package has 38 elements: num_sifr becomes 38 after the += 1 workaround, the loop correctly fills indices 0..37, and the sentinel write then targets index 38, one past the end -- a silent 4-byte heap overflow on kernels without CONFIG_UBSAN. Tightening the rejection check to num_sifr <= package.count would avoid the overflow but breaks probe() entirely on exactly this hardware, since num_sifr == package.count is the case the off-by-one workaround exists to support. Nothing else in the driver reads this sentinel value back, so simply skip the write when there is no room for it instead. Signed-off-by: Hilgad Montelo --- drivers/platform/x86/panasonic-laptop.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86/panasonic-laptop.c index 93e6511..9511440 100644 --- a/drivers/platform/x86/panasonic-laptop.c +++ b/drivers/platform/x86/panasonic-laptop.c @@ -476,7 +476,16 @@ static int acpi_pcc_retrieve_biosdata(struct pcc_acpi *pcc) } else pr_err("Invalid HKEY.SINF data\n"); } - pcc->sinf[hkey->package.count] = -1; + /* + * pcc->sinf[] has pcc->num_sifr elements (valid indices + * 0..num_sifr-1). On DSDTs where SINF's package count equals + * num_sifr exactly -- the off-by-one case probe()'s num_sifr++ + * already allocates a spare element for -- there is no room left + * for this trailing sentinel; nothing reads it back, so just skip + * the write rather than running one element past the flex array. + */ + if (hkey->package.count < pcc->num_sifr) + pcc->sinf[hkey->package.count] = -1; end: kfree(buffer.pointer); -- 2.53.0