From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 040EA35E539 for ; Wed, 19 Nov 2025 12:50:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763556649; cv=none; b=XZcHh2bfwuTTBtWOmrE28a81VBXNOFCgUvAKMybq4p1uY9EPOgM2Ax3vl/g2950CbnWv1xPlFbjKjRIw+R95/qo8McPujJHGn7+iwRxOItYF88wPNan1nfPaggg+WGhI67/4d/F5yZnKtOydSrynG+tQIuqFTEngSgSeYvXLZMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763556649; c=relaxed/simple; bh=53sIM2pSeFpFsfToP9uhfhxM1wcng1ujol0qbTFJEJc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=exn9XdhFDjYNQV/zfSCvaaYg+r0msH571CbmL7g1wRKYjhGh3GhPze+dk/dGiLX5CA3QYoL6uwgBaFV0KGnAixy6OOmbeuJNHikXf96LR/Zl958IbL9PBJ4jR4zknfx+xGUzAk9eYxMACiJ686DZNu5oiCt3ovyw7+qKNRm77Uw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=qpU6DIEo; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="qpU6DIEo" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1763556635; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=SYvVHJtbZJgNDIZKPd7w4W44/8cwQKiklMT2dJiY6vA=; b=qpU6DIEo6ei7IMcXKQRgob1kWnSS25nHbU51X0w6cLeLTvaA2fM4wTEa2ipr/W6q+QSBVMmh3zS0u4Kx9qJ0Qt35c9gXQDRtWKbrGXldumyQzhuhTezeqA83UaZ5yJVo7VLUYi2tR/6QSeOsndGJs17igPwzJihnARIjMKYmJrY= Received: from 30.178.240.57(mailfrom:kanie@linux.alibaba.com fp:SMTPD_---0WsosPPm_1763556634 cluster:ay36) by smtp.aliyun-inc.com; Wed, 19 Nov 2025 20:50:35 +0800 Message-ID: <0a3ab821-d2ce-498d-b3cd-aff96fd872fd@linux.alibaba.com> Date: Wed, 19 Nov 2025 20:50:33 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: =?UTF-8?B?TW96aWxsYSBUaHVuZGVyYmlyZCDmtYvor5XniYg=?= Subject: Re: [PATCH v2] PCI: Check rom header and data structure addr before accessing To: Andy Shevchenko Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org References: <20251119101116.74307-1-kanie@linux.alibaba.com> From: Guixin Liu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2025/11/19 18:49, Andy Shevchenko 写道: > On Wed, Nov 19, 2025 at 06:11:16PM +0800, Guixin Liu wrote: > > Thanks for the update, my comments below. > >> We meet a crash when running stress-ng: >> >> 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 >> ksys_read+0x63/0xe0 >> do_syscall_64+0x34/0x80 >> entry_SYSCALL_64_after_hwframe+0x78/0xe2 > You missed my comment on these lines. Have you read Submitting Patches > documentation? oh, 4 lines, of coures, will be updated in v3. > >> 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. > ... > >> static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, >> size_t size) >> { >> + void __iomem *end = rom + size; >> void __iomem *image; >> int last_image; >> unsigned int length; >> image = rom; >> do { >> void __iomem *pds; >> + >> + if (image + PCI_ROM_HEADER_SIZE >= end) >> + break; >> + >> /* Standard PCI ROMs start out with these bytes 55 AA */ >> if (readw(image) != 0xAA55) { >> pci_info(pdev, "Invalid PCI ROM header signature: expecting 0xaa55, got %#06x\n", >> readw(image)); >> break; >> } >> + >> /* get the PCI data structure and check its "PCIR" signature */ >> pds = image + readw(image + 24); >> + if (pds + PCI_ROM_DATA_STRUCT_SIZE >= end) >> + break; >> if (readl(pds) != 0x52494350) { >> pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", >> readl(pds)); >> last_image = readb(pds + 21) & 0x80; >> length = readw(pds + 16); >> image += length * 512; >> + >> /* Avoid iterating through memory outside the resource window */ >> - if (image >= rom + size) >> + if (image + PCI_ROM_HEADER_SIZE >= end) > Theoretically this can overflow and become a false condition when should be > true. Check overflow.h if they have some helpers for wraparound checks. Yes, this can overflow, will be changed in v3. > So, first you need to validate the "end" and/or "size". > > image = rom; > do { > void __iomem *pds; > > if (size < PCI_ROM_HEADER_SIZE) > break; > ... > size -= ... // not sure if we can change this variable, though > } while (...); Sure, I will modify the code to fix the overflow issue. Best Regards, Guixin Liu > >> break; >> if (!last_image) { >> if (readw(image) != 0xAA55) {