On Thu, Oct 24, 2024 at 10:17:25AM +0800, liwei wrote:
> 'pds' does not perform 4-byte alignment check. If 'pds' is not 4-byte
> aligned, it will cause alignment fault.
>
> 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
> Data abort info:
> ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000203ef6a0d000
> [ffff8000c930ffff] pgd=1000002080bcf003, p4d=1000002080bcf003, pud=100000403ae8a003, pmd=1000202027498003, pte=00680000b000ff13
> Internal error: Oops: 0000000096000021 [#1] SMP
> CPU: 16 PID: 451316 Comm: read_all Kdump: loaded Tainted: G W 6.6.0+ #6
> Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 6.57 05/17/2023
> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : pci_get_rom_size+0x74/0x1f0
> lr : pci_map_rom+0x140/0x280
> sp : ffff8000b96178f0
> x29: ffff8000b96178f0 x28: ffff004e284b3f80 x27: ffff8000b9617be8
> x26: ffff0020facb7020 x25: 0000000000100000 x24: 00000000b0000000
> x23: ffff00208c8ea740 x22: 1ffff000172c2f2e x21: ffff8000c9300000
> x20: 0000000000100000 x19: ffff8000c9300000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> x14: 0000000000000000 x13: 0000000041b58ab3 x12: 1ffff000172c2ec8
> x11: 00000000f1f1f1f1 x10: ffff7000172c2ec8 x9 : ffffb9ba9db93ad8
> x8 : ffff7000172c2eac x7 : ffff8000c9400000 x6 : 0000000052494350
> x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff8000c930ffff
> x2 : 000000000000aa55 x1 : 0000000000000000 x0 : ffff00208c8ea000
> Call trace:
> pci_get_rom_size+0x74/0x1f0
> pci_map_rom+0x140/0x280
> pci_read_rom+0xa8/0x158
> sysfs_kf_bin_read+0xb8/0x130
> kernfs_file_read_iter+0x124/0x278
> kernfs_fop_read_iter+0x6c/0xa8
> new_sync_read+0x128/0x208
> Inject: max_dir_depth
> vfs_read+0x244/0x2b0
> ksys_read+0xd0/0x188
> __arm64_sys_read+0x4c/0x68
> invoke_syscall+0x68/0x1a0
> el0_svc_common.constprop.0+0x11c/0x150
> do_el0_svc+0x38/0x50
> el0_svc+0x64/0x258
> el0t_64_sync_handler+0x100/0x130
> el0t_64_sync+0x188/0x190
> Code: d50331bf ca030061 b5000001 8b030263 (b9400064)
> SMP: stopping secondary CPUs
> Starting crashdump kernel...
>
> In UEFI Specification Version 2.8, describes that the PCIR data structure must
> start on a 4-byte boundary. Fix it by verifying the 'pds' is aligned.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: liwei <liwei728@xxxxxxxxxx>
> ---
> drivers/pci/rom.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
> index e18d3a4383ba..0fa6b3da63cc 100644
> --- a/drivers/pci/rom.c
> +++ b/drivers/pci/rom.c
> @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom,
> }
> /* get the PCI data structure and check its "PCIR" signature */
> pds = image + readw(image + 24);
> + /* The PCIR data structure must begin on a 4-byte boundary */
> + if (!IS_ALIGNED((unsigned long)pds, 4)) {
> + pci_info(pdev, "Invalid PCI ROM header signature: PCIR %#06x\n",
> + readw(image + 24));
> + break;
> + }
We definitely should not panic if the ROM is incorrectly formatted. I
assume this crash happened because the ROM is mapped in such a way
that an unaligned readl() causes an alignment fault.
What would be the downside of reading byte-wise and just not enforcing
the alignment restriction, e.g., by using memcpy_fromio() or similar?
If we bail out here, I think we'll report a size that doesn't include
any images after this one where PCIR isn't correctly aligned.
> if (readl(pds) != 0x52494350) {
> pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n",
> readl(pds));
> --
> 2.25.1
>
