From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 430AF37D126 for ; Wed, 20 May 2026 07:50:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779263402; cv=none; b=roBPOSrMwxzAJzOzb9vaAkICwdSt1rP2M/9rsRamkWg1DQxhYyoCpLEOdiZYw3AF7+IVQSwdhofedvn/kM+qGLcS0gEvOwKFmJr1KbOWmDGDScdt9XatO4giEEgGo15JXn4Pu17t51c8Op8+idMu4XdRRzlBHYzE6ebJnEDB09Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779263402; c=relaxed/simple; bh=BnIfkijOqhETRqAvk4NXBGnVXN/QWwu0koX8lwy3/tM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ViyDc4u7eqmfGA/F0nuVYkCxtqFVz/ns1qr+54BZuXTHFNjuuQ/VdZ211Gid88Br9Y2UdHNZGxbXfg7+wPFaNUVYSUGpXp7j6RZC8Ma5Xrj61X/bRClXHtWR8HbYjlKP4gb/7re3qYWgUBsG+myJ8l905DXjanIMyIIh8sKhFZE= 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=kFFkTIw1; arc=none smtp.client-ip=209.85.128.45 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="kFFkTIw1" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48e82c23840so36476355e9.3 for ; Wed, 20 May 2026 00:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779263400; x=1779868200; 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=qZWSaEiPka45nin0aHf92f+9R1duVlyTxQYhDwK6lTc=; b=kFFkTIw1ndqYmpcDXM006kvjfbXWH2bTlIUC8TJTUqKrqXunB2sec/fq/2RNZIZEKd 5Z/qKu5TQYvEpxfoz2MIBfVJ5oUtb8wHwOVwzoiuUqgsO3VK2RyCaQbAEiAReXfkbCyz JIJ2MJq1KAG9RMhEfW4xNqAOHtbXUsunLjcVqbwxfOvmxkGY4YU8m8pQBUiJIBPRwvjL NiHqT3Ky6hh6UQX3z0Z8zYb7Uh3T64WJrnXqNhR0R1eeX7JCeBFhln43w2guVlwAZWQ/ ThbRD3aQ+QnAjhJqfm7VImCwcc6XSHSRyYcYIWtIAP1cMgO9IyYjZHSvaO1ldhv1JkM9 55sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779263400; x=1779868200; 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=qZWSaEiPka45nin0aHf92f+9R1duVlyTxQYhDwK6lTc=; b=JzBhf+/Wi4pLH4DyU0XwnrAzn0l7CO1bsV9+l/oY+JVY55znaffB+yjv1PyrmrDcki Aq33fHdQLXQME6CfgdnAgNcOVlONFPf7DyfVvmS3ApPKDjfL5Og2wuuRFOusRawUx6k9 hTUuKvUNR+UcZ33+IBx16Aljgfp815v9p9s5rRlh78OmxpdU7ZooC9jFl2x7M+KnVF+w pwG7sY2Pj/1BVI29rNMe/WiGZwhFJMynSQRuqRW/22jznWnAynjBNRoyYBbvX3Psn8zl vJmz8t+u9TlS/cvx/xsOh1OiVfXXjmJoUIzog8gZAkNhg7mnwV835S8UKn6Ow2ZD++ng Lh7Q== X-Forwarded-Encrypted: i=1; AFNElJ9/zrnkGPFvUWOG157N7WfMtd4+EwEp3Gt+U3Nb0dg7ccEm4PQRFfYZArlPaqOBhL0In6dFneodWKHexfE=@vger.kernel.org X-Gm-Message-State: AOJu0YzwlbOiDedTV54V1CVigWyGWQTdkcB59RBVoYo7n92JwZ1R9mpX tTlySlbfwMx7vnn9BtyOpkUF7HB9b6AeIFe+ogU0XLK+AWISp1zLZLaTnSdMKTBW5bw= X-Gm-Gg: Acq92OHi1nNiQloQ3HeSmg88fb1XF7lpcz9hyPjZIVXbqs/TnHO9nqFHfU4Y1fEu++b vClF1QS5eHW+MLnkprn7ycdPyxhoWcpSy5q/iNnYVrrDi5QzGk+4C4LnCD543vG86J1lN3SHLnh H/DqOYLbCLdTVPIGV4C+iNPFCI40U8iiiFQMmxQN7BaZ0h9w08mbIjedydOayaLEIVq2jf2xqcv 4OvtV1aTb+gCm2kSiiIvOzndj8LGUrFLtE/uIzlOLuXWaHM0Uf2xsoVUptyuwp6kBD2FHb3jZoc cqz9R85MRrY3E/JrKfOopcxhJvHUQOHQPjq/H47KqlIcvKvhdskY99YX3fCe7Wod/7gKPNbYM1i cHzohB3eidjI55dcyv9Da00BAmPPdTBRPjVKG7KfU5iT4jDN0jlYy9Xdujdio8BWrMSQHpRgFjX TapOJnbaQ19lhwH7ogLCE= X-Received: by 2002:a05:600c:5247:b0:48f:d1b8:9aa0 with SMTP id 5b1f17b1804b1-49007bdff16mr199799125e9.7.1779263399515; Wed, 20 May 2026 00:49:59 -0700 (PDT) Received: from G614PR ([2a01:e11:202b:40:328e:213e:a3da:580f]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fffb9aac4sm496536215e9.9.2026.05.20.00.49.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 00:49:58 -0700 (PDT) From: "Marco Scardovi (scardracs)" To: andriy.shevchenko@linux.intel.com Cc: brgl@kernel.org, linusw@kernel.org, linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, mika.westerberg@linux.intel.com, mscardovi95@gmail.com, westeri@kernel.org Subject: [PATCH v3 0/2] gpiolib: acpi: Fix bounds-checking and connection leak Date: Wed, 20 May 2026 09:45:45 +0200 Message-ID: <20260520074955.55443-1-mscardovi95@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Andy, This new series addresses two issues in the ACPI GPIO library while trying to address your feedbacks: 1. Adds robust bounds checking for pin resource indexing when requesting owned descriptors and querying wakeup/interrupt pin configurations. 2. Fixes a connection/descriptor leak in the OpRegion address space handler and handles connection rollback in a transaction-local list to avoid wiping successfully established connections. Please note that some of these changes were found during a personal follow up analysis before submitting the patches to the community. They are reported to explain why some of these fixes are made in that way instead of another. Changes since v2: - Fixed a global over-cleanup bug in the error path of the handler, which incorrectly wiped the whole persistent connection list (achip->conns). We now use a temporary local list_head (new_conns) inside the handler to log and rollback only the connections requested during the current transaction, and splice them into the global list only on success. - Renamed the global connections teardown helper to acpi_gpiochip_free_all_connections() to clearly indicate its scope. - Fixed a potential concurrent connection duplication race in the handler using an optimistic double-check allocation retry pattern. - Introduced the acpi_gpiochip_find_conn() helper to reduce lookup code duplication. - Changed the subject prefix of Patch 2/2 to "Fixes: gpiolib: acpi: ...". Changes since v1: - Reworked bounds checking in acpi_gpio_adr_space_handler() to validate that the requested pin range [pin_index, pin_index + bits] remains within bounds of the ACPI resource pin table, returning -EINVAL instead of silent truncation. As always I'll wait for your precious feedbacks Assisted-by: Antigravity:gemini-3-flash Signed-off-by: Marco Scardovi Marco Scardovi (scardracs) (2): gpiolib: acpi: Add robust bounds-checking for GPIO pin resources Fixes: gpiolib: acpi: resource leak in OpRegion drivers/gpio/gpiolib-acpi-core.c | 157 ++++++++++++++++++++++++++++++--------- 1 file changed, 122 insertions(+), 35 deletions(-) -- 2.54.0