[{"id":3688169,"web_url":"http://patchwork.ozlabs.org/comment/3688169/","msgid":"<20260508052312.E8516C2BCB0@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T05:23:12","subject":"Re: [PATCH v7 06/24] PCI/sysfs: Add static PCI resource attribute\n macros","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n- [Critical] The `pci_dev_resource_io_attr` macro leaves the `.size` field of the binary attribute uninitialized (0), disabling VFS bounds checking. This allows arbitrary offsets that truncate on 32-bit architectures, enabling read/write access to arbitrary I/O ports.\n- [High] The `pci_dev_resource_io_attr` macro conditionally omits the `.llseek` callback on architectures without I/O mmap support (like x86 and arm64), causing `lseek(SEEK_END)` to incorrectly return 0 for I/O BAR sysfs files.\n--\n\ncommit 2bb0cfc5ea48584962711dffb2f762f594fd8374\nAuthor: Krzysztof Wilczyński <kwilczynski@kernel.org>\n\nPCI/sysfs: Add static PCI resource attribute macros\n\nThis patch adds macros for declaring static binary attributes for PCI\nresource files, setting specific callbacks based on the resource type.\nIt conditionally includes mmap support for I/O BAR resources based on\narch_can_pci_mmap_io().\n\n> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c\n> --- a/drivers/pci/pci-sysfs.c\n> +++ b/drivers/pci/pci-sysfs.c\n[ ... ]\n> @@ -1197,6 +1197,47 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,\n>  \treturn pci_resource_io(filp, kobj, attr, buf, off, count, true);\n>  }\n>  \n> +/*\n> + * generic_file_llseek() consults f_mapping->host to determine\n> + * the file size. As iomem_inode knows nothing about the\n> + * attribute, it's not going to work, so override it as well.\n> + */\n> +#if arch_can_pci_mmap_io()\n> +# define __PCI_RESOURCE_IO_MMAP_ATTRS\t\t\\\n> +\t.f_mapping = iomem_get_mapping,\t\t\\\n> +\t.llseek = pci_llseek_resource,\t\t\\\n> +\t.mmap = pci_mmap_resource_uc,\n> +#else\n> +# define __PCI_RESOURCE_IO_MMAP_ATTRS\n> +#endif\n\nOn architectures where arch_can_pci_mmap_io() is false (such as x86 and arm64),\n__PCI_RESOURCE_IO_MMAP_ATTRS evaluates to empty, meaning .llseek is left as\nNULL.\n\nSince these are static attributes, their .size field defaults to 0. When\n.llseek is NULL, sysfs_kf_bin_llseek() falls back to generic_file_llseek().\n\nBecause the inode size is 0, will lseek(fd, 0, SEEK_END) incorrectly return\n0 instead of the actual resource length, potentially breaking userspace tools\nlike pciutils?\n\nShould .llseek = pci_llseek_resource be defined unconditionally to ensure\nthe correct dynamic resource length is computed?\n\n> +\n> +#define pci_dev_resource_io_attr(_bar)\t\t\t\t\t\\\n> +static const struct bin_attribute dev_resource##_bar##_io_attr = {\t\\\n> +\t.attr = { .name = \"resource\" __stringify(_bar), .mode = 0600 },\t\\\n> +\t.private = (void *)(unsigned long)(_bar),\t\t\t\\\n> +\t.read = pci_read_resource_io,\t\t\t\t\t\\\n> +\t.write = pci_write_resource_io,\t\t\t\t\t\\\n> +\t__PCI_RESOURCE_IO_MMAP_ATTRS\t\t\t\t\t\\\n> +}\n\nBecause the .size field of this static bin_attribute is uninitialized (0),\nVFS bounds checks in sysfs_kf_bin_read() and sysfs_kf_bin_write() are\ndisabled.\n\nIf an arbitrarily large 64-bit positive file offset is passed via pread(),\ndoes this offset truncate on 32-bit architectures?\n\nLooking at pci_resource_io():\n\nstatic ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,\n\t\t\t       const struct bin_attribute *attr, char *buf,\n\t\t\t       loff_t off, size_t count, bool write)\n{\n#ifdef CONFIG_HAS_IOPORT\n\t...\n\tunsigned long port = off;\n\t...\n\tport += pci_resource_start(pdev, bar);\n\n\tif (port > pci_resource_end(pdev, bar))\n\t\treturn 0;\n\t...\n}\n\nCould a 64-bit offset be crafted such that when truncated to 32 bits, it\nbecomes a negative value that exactly offsets pci_resource_start(pdev, bar)?\n\nThis would cause port to wrap around to a targeted port value.\n\nSince the upper-bound check against pci_resource_end() would then pass,\nand there is no lower-bound check, does this allow reading or writing any\nphysical I/O port between 0 and pci_resource_end?","headers":{"Return-Path":"\n <linux-pci+bounces-54223-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=N3j20pBc;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-54223-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"N3j20pBc\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBcwC6pfJz1yJq\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 08 May 2026 15:23:23 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 985D1300B551\n\tfor <incoming@patchwork.ozlabs.org>; Fri,  8 May 2026 05:23:15 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 82A5B330644;\n\tFri,  8 May 2026 05:23:13 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 6051470809\n\tfor <linux-pci@vger.kernel.org>; Fri,  8 May 2026 05:23:13 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id E8516C2BCB0;\n\tFri,  8 May 2026 05:23:12 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778217793; cv=none;\n b=Ac+YPkl2lzcObIb+l6padTNKFD5atS0VqKe1VEUPljWi+KjA0NlxVDeVXXtMrf+Sez/GQEqIiA62UvNXr9VTmJN5gpLf9a6j+Q4oaQDDjLrcgTjjkygVVzoL+22dAXD6HyyWZ6VEfWRyqiMteIOZT+wkewk5loWG4sEnRErFLXY=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778217793; c=relaxed/simple;\n\tbh=azlnMnzy8lNPSFJ8Qfc6i1xtogdTTZRo8Lln1Dvg4T8=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=FJ5MfkvYWUkrv458nmTcbcbXbTVoSj1TbXC3cxhLJcCS3dy+AYUgNKXFW8Z2MuDWnbCX/f8nt3x2qaYAxJv7Is+jXXyUZ63j0EjpBQ1soxwYjNDEw6su6l01P1TXvmgD6sLkaOu19RKmWqkaCx8x7pfj7CYsPrRI4uU3uWN/rOQ=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=N3j20pBc; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778217793;\n\tbh=azlnMnzy8lNPSFJ8Qfc6i1xtogdTTZRo8Lln1Dvg4T8=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=N3j20pBc02pewEi1UZXiNcyYwGFZt2I006UwIn3ijkcFjjLRDS0pjqWRUZ6KThaAW\n\t Ju+y9JULoNgzzEzNhAt+/JoGcOzGon+VyEg45nHcKMN9RgqnOaibQENw3LT7iastH+\n\t wGCydmNvRF0IWwWt+VLRV15js/2nxiYhlJhGttJYj8pUrC33QyRC6QEppVqTh6ImRr\n\t GGM6vWFXxvWgEK6CsTz+6HnTeVKl/QbajFlCEAbvD6AyWpF9w/qkewPMBYGq4a3hz3\n\t r8xxPVzvBBSSaqWLuy5JxGWuxcZPKcidlVL5MMdx6bj4Qa24hYhdXX+9eEGG8TIgNj\n\t JmHUsbsLXHZMA==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v7 06/24] PCI/sysfs: Add static PCI resource attribute\n macros","Reply-To":"sashiko@lists.linux.dev","To":"=?utf-8?q?Krzysztof_Wilczy=C5=84ski?= <kwilczynski@kernel.org>","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508043543.217179-7-kwilczynski@kernel.org>","References":"<20260508043543.217179-7-kwilczynski@kernel.org>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 05:23:12 +0000","Message-Id":"<20260508052312.E8516C2BCB0@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>"}}]