[{"id":3677190,"web_url":"http://patchwork.ozlabs.org/comment/3677190/","msgid":"","list_archive_url":null,"date":"2026-04-14T13:01:50","subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","submitter":{"id":93088,"url":"http://patchwork.ozlabs.org/api/people/93088/","name":"Marco Nenciarini","email":"mnencia@kcore.it"},"content":"Gentle ping on this. It is a one-line bounds check fix for a real\nUBSAN splat triggered when config space reads return 0xffffffff\n(device fallen off the bus).","headers":{"Return-Path":"\n ","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=fail reason=\"signature verification failed\" (1024-bit key;\n unprotected) header.d=kcore.it header.i=@kcore.it header.a=rsa-sha256\n header.s=spark header.b=dbmnzrmi;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52488-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n header.d=kcore.it header.i=@kcore.it header.b=\"dbmnzrmi\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=49.13.27.68","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=kcore.it","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=kcore.it"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4fw4HH5bSPz1yDF\n\tfor ; Tue, 14 Apr 2026 23:04:27 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 194D930469AD\n\tfor ; Tue, 14 Apr 2026 13:02:11 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5EF0B3E6DCC;\n\tTue, 14 Apr 2026 13:02:10 +0000 (UTC)","from spark.kcore.it (spark.kcore.it [49.13.27.68])\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 2286A1DF254\n\tfor ; Tue, 14 Apr 2026 13:02:08 +0000 (UTC)","from mnencia by spark.kcore.it with local (Exim 4.96)\n\t(envelope-from )\n\tid 1wCdOo-007jUY-2y;\n\tTue, 14 Apr 2026 15:01:50 +0200"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776171730; cv=none;\n b=RwB3eW77brm39AW8RltEdy5yh3/lReiX6B7wTwczs0QE8dS+2ETdwn+aEETkXsSqLaYXbTtW6DnK//lwletaNGV7oZr4YzANa2hU2MbtuDL+SQAAca9l1/mX7495hyZUyjREXBLuwh2XAPxeWam7duUIBIHxS9b7HxyKIks0tYg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776171730; c=relaxed/simple;\n\tbh=NPx9iUzmfbfaFnFGts8y+q3gUOSzLlHGkd3Wr0x9A70=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To:References;\n b=W3KhGpms1nAwmuwsGQx5npDUaf/6jlVk+zIv5dD16tIg5dnL51EQmnoifniDEwGxGtQWB6qgegpzlCXCZCxI2t1Fg6NDC/BAy5R+3K7Vl62hn0LsyF/i5/6uFIEJEm2IPYM2cebyxsmtErD7yP+eI2+UEtuOsZs7VLZ5bJLYtG0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=kcore.it;\n spf=pass smtp.mailfrom=kcore.it;\n dkim=pass (1024-bit key) header.d=kcore.it header.i=@kcore.it\n header.b=dbmnzrmi; arc=none smtp.client-ip=49.13.27.68","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kcore.it;\n\ts=spark; h=References:In-Reply-To:Content-Type:MIME-Version:Message-ID:\n\tSubject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:\n\tContent-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc\n\t:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:\n\tList-Post:List-Owner:List-Archive;\n\tbh=NPx9iUzmfbfaFnFGts8y+q3gUOSzLlHGkd3Wr0x9A70=; b=dbmnzrmiotaD+mLk6QDge0Kzp8\n\tciDLbZYAUzvSRJqRBJ5mksudC1olTZy0JWHH69m2i6INLiu3UpTD9UlAc8smCfVHCRXHyI6xoLlHE\n\ttV5SctpNEgg9jVQ2Tpb80dMzc58voo2zBrQgob5RMTC+eC3scvRB3h8BjvzsWpkJ/aUw=;","Date":"Tue, 14 Apr 2026 15:01:50 +0200","From":"Marco Nenciarini ","To":"bhelgaas@google.com","Cc":"michal.winiarski@intel.com, ilpo.jarvinen@linux.intel.com,\n\tlinux-pci@vger.kernel.org, mnencia@kcore.it","Subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","Message-ID":"","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260408163922.1740497-1-mnencia@kcore.it>","References":"<20260408163922.1740497-1-mnencia@kcore.it>"}},{"id":3677209,"web_url":"http://patchwork.ozlabs.org/comment/3677209/","msgid":"","list_archive_url":null,"date":"2026-04-14T13:34:07","subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","submitter":{"id":83080,"url":"http://patchwork.ozlabs.org/api/people/83080/","name":"Michał Winiarski","email":"michal.winiarski@intel.com"},"content":"On Wed, Apr 08, 2026 at 06:39:22PM +0200, Marco Nenciarini wrote:\n> sriov_restore_vf_rebar_state() extracts bar_idx from the VF Resizable\n> BAR control register using a 3-bit field (PCI_VF_REBAR_CTRL_BAR_IDX,\n> bits 0-2), which yields values in the range 0-7. This value is then\n> used to index into dev->sriov->barsz[], which has PCI_SRIOV_NUM_BARS\n> (6) entries.\n> \n> If the PCI config space read returns garbage data (e.g. 0xffffffff when\n> the device is no longer accessible on the bus), bar_idx is 7, causing\n> an out-of-bounds array access. UBSAN reports this as:\n> \n> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51\n> index 7 is out of range for type 'resource_size_t [6]'\n> \n> This was observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell\n> off the PCIe bus during a failed GC6 power state exit. The subsequent\n> pci_restore_state() call triggered the UBSAN splat in\n> sriov_restore_vf_rebar_state() since all config space reads returned\n> 0xffffffff.\n> \n> Add a bounds check on bar_idx before using it as an array index to\n> prevent the out-of-bounds access.\n> \n> Fixes: 5a8f77e24a30 (\"PCI/IOV: Restore VF resizable BAR state after reset\")\n> Cc: stable@vger.kernel.org\n> Signed-off-by: Marco Nenciarini \n\nReviewed-by: Michał Winiarski \n\nThanks,\n-Michał\n\n> ---\n> Cc: Michał Winiarski \n> Cc: Ilpo Järvinen \n> \n> drivers/pci/iov.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c\n> index 00784a60b..521f2cb64 100644\n> --- a/drivers/pci/iov.c\n> +++ b/drivers/pci/iov.c\n> @@ -946,6 +946,8 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)\n> \n> \t\tpci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);\n> \t\tbar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);\n> +\t\tif (bar_idx >= PCI_SRIOV_NUM_BARS)\n> +\t\t\tcontinue;\n> \t\tsize = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);\n> \t\tctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;\n> \t\tctrl |= FIELD_PREP(PCI_VF_REBAR_CTRL_BAR_SIZE, size);\n> -- \n> 2.47.3\n>","headers":{"Return-Path":"\n ","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=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=coVfWLw+;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52490-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"coVfWLw+\"","smtp.subspace.kernel.org;\n arc=fail smtp.client-ip=192.198.163.18","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw50N6tbPz1y2d\n\tfor ; Tue, 14 Apr 2026 23:36:36 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 55644302FA93\n\tfor ; Tue, 14 Apr 2026 13:34:21 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E9E742DB79E;\n\tTue, 14 Apr 2026 13:34:20 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.18])\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 899AE2C21C7;\n\tTue, 14 Apr 2026 13:34:19 +0000 (UTC)","from fmviesa004.fm.intel.com ([10.60.135.144])\n by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 14 Apr 2026 06:34:19 -0700","from orsmsx902.amr.corp.intel.com ([10.22.229.24])\n by fmviesa004.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 14 Apr 2026 06:34:18 -0700","from ORSMSX901.amr.corp.intel.com (10.22.229.23) by\n ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37; Tue, 14 Apr 2026 06:34:18 -0700","from ORSEDG901.ED.cps.intel.com (10.7.248.11) by\n ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37 via Frontend Transport; Tue, 14 Apr 2026 06:34:18 -0700","from DM5PR21CU001.outbound.protection.outlook.com (52.101.62.4) by\n edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37; Tue, 14 Apr 2026 06:34:15 -0700","from DM4PR11MB8132.namprd11.prod.outlook.com (2603:10b6:8:17e::13)\n by CO1PR11MB5124.namprd11.prod.outlook.com (2603:10b6:303:92::12) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9818.20; Tue, 14 Apr\n 2026 13:34:10 +0000","from DM4PR11MB8132.namprd11.prod.outlook.com\n ([fe80::22f3:a01e:fb45:57ac]) by DM4PR11MB8132.namprd11.prod.outlook.com\n ([fe80::22f3:a01e:fb45:57ac%3]) with mapi id 15.20.9818.017; Tue, 14 Apr 2026\n 13:34:10 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776173660; cv=fail;\n b=i4F+QsOUn/LTEXzVJR6o21W89gJUjXY+mCgtEp2EsnKkO5xajkHTUvT5M6TmNkIJ+SaUujxVOZitQfFoa+9uVj9E+1MIb4+qMuZAYtvkhPQd2gXpbe4LyJXYTJdLSjNczmm72CM5Hli0DbHUWSoSA/JMKQ+F2m68ajeOuO1+/6I=","i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=gOrpHvvt2n9EO6sDjhB73BWY1Ja0uESJUthwSQX/g1AB62s0EtgvmPalmfnzoQ9Pa9Qizg+5tkLz+u2Agc6p5p5sfL1sc+sHSI1AVxzdOE/ynnt5aUBhZPRhoARXW7Xtni+pN3FP6I+B+SKOglBTAwFQ9eczT5xLamwA2ylG0eN7h0VIaWPzmy3wRU7YJHjFxo4XjjcrrdCAk03pLpmIv1hhNXj8QNu/623VHLQgi3amaJjw+NORO+uU46blKVUFQ0Tuo5WoN5FbN4ewzgb5dx4MAQBqHXkJXbhnRPKkGeFwF7FhAG6tg0LjK377Xg5zkOnFaN/Eac9wGsn6hZ8Ggw=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776173660; c=relaxed/simple;\n\tbh=L2odwwDrFjWmizRr8fbGfaNx5nbRKiU9pwiTT3Vht8s=;\n\th=Date:From:To:CC:Subject:Message-ID:References:Content-Type:\n\t Content-Disposition:In-Reply-To:MIME-Version;\n b=TEL+/GbCxCjSwYtZeOccIBNiJ3HDNhsU4KdMxuBxUyLO3iiRtPu03MZRSUVrY38RXC7tPImOIJW3r9pNo5QNFFNJI1FxTThQ4nzHSe1cLET/sm/tPL0RPTVrTLiBJ0Rhq7/GQzDKmm+vc1p8vlhuKqEm5i9ET5LDUuRTSCpX2CE=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=8MxS8TavIgcvDapRVozhlx4bSPTIj/Af4v7GCLAWWMY=;\n b=HPV66UULj4b+04NpWfpL5jE7hlQK9qESgDLoS7Ja672ES3LzCEEtp8xU6kAmEjGCU1dfbyDp+sX5BFDJs5gz/xJZ9eC6+MLOPuP4htCAENg9nGYr57vyIrXDWFCd7cAarPzlfj+NZEtL1GYF4Ahcy+jn8pWTRuNvljhwsBt8hWfB7NhVVsXgGbbVsn7lWaxSyTjfUPaX3A9ilM/E3tY2Zvo3+1dEh0M4vi6GnQN6lDI45h8Eysrq25Oq8BWi6WXP49RBUtl7AeSQh329WRa+HibJ7Tkzes0s+4WoKVycONT1VDUXHXW57KJDbP1VoWniqGt3WZPvM0WsHF/1NNspxg=="],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com;\n spf=pass smtp.mailfrom=intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=coVfWLw+; arc=fail smtp.client-ip=192.198.163.18","i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1776173659; x=1807709659;\n h=date:from:to:cc:subject:message-id:references:\n content-transfer-encoding:in-reply-to:mime-version;\n bh=L2odwwDrFjWmizRr8fbGfaNx5nbRKiU9pwiTT3Vht8s=;\n b=coVfWLw+gy2EG0HZ4YmSiBauQ1o5+HzUUy6lZxM0L/ZOrvpV0bIYD8wQ\n FYl0NaqLJcLyZElEJAQhcuJSvR7O2NYtDu2ZyMBF7qAkxaGLOYnHBX3E4\n Eb0Gx7cFfv+bsvTqG+uQLiln0j/9xjahzQYuZLJTGEA/Vr52YE+1IvG2l\n s/JDQPtS6G12Yuij70vdbaDWzMFF0kpX+9Tuq4KUac1h3QehVFpGL55kU\n NzJIzIoIs1ApYGMa4mVWX3GHF2xq3q4uTx3azwsRXJTeY3WrH1jaZ2QSV\n idISSzQwwQWQwqabeXWVh5c+5fLO2ex4GJ7rUci7VWm57UtTttHSMQTgh\n A==;","X-CSE-ConnectionGUID":["vijBB7rIRh+D98AxH5Cqrg==","Qo7uXF/gQTytNLhet9a0lQ=="],"X-CSE-MsgGUID":["XNSNkfKdQ1y5kMbt/iJc4w==","9K0eViBqQqa9MNDoDe+OxA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11759\"; a=\"76292400\"","E=Sophos;i=\"6.23,179,1770624000\";\n d=\"scan'208\";a=\"76292400\"","E=Sophos;i=\"6.23,179,1770624000\";\n d=\"scan'208\";a=\"231846690\""],"X-ExtLoop1":"1","Date":"Tue, 14 Apr 2026 15:34:07 +0200","From":"=?utf-8?q?Micha=C5=82?= Winiarski ","To":"Marco Nenciarini ","CC":"Bjorn Helgaas ,\n Ilpo =?utf-8?b?SsOkcnZpbmVu?= ,\n , ,\n ","Subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","Message-ID":"","References":"<20260408163922.1740497-1-mnencia@kcore.it>","Content-Type":"text/plain; charset=\"utf-8\"","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260408163922.1740497-1-mnencia@kcore.it>","X-ClientProxiedBy":"VI1PR07CA0284.eurprd07.prod.outlook.com\n (2603:10a6:800:130::12) To DM4PR11MB8132.namprd11.prod.outlook.com\n (2603:10b6:8:17e::13)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"DM4PR11MB8132:EE_|CO1PR11MB5124:EE_","X-MS-Office365-Filtering-Correlation-Id":"9a63bf04-e53b-4701-8472-08de9a2a82bb","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"\n BCL:0;ARA:13230040|1800799024|376014|366016|22082099003|18002099003|56012099003;","X-Microsoft-Antispam-Message-Info":"\n p954aHtoq6Qssnjq1SFFtgGII0S+vUn1Un4XHU09jfN9mfVnZK9GqaO0vg+3zlqI/2yGleucDXIT89pTYkJa15v2c+OoBkEi6RAi8PSiULdgshPZHPIejsfYJJobEEMM1v3FON59qKFkBtKyBujPeCAuCbyOxf+FBxWarcj/p+K6Qemfyi2cDSc0x3coAIyaAncd5dekh74Lwe0Coswcql47x8H7gU9nvYXMAZ5IrUfF9/I8ZcJcLKJB9kO8iXkNAju8n0Xj+GgWHzoZYUZUzFXlTqPbtnU0FRD+3tZMLXU8MEv0ZIlwdC6JzAaDeCk/cLjprUVOzjuiryb8wpkIrtZnMJRqx/lt+kGHQsW2v9nbYedIUrjNEvUVPJCpnBxqoVdmhRZ3LTVwmd+QNYStp3E9JZEvl5dqkYDJ/QVWbpz5weqiRODMpX63plEA5WU5MZe19Cuv2Rwsqlrzq7Em0dhd3xmZ9DKvsdFt8Zi+6AfTGFW2nf8Km0qPOhyWxEY4tGgHpo3163iO1dAtm1UQEDB7Q4R0N8/g8UQaOzyLs4Q+GhWWmOllmKjLZQZPfQKDYhERudgRD/Nf1dZT094fIHvey7XP6dqDxC/jYRmAcdoaBAxmlPYR7lrBN4N04tlXqPvc4tsbxlKB7Ejd/+PQ0aYH4EC3WPIMavnzIZMnpAE5ccbGpCmKwaeSxT54wwBemHTKrgtKAwRi0TQBVld7Cn6KnqT2Blad2Hae3LfNjNs=","X-Forefront-Antispam-Report":"\n CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB8132.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"=?utf-8?q?bsclw/DnrcV4aUImImHeV6b9BKsS?=\n\t=?utf-8?q?azDVQPDbARdYXP74REBS6yu9/z/IuSKUisGU/thoEhlViVUD4wTd+UhTZY0ma0ZA/?=\n\t=?utf-8?q?M8zpe7FBGCdyM+keQ/3m2De4Q0fZQUa5M+14nOmU0US3YG/qPg+ybpmkjfjWMWsBj?=\n\t=?utf-8?q?ca0J2kI92r2HP+Dk2AYLxtNBojvofLoN8UFuHRUDfCszcu8pQ1Fwt1KLG4Za3KZya?=\n\t=?utf-8?q?yA7pYT7XF8Pq4RhxE/8rSr3+DvxuL/53A2pgBnIIe1WyI/5JqO8q6OVqkLXIAl93x?=\n\t=?utf-8?q?XjLC9I5mK0/cli7/ptbbXQJ2SYFUT5NMWfrOQ//C8+QLjBcOKIBb9skzA3h3VOJRD?=\n\t=?utf-8?q?3/i3FYap7y2GU37DXj6h1sphQgYZawDmrOH8lS0tVHB63EtLFC+UKjqoLMashTTDk?=\n\t=?utf-8?q?eT0E5NOPiC6b4ns209TCkOkwC++RmtUcLdlEg92esX2fzrOOTo+jQ+MfXNgXf7wYT?=\n\t=?utf-8?q?R86pljIri5pmDf3PnEjnIxDild2xUQzHeZPwxBRnxt9Zcp8PZFvgmuBH8L7+U+8+9?=\n\t=?utf-8?q?MBZWqedRyWZ9EJDl2CkCKZ1QVbfOEv+q2n9TQh6ZpqtCDHChhw1D/GvdI4mI9xwif?=\n\t=?utf-8?q?5grcNA6xoMCi95yTaih/BMRf4pjBS0gMGl+INiSHe0OsrVmvo0p4Sv44iMVg1Q1Lx?=\n\t=?utf-8?q?F4EFRemGdsoU+y4S1ZRY2BWtuMaipADBdV2YoMowOk+ALkTRSYg2MrmX+qhJJjffd?=\n\t=?utf-8?q?JwxGDy4xHi8AjrNAzrc1+VS+oQfXTVUI6I+04cOYkUVkQ40v6wZ38zZ+Aef0dumuH?=\n\t=?utf-8?q?JiFwAUossH0PGpaXXkncDl4dX2ypP1yYPT8+AyuMDdZuoOHABmdDrzUuvVknSaHAI?=\n\t=?utf-8?q?lsz8HN7ZZUL6DooQzCm/WC1gdtDIykBMqwoaTJ3Ww5qt3qL2U0nD/bCyqVtUIvYkh?=\n\t=?utf-8?q?ZqWC80IKGcDGHA2izJ+U5sCVvHegQgBLsAPbJi+bKACpqRnHEqFOU9KTHS4LScRZY?=\n\t=?utf-8?q?nwvfZOo89QAgP5hQD3h4FpMe7mZgZTlvvLP4KtWRbcl6jfW9v2abjKyUn69G3QDno?=\n\t=?utf-8?q?snLV6IVOuPYQihvnA6LGXuf2hEyR2lMy0My4s7Y18JS8JdpbrmEZSl21SP8zAcV8+?=\n\t=?utf-8?q?hzKmn/IPH7I5dyLEnXs0HDM83ZByjOKgOf2YdnQg10tqTgsa/ntRt7gnwVlo9D0m5?=\n\t=?utf-8?q?I8eql+jJxdPeMXBY1hnTVhZg29ajs6UcZiqpA1JffPU+LTgjWb2nZyCANLBEbFuDR?=\n\t=?utf-8?q?bVu51I11m2Q92bzgJEQpJowsG4sSNKSEvJLWyStLijofPIoWh5jRlNxxIErxU+LpT?=\n\t=?utf-8?q?M2s2JlPKaZdo+7FlJ5Ys4LszhUgLxsrhioWnISZ39Woj2zH7+dpuq1JP0qndAWEF5?=\n\t=?utf-8?q?ds1rbi5F/z4G/Aw5OXrzvcYvC2+9gFRmiZNqTVRiigjwRcXDWOO21vavx8yLYA5UB?=\n\t=?utf-8?q?74viKw8ymv/w8MEtBgvem31a9bv88/mvxJE0n2A8rfvIiCKM27xvKGU6Dy2QDHTk8?=\n\t=?utf-8?q?JTxR+P3Lou/vRYMY/OmhspqzxFox3juVp+nEQSTkvuEUwfocCy+04jE9cwX5Q2Ki7?=\n\t=?utf-8?q?aZQQJathz8FiqBAOm6PCzWln31eUujkyCno+zfcPZuyN8OxF9Dog0+fYPsSODUaQM?=\n\t=?utf-8?q?4SaF8Oot8GJuSiWnG9pX74h65ouzXQynrDKGCsMUWxtm1HGwrxH7CcketlOkUo2nU?=\n\t=?utf-8?q?XUbNvJbCL9p727L1cCmET4bHuYRr/2zP90kvRvT5MwGix0VrXc8QY=3D?=","X-Exchange-RoutingPolicyChecked":"\n JFGBwFGrCV6prxHHOfnHOgNpdoDjnI8MuwUra39GRoY1j7bQbHS+hXq4G+J8vXuPKrFw0La7iulrK0NH5+GhnTo4oospwtSkj7MxGpjHYcaOwertGf1cGHo/9zICra3rFLCPt9ySIlhxUsJrJ6Jnn9VfQqTYDvYjQlFeTDBId9k3pLiPZ5BTBiaavg5ByaiDa/xoNhF3qYbU13p1OG/7BcAuI7D0FMU9w/EzZoKCa7uT1bj5FoDsMfgE4Bw2aN7qf35hJc/OmGb9EQ6ywQbemWRpYwYeX+8Jv5BBeEERzon5krpx2HWZYlU39k86a4xPo1TOdK2Y41BPCqj8Pg9DUg==","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 9a63bf04-e53b-4701-8472-08de9a2a82bb","X-MS-Exchange-CrossTenant-AuthSource":"DM4PR11MB8132.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"14 Apr 2026 13:34:10.7584\n (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n NgAio0XwAFn5ihWZXYOO5VYH6j3g177obcMCSh/aS28zaNzv9cIEkFcwmnUedtSWC3rWPxoJGvL30ZlbaOIJMOW5nPK4MsGTupNiwwdypUc=","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"CO1PR11MB5124","X-OriginatorOrg":"intel.com"}},{"id":3678416,"web_url":"http://patchwork.ozlabs.org/comment/3678416/","msgid":"<20260416224238.GA35669@bhelgaas>","list_archive_url":null,"date":"2026-04-16T22:42:38","subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Wed, Apr 08, 2026 at 06:39:22PM +0200, Marco Nenciarini wrote:\n> sriov_restore_vf_rebar_state() extracts bar_idx from the VF Resizable\n> BAR control register using a 3-bit field (PCI_VF_REBAR_CTRL_BAR_IDX,\n> bits 0-2), which yields values in the range 0-7. This value is then\n> used to index into dev->sriov->barsz[], which has PCI_SRIOV_NUM_BARS\n> (6) entries.\n> \n> If the PCI config space read returns garbage data (e.g. 0xffffffff when\n> the device is no longer accessible on the bus), bar_idx is 7, causing\n> an out-of-bounds array access. UBSAN reports this as:\n> \n> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51\n> index 7 is out of range for type 'resource_size_t [6]'\n> \n> This was observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell\n> off the PCIe bus during a failed GC6 power state exit. The subsequent\n> pci_restore_state() call triggered the UBSAN splat in\n> sriov_restore_vf_rebar_state() since all config space reads returned\n> 0xffffffff.\n> \n> Add a bounds check on bar_idx before using it as an array index to\n> prevent the out-of-bounds access.\n\nI think pci_restore_rebar_state() has a similar problem: if the device\ndoesn't respond, \"nbars\" will be 7 (legal values are 1-6), and\n\"bar_idx\" will also be 7 (legal values 0-5). We use \"bar_idx\" for\npci_resource_n(), and dev->resource[7] does exist but is not a valid\nBAR.\n\n> Fixes: 5a8f77e24a30 (\"PCI/IOV: Restore VF resizable BAR state after reset\")\n> Cc: stable@vger.kernel.org\n> Signed-off-by: Marco Nenciarini \n> ---\n> Cc: Michał Winiarski \n> Cc: Ilpo Järvinen \n> \n> drivers/pci/iov.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c\n> index 00784a60b..521f2cb64 100644\n> --- a/drivers/pci/iov.c\n> +++ b/drivers/pci/iov.c\n> @@ -946,6 +946,8 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)\n> \n> \t\tpci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);\n> \t\tbar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);\n> +\t\tif (bar_idx >= PCI_SRIOV_NUM_BARS)\n> +\t\t\tcontinue;\n\nBoth here and in pci_restore_rebar_state(), we blindly use \"nbars\"\nderived from a value that might be ~0 because the config read failed.\nIf we fix these, I think we should do something like this so it's\nobvious why we're checking:\n\n pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);\n if (PCI_POSSIBLE_ERROR(ctrl))\n return;\n\n nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);\n for (i = 0; i < nbars; ...) {\n ...\n pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);\n if (PCI_POSSIBLE_ERROR(ctrl))\n return;\n\n bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;\n res = pci_resource_n(pdev, bar_idx);\n\nIt's true that \"nbars\" and \"bar_idx\" *could* still be invalid even if\nthe config read succeeded, but that would be a device defect.\n\n> \t\tsize = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);\n> \t\tctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;\n> \t\tctrl |= FIELD_PREP(PCI_VF_REBAR_CTRL_BAR_SIZE, size);\n> -- \n> 2.47.3\n>","headers":{"Return-Path":"\n ","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=uLds86Cg;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52658-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=\"uLds86Cg\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxY1d04Pmz1yGt\n\tfor ; Fri, 17 Apr 2026 08:42:45 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 0C026305AAA0\n\tfor ; Thu, 16 Apr 2026 22:42:41 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 3A6D7379993;\n\tThu, 16 Apr 2026 22:42:40 +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 148E833262F;\n\tThu, 16 Apr 2026 22:42:39 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 88605C2BCAF;\n\tThu, 16 Apr 2026 22:42:39 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776379360; cv=none;\n b=VXHv2R3EHZvufCdOX+g2xcYU42q5f1a9kYyw5EjzGgPRuwpZpAheT3BqZLlmjjWYOXRAmQgdwM09ETlTewpxkgNMZCOOKTncBMx7AZepnAgDN3IGKgWROWUHOeOboaFziaXejIwXudm2i8L/csFxbk0nzhs6ekqVzHv1upR9Xu8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776379360; c=relaxed/simple;\n\tbh=7Nj+vNpy/vkj8eg2shMUBd4fYul1POhc0Kx6+tca4dg=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To;\n b=MlO1YGNCgJ4rIhfRPG4tvUvLrbbRBsxuULCZljfGKT7S8OwP8p+2wnlxuxdTexum2UxdeJFUJqhwhxsWBM7U8SYOY23piMXBQizGiTVKbaPENZ+kznEx6DR6Xg/5Fqls8DbXXIrAJDUBuxgCA5SDAIP5j3BPTLbCEdj1UwJoREI=","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=uLds86Cg; 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=1776379359;\n\tbh=7Nj+vNpy/vkj8eg2shMUBd4fYul1POhc0Kx6+tca4dg=;\n\th=Date:From:To:Cc:Subject:In-Reply-To:From;\n\tb=uLds86CgS5Y5rcAjyJNrkpZ9/9XG622QV0XIX2b8aIY7YVPowsFIfwdQGbXq+ThGZ\n\t sp/CRJCZRvDYYWl1kYgoNil0IHeHnsnOBoc5h1dCAdjxE+iRl+RVpvcrFkIpeak++8\n\t GdtlvbcTs8tn7seSmFMOwWmTtLVdPk5Dv3hU2aKXqhbnE8+6jBZCCml/0TQRnGesxj\n\t DuJIwQegIGD5RXjoWcYrtrRzRREwrA2xAmcT8rpGkBJR32rE/FjRErLhoq9cVGaDL3\n\t Lt4nRSvCOPFYk/och0L5YRP3yOmcYWLSpAKJWPeJwdpBG8haGPviMpkfB80Rlbft/6\n\t dbSBzOsSqKsiQ==","Date":"Thu, 16 Apr 2026 17:42:38 -0500","From":"Bjorn Helgaas ","To":"Marco Nenciarini ","Cc":"Bjorn Helgaas ,\n =?utf-8?q?Micha=C5=82?= Winiarski , Ilpo\n\t=?utf-8?b?SsOkcnZpbmVu?= ,\n linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,\n stable@vger.kernel.org","Subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","Message-ID":"<20260416224238.GA35669@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260408163922.1740497-1-mnencia@kcore.it>"}},{"id":3678418,"web_url":"http://patchwork.ozlabs.org/comment/3678418/","msgid":"<20260416225745.GA41850@bhelgaas>","list_archive_url":null,"date":"2026-04-16T22:57:45","subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"[+cc Rafael, Eric, Alex, Lukas, generic pci_restore_state() question]\n\nOn Wed, Apr 08, 2026 at 06:39:22PM +0200, Marco Nenciarini wrote:\n> sriov_restore_vf_rebar_state() extracts bar_idx from the VF Resizable\n> BAR control register using a 3-bit field (PCI_VF_REBAR_CTRL_BAR_IDX,\n> bits 0-2), which yields values in the range 0-7. This value is then\n> used to index into dev->sriov->barsz[], which has PCI_SRIOV_NUM_BARS\n> (6) entries.\n> \n> If the PCI config space read returns garbage data (e.g. 0xffffffff when\n> the device is no longer accessible on the bus), bar_idx is 7, causing\n> an out-of-bounds array access. UBSAN reports this as:\n> \n> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51\n> index 7 is out of range for type 'resource_size_t [6]'\n> \n> This was observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell\n> off the PCIe bus during a failed GC6 power state exit. The subsequent\n> pci_restore_state() call triggered the UBSAN splat in\n> sriov_restore_vf_rebar_state() since all config space reads returned\n> 0xffffffff.\n\nI think all of pci_restore_state() is problematic for all devices, not\njust this GPU. If these config reads fail, all the previous config\nwrites probably failed (silently) as well.\n\nAnd we have this weird retry loop in pci_restore_config_dword():\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pci.c?id=v7.0#n1766,\nwhich was originally added by\nhttps://git.kernel.org/linus/26f41062f28d (\"PCI: check for pci bar\nrestore completion and retry\") to fix an actual problem:\n\n On some OEM systems, pci_restore_state() is called while FLR has not\n yet completed. As a result, PCI BAR register restore is not\n successful. This fix reads back the restored value and compares it\n with saved value and re-tries 10 times before giving up.\n\nThis just gives me the heebie-jeebies. If we still need this retry\nloop, it means all the previous state restoration (PCIe, LTR, ASPM,\nIOV, PRI, ATS, DPC, etc.) probably failed, and we end up with a device\nwhere the BARs got restored but none of the previous stuff. That\nsounds like a mess.\n\n> Add a bounds check on bar_idx before using it as an array index to\n> prevent the out-of-bounds access.\n> \n> Fixes: 5a8f77e24a30 (\"PCI/IOV: Restore VF resizable BAR state after reset\")\n> Cc: stable@vger.kernel.org\n> Signed-off-by: Marco Nenciarini \n> ---\n> Cc: Michał Winiarski \n> Cc: Ilpo Järvinen \n> \n> drivers/pci/iov.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c\n> index 00784a60b..521f2cb64 100644\n> --- a/drivers/pci/iov.c\n> +++ b/drivers/pci/iov.c\n> @@ -946,6 +946,8 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)\n> \n> \t\tpci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);\n> \t\tbar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);\n> +\t\tif (bar_idx >= PCI_SRIOV_NUM_BARS)\n> +\t\t\tcontinue;\n> \t\tsize = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);\n> \t\tctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;\n> \t\tctrl |= FIELD_PREP(PCI_VF_REBAR_CTRL_BAR_SIZE, size);\n> -- \n> 2.47.3\n>","headers":{"Return-Path":"\n ","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=Enb/HGvB;\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-52659-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=\"Enb/HGvB\"","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 4fxYM53qwJz1yGt\n\tfor ; Fri, 17 Apr 2026 08:57:53 +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 104B330173A3\n\tfor ; Thu, 16 Apr 2026 22:57:50 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2914038C2B4;\n\tThu, 16 Apr 2026 22:57:47 +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 0413536AB47;\n\tThu, 16 Apr 2026 22:57:46 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 862DEC2BCAF;\n\tThu, 16 Apr 2026 22:57:46 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776380267; cv=none;\n b=KFppTgYjo7pDaQ4js90Ot+hYHo+zuHudxDLmnyVtA45crbgiQzVktkmXQFhSuG4/d4hC8p99GG1ruwjpIrfLG/XLX9nk4wXdqMGs+4yRIESjTl/lpDURsZ8Vr2f4GzXL3v9P+k9c5WkSrbejaIebL4HjqxWEFlePyFmlocFUs/c=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776380267; c=relaxed/simple;\n\tbh=INsj20KDfG23/jzsGs2wubVcaAApLPgZTwJiiSFc1Zc=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To;\n b=BObSpackZN2Y2w7OaCs9UTssIJuqrB/MR4vi0QbJqhK1Q+K83xNCe95pefg9/zmxs5pjEk3k/sjX1+ab66WTcbrzDpow6h8aNYsvRce+/ljDAQu6AKoAYcTQ24e84N1lc3dmBBZJQgsGuTcDwV/KOn01BM2+hFbAhSfSs2bHtEg=","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=Enb/HGvB; 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=1776380266;\n\tbh=INsj20KDfG23/jzsGs2wubVcaAApLPgZTwJiiSFc1Zc=;\n\th=Date:From:To:Cc:Subject:In-Reply-To:From;\n\tb=Enb/HGvBZ/uCmFzDSjEWKnkalJ1LFOsoHS2bHok65YiPFV11EkSIC0kRZGhttxo9+\n\t 01SQlzHWUWAfTRZgHBG+jIyR8EA95XKirshquCRTKM7buv8taphES0h4S7mCSu7HF5\n\t lPtKL6uA3tIn6KuOyCvmf8N1Q97vWQA+nkr1Bcaqs/QDcowbPlHgm8KwBsXwDPDupJ\n\t Ok0dF/2W5CRAA1VJK5a4YTs2tvuEQTWLVZjKzkBaEO0ZZN9RSEiUvv2h0INO6LyThs\n\t FhqaiZt884HV7VxzyWHww2lbpqCUivbsHJ/X/jDFYX/FjlWpNgsudGdCA9GHUU7gbF\n\t ByfMJitlc4fIQ==","Date":"Thu, 16 Apr 2026 17:57:45 -0500","From":"Bjorn Helgaas ","To":"Marco Nenciarini ","Cc":"Bjorn Helgaas ,\n =?utf-8?q?Micha=C5=82?= Winiarski , Ilpo\n\t=?utf-8?b?SsOkcnZpbmVu?= ,\n \"Rafael J. Wysocki\" , Eric Chanudet ,\n Alex Williamson , Lukas Wunner ,\n linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,\n stable@vger.kernel.org","Subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","Message-ID":"<20260416225745.GA41850@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260408163922.1740497-1-mnencia@kcore.it>"}},{"id":3678480,"web_url":"http://patchwork.ozlabs.org/comment/3678480/","msgid":"","list_archive_url":null,"date":"2026-04-17T04:57:21","subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","submitter":{"id":68499,"url":"http://patchwork.ozlabs.org/api/people/68499/","name":"Lukas Wunner","email":"lukas@wunner.de"},"content":"On Thu, Apr 16, 2026 at 05:57:45PM -0500, Bjorn Helgaas wrote:\n> And we have this weird retry loop in pci_restore_config_dword():\n> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pci.c?id=v7.0#n1766,\n> which was originally added by\n> https://git.kernel.org/linus/26f41062f28d (\"PCI: check for pci bar\n> restore completion and retry\") to fix an actual problem:\n> \n> On some OEM systems, pci_restore_state() is called while FLR has not\n> yet completed. As a result, PCI BAR register restore is not\n> successful. This fix reads back the restored value and compares it\n> with saved value and re-tries 10 times before giving up.\n> \n> This just gives me the heebie-jeebies. If we still need this retry\n> loop, it means all the previous state restoration (PCIe, LTR, ASPM,\n> IOV, PRI, ATS, DPC, etc.) probably failed, and we end up with a device\n> where the BARs got restored but none of the previous stuff. That\n> sounds like a mess.\n\nNowadays we wait for devices to re-appear after reset by polling the\nVendor ID register, see the call to pci_dev_wait() in pcie_flr().\n\nIt seems we didn't do that back in the day when 26f41062f28d introduced\nthe loop. The commit went into v3.4 and back then, pcie_flr() only\nwaited for 100 msec:\n\nhttps://elixir.bootlin.com/linux/v3.4/source/drivers/pci/pci.c#L3052\n\nAnd indeed pci_reset_function() immediately restored config space\nafterwards:\n\nhttps://elixir.bootlin.com/linux/v3.4/source/drivers/pci/pci.c#L3285\n\nSo I strongly suspect that the loop no longer has a valid raison d'être.\nMaybe remove it early in the next cycle to get linux-next coverage for\n8 weeks and see if anything breaks (which I doubt)?\n\nAs to validity of cached config space state in general, see this\ndiscussion with Ilpo yesterday, in response to a regression fix\nI submitted:\n\nhttps://lore.kernel.org/all/aeDXktnNLEtmYsbh@wunner.de/\n\nThanks,\n\nLukas","headers":{"Return-Path":"\n ","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 spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52684-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=83.223.78.233","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=wunner.de"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxjSJ3YP7z1yD3\n\tfor ; Fri, 17 Apr 2026 15:02:56 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 09D48302ED6E\n\tfor ; Fri, 17 Apr 2026 05:02:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D8C443B7A8;\n\tFri, 17 Apr 2026 05:02:51 +0000 (UTC)","from mailout2.hostsharing.net (mailout2.hostsharing.net\n [83.223.78.233])\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 AF68C1643B;\n\tFri, 17 Apr 2026 05:02:49 +0000 (UTC)","from h08.hostsharing.net (h08.hostsharing.net\n [IPv6:2a01:37:1000::53df:5f1c:0])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384\n\t client-signature ECDSA (secp384r1) client-digest SHA384)\n\t(Client CN \"*.hostsharing.net\",\n Issuer \"GlobalSign GCC R6 AlphaSSL CA 2025\" (verified OK))\n\tby mailout2.hostsharing.net (Postfix) with ESMTPS id 3FBD41062E;\n\tFri, 17 Apr 2026 06:57:21 +0200 (CEST)","by h08.hostsharing.net (Postfix, from userid 100393)\n\tid 20116601495C; Fri, 17 Apr 2026 06:57:21 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776402171; cv=none;\n b=s1p7a65bAc0BHPzbKeXDF3XDGPIdN0Fy6GbE/VGXLQkHXzKLyvPzYeySsY4Lq+f4tmzeAJGG5/3ScD47NZIYQQFvDIdld52TKptQr62aRrDI9cWKBc25vUmrtHA+Bo8EskIGxw6pYoJa/LlxvKBb9Axye/oLlUm8sNLPZ4SgDLw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776402171; c=relaxed/simple;\n\tbh=Z1CdR5FcjEmeJjNx2pjoaO8JYhaJSY/2d3TR/ySKYjg=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=sjctOI59uBDh5Xr6KLQeJJp/JlkF1joiGCLOkD1GelkSBt7oMiM9HERP/+ptx5bsW0pmpKaDC/DtfzbA+Jb4QDkF4PCyVWNkTJiEIHOoCR3EYPwjx4NSYtCbWzkafbkxDcoYZ9tUdBC9DClx0VAfJOMYKQJ264DaRiGdzqZuehI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de;\n spf=pass smtp.mailfrom=wunner.de; arc=none smtp.client-ip=83.223.78.233","Date":"Fri, 17 Apr 2026 06:57:21 +0200","From":"Lukas Wunner ","To":"Bjorn Helgaas ","Cc":"Marco Nenciarini , Bjorn Helgaas ,\n\t=?utf-8?q?Micha=C5=82?= Winiarski , Ilpo\n\t=?iso-8859-1?q?J=E4rvinen?= ,\n \"Rafael J. Wysocki\" , Eric Chanudet ,\n Alex Williamson , linux-pci@vger.kernel.org,\n linux-kernel@vger.kernel.org, stable@vger.kernel.org","Subject":"Re: [PATCH] PCI/IOV: Fix out-of-bounds access in\n sriov_restore_vf_rebar_state()","Message-ID":"","References":"<20260408163922.1740497-1-mnencia@kcore.it>\n <20260416225745.GA41850@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260416225745.GA41850@bhelgaas>"}}]