From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4369B4C97 for ; Wed, 26 Nov 2025 07:49:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764143389; cv=none; b=T7+33IbL00mwdv4r9iQJgX/SAKSiJz4wFHHggXDsfKbSLWE1RqIGcawjIIOjZjhoy8Fc18bOXF8PqfuNUBj31EmlyQ0gMlNeUgWRYQEvLnZth20tjPOTZbzNTvp4c0AfMzxs+rDJIRuo8gwbMrptHNftw92G1ryaS3nBTr/rIxg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764143389; c=relaxed/simple; bh=Oi/HfJstdjPyhynZE5owXpjNJXoNlvl7hiXB4Y7/1Zo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LhVxOWrsmC+16whEWUzqkCdvfMhstEaApytXKprVsyvlMPCzGIYwp6LSsKPlukxsqVPL3DByEjjjXuRNCLhcOeoZjQumu1rL5VZ093xe5rFS0eJT/hH3ujeyReT/BTJLRbfICu5ifyZJcm33dU4lbxpzNl/nPMPOg+L11v9VADI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TzpPFrqr; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TzpPFrqr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764143388; x=1795679388; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Oi/HfJstdjPyhynZE5owXpjNJXoNlvl7hiXB4Y7/1Zo=; b=TzpPFrqr4ELLpfCwklvpvTBYalRC/Hpehb2JMIu3xdkX1DYeqTB0hp5M 9IM6c2Rlv/ONCCOw2O7U7MgVvpwf0pZWsY8obLeLdXkBX1hlax3n+9zdL Cev/D5gI3ETKgyWD2yYh30qLRgr7iQzTozpOCwZyepH/W6WnIKUU6XPKt sFgO0NLMGb5Dpj1ivLQWecWreGLUEcwbY/g1BN/ieBvvDVCfqsRmaQJDh v2rWv/Lh7PirCHaJjW8efnwavJOIvNuOMfQ9A4B5k4ovwTj0dgQv0yAWK q6AEPVkKegnoNgSZvRa8GlPKBj6s8si4O5hnjE+75SijyceoT2es6zNxu w==; X-CSE-ConnectionGUID: 068i8MB2TkSHN1MoIdn5pw== X-CSE-MsgGUID: 6QRTF38ARKizlM9VcA+meQ== X-IronPort-AV: E=McAfee;i="6800,10657,11624"; a="83564352" X-IronPort-AV: E=Sophos;i="6.20,227,1758610800"; d="scan'208";a="83564352" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Nov 2025 23:49:48 -0800 X-CSE-ConnectionGUID: 5CyTEgU7T4e/fluFZkJtbg== X-CSE-MsgGUID: anCHnDhCSGSgW/1+No16SQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,227,1758610800"; d="scan'208";a="230128883" Received: from rvuia-mobl.ger.corp.intel.com (HELO localhost) ([10.245.245.89]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Nov 2025 23:49:45 -0800 Date: Wed, 26 Nov 2025 09:49:43 +0200 From: Andy Shevchenko To: Guixin Liu Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] PCI: Check rom header and data structure addr before accessing Message-ID: References: <20251126072623.62579-1-kanie@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <20251126072623.62579-1-kanie@linux.alibaba.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Wed, Nov 26, 2025 at 03:26:23PM +0800, Guixin Liu wrote: > We meet a crash when running stress-ng on x86_64 machine: > > BUG: unable to handle page fault for address: ffa0000007f40000 > RIP: 0010:pci_get_rom_size+0x52/0x220 > Call Trace: > > pci_map_rom+0x80/0x130 > pci_read_rom+0x4b/0xe0 > kernfs_file_read_iter+0x96/0x180 > vfs_read+0x1b1/0x300 > > Our analysis reveals that the rom space's start address is > 0xffa0000007f30000, and size is 0x10000. Because of broken rom > space, before calling readl(pds), the pds's value is > 0xffa0000007f3ffff, which is already pointed to the rom space > end, invoking readl() would read 4 bytes therefore cause an > out-of-bounds access and trigger a crash. > Fix this by adding image header and data structure checking. > > We also found another crash on arm64 machine: > > Unable to handle kernel paging request at virtual address > ffff8000dd1393ff > Mem abort info: > ESR = 0x0000000096000021 > EC = 0x25: DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > FSC = 0x21: alignment fault > > The call trace is the same with x86_64, but the crash reason is > that the data structure addr is not aligned with 4, and arm64 > machine report "alignment fault". Fix this by adding alignment > checking. Thanks for the update, looks much better now! My comments below. ... > +static inline bool pci_rom_header_valid(struct pci_dev *pdev, > + void __iomem *image, > + void __iomem *rom, > + size_t size, > + bool last_image) > +{ > + uintptr_t rom_end = (uintptr_t)rom + size; > + uintptr_t header_end; Note: Linus told that kernel should not use uintptr_t. s/uintptr_t/unsigned long/g and here in some cases we even don't need that type at all. > + if (check_add_overflow((uintptr_t)image, PCI_ROM_HEADER_SIZE, > + &header_end)) > + return false; > + if (image >= rom && header_end < rom_end && > + IS_ALIGNED((uintptr_t)image, 2)) { So, why not /* Check if we have enough space in ROM */ if (image < rom || header_end > rom_end) return false; /* ARM requires proper alignment */ /// Find a better comment text for above. if (!IS_ALIGNED((unsigned long)image, 2UL)) return false; > + /* Standard PCI ROMs start out with these bytes 55 AA */ > + if (readw(image) == 0xAA55) > + return true; > + > + if (!last_image) > + pci_info(pdev, "No more image in the PCI ROM\n"); > + else > + pci_info(pdev, "Invalid PCI ROM header signature: expecting 0xaa55, got %#06x\n", > + readw(image)); > + } > + return false; > +} ... > +static inline bool pci_rom_data_struct_valid(struct pci_dev *pdev, > + void __iomem *pds, > + void __iomem *rom, > + size_t size) Similar comments as per above. ... > image = rom; > do { > void __iomem *pds; > + > + if (!pci_rom_header_valid(pdev, image, rom, size, true)) > break; > + > /* get the PCI data structure and check its "PCIR" signature */ > pds = image + readw(image + 24); > + if (!pci_rom_data_struct_valid(pdev, pds, rom, size)) > break; > + > last_image = readb(pds + 21) & 0x80; > length = readw(pds + 16); > image += length * 512; > + if (!pci_rom_header_valid(pdev, image, rom, size, (bool)last_image)) This casting is a bit odd. Can we avoid doing like this? > } while (length && !last_image); -- With Best Regards, Andy Shevchenko