From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 C3AFD33CEB4 for ; Wed, 26 Nov 2025 17:39:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764178760; cv=none; b=pg/fg1IA5M1rRy3EMcSDrLaBmC6QrqndnWmo4RsawdJtPoJNhvD7U4XelP0l0/IkEUNCkIHo4AcTaVkitihc9kHz1qMB3csunVgtLeLgduZ8b3ClkmpKodummQfrq1i3595RDyfsgeJ1OFc+O0aVxcxFvpVQ/uXj6+hwRX5BAjw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764178760; c=relaxed/simple; bh=E1DM5QNauY0G0GGn+dn7XVaWcHQiu3RtJPpa1tGfZJQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q2KUM3Sc4/SdHhjH/ZziqXr/VgrEwFuCGvqdoLWLPChKznvHMnExSpta+iqbNuv1OGWQJev+oe3wNoTyLqyOIFLaj0wm0AuxZR3sr0jaDHPC6VVBH1IuOPp1zc6uI5HUiqAIHNJdeqk+rRpLcVxqA6oDi3rRh1qPKlcZwV7UHkk= 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=arS6YHmY; arc=none smtp.client-ip=192.198.163.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="arS6YHmY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764178759; x=1795714759; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=E1DM5QNauY0G0GGn+dn7XVaWcHQiu3RtJPpa1tGfZJQ=; b=arS6YHmY1nYvhCIGiTssLuATvcBmp+ObWhqBiCJXJD4CgAqHNC18ACyG 0vrCKZISoOCNp+9tK1H5+YQXXKXQ3Ll83UH1Sk2JAKPou+ugF+swnQ4m5 etCLp2PxVtlnaeg/eRahm1PqKHkr07m9Luhcb3yULUZ9qQTnMufgz1JXc lBbVOQA+MLLkd9kAt7f9N7u1sSCsj5bX1jvbnc60sLCnfH03y/r8AWCyd cLtuD03m06UlRrxpZRQvZVXXzSHfOCsPawdMbLqtKO1OsBH7QMr1xtgQI HwB5OzRiGpTe/ipgVc7D/Avgrcu49beK3By1fzUz5Ma30p03NQy/KpKYp Q==; X-CSE-ConnectionGUID: 1oay5fCnQVyDkcMU/pd6qw== X-CSE-MsgGUID: V+1bppyES0i7nW8BxgGrgw== X-IronPort-AV: E=McAfee;i="6800,10657,11625"; a="77587556" X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="77587556" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 09:39:18 -0800 X-CSE-ConnectionGUID: fvA6TEw2R8uovRJn1BDDXg== X-CSE-MsgGUID: TqnecUF+TGSejkaMqvMW4g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="230264330" 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; 26 Nov 2025 09:39:16 -0800 Date: Wed, 26 Nov 2025 19:39:14 +0200 From: Andy Shevchenko To: Guixin Liu Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] PCI: Check rom header and data structure addr before accessing Message-ID: References: <20251126125727.57620-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: <20251126125727.57620-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 08:57:27PM +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. There are few comments, but in general it looks good to me. So, if you address the below, feel free to add Reviewed-by: Andy Shevchenko And thanks for pursuing this issue! ... > --- > v3 -> v4: > - Use "u64" instead of "uintptr_t". Hmm... Do we have a use cases when u64 is required on, say, 32-bit unsigned long cases? > - Invert the if statement to avoid excessive indentation. > - Add comment for alignment checking. > - Change last_image's type from int to bool. ... > +static inline bool pci_rom_header_valid(struct pci_dev *pdev, Usually we use verb 'is' in names of the boolean functions. pci_rom_is_header_valid() > + void __iomem *image, > + void __iomem *rom, > + size_t size, > + bool last_image) > +{ > + u64 rom_end = (u64)rom + size; > + u64 header_end; > + > + /* > + * Some CPU architectures require IOMEM access addresses to > + * be aligned, for example arm64, so since we're about to > + * call readw(), we check here for 2-byte alignment. > + */ > + if (!IS_ALIGNED((u64)image, 2)) > + return false; > + > + if (check_add_overflow((u64)image, PCI_ROM_HEADER_SIZE, &header_end)) > + return false; > + > + if (image < rom || header_end >= rom_end) But header_end == rom_end is valid case for _header_, no? Then we should fail later on. > + 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)); The positive conditional can be used (easier to parse) if (last_image) ... else ... > + return false; > +} > + > +static inline bool pci_rom_data_struct_valid(struct pci_dev *pdev, pci_rom_is_data_struct_valid() > + void __iomem *pds, > + void __iomem *rom, > + size_t size) > +{ > + u64 rom_end = (u64)rom + size; > + u64 end; > + u16 data_len; > + > + /* > + * Some CPU architectures require IOMEM access addresses to > + * be aligned, for example arm64, so since we're about to > + * call readl(), we check here for 4-byte alignment. > + */ > + if (!IS_ALIGNED((u64)pds, 4)) > + return false; > + > + /* Before reading length, check range. */ > + if (check_add_overflow((u64)pds, 0x0B, &end)) > + return false; > + > + if (pds < rom || end >= rom_end) Same Q here, wouldn't '=' be a valid case? > + return false; > + > + data_len = readw(pds + 0x0A); > + if (!data_len || data_len == 0xFFFF || U16_MAX? > + check_add_overflow((u64)pds, data_len, &end)) > + return false; I would split these two data_len = readw(pds + 0x0A); if (!data_len || data_len == U16_MAX) return false; if (check_add_overflow((u64)pds, data_len, &end)) return false; > + if (end >= rom_end) > + return false; > + > + if (readl(pds) == 0x52494350) > + return true; > + > + pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", > + readl(pds)); > + return false; > +} ... > 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); !!() is not needed. last_image = readb(pds + 21) & 0x80; > length = readw(pds + 16); > image += length * 512; > + > + if (!pci_rom_header_valid(pdev, image, rom, size, last_image)) > break; > } while (length && !last_image); -- With Best Regards, Andy Shevchenko