lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 May 2008 03:16:11 +0200 From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@....net> To: Linus Torvalds <torvalds@...ux-foundation.org> CC: Jesper Krogh <jesper@...gh.cc>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, David Woodhouse <dwmw2@...radead.org> Subject: Re: Linux 2.6.26-rc4 On 26.05.2008 23:42, Linus Torvalds wrote: > On Mon, 26 May 2008, Jesper Krogh wrote: > >> I did get this one (which I didn't on 2.6.25.2) >> >> [42949399.810959] ck804xrom ck804xrom_init_one(): Unable to register resource >> 0x0000000000000000-0x00000000ffffffff - kernel bug? >> > > Something is trying to register a 4GB resource. That sounds unlikely > (possible on a 64-bit PCI setup, but I think it's more likely to be some > overflow of 0 in "unsigned int"). > > In fact, this seems to be due to some driver bug. It looks like we have > > window->size = 0xffffffffUL - window->phys + 1UL; > > and in order for window->size to be 0x100000000, that means that > window->phys has to be 0. Which looks impossible, or at least like > ent->driver_data is neither DEV_CK804 nor DEV_MCP55. Very odd. > > The warning: > > >> [42949399.979924] WARNING: at arch/x86/mm/ioremap.c:159 __ioremap_caller+0x299/0x330() >> > > is then just a result of the driver blindly continuing and trying to > "ioremap()" the resource even though it's bogus and the resource > allocation failed. > > In other words, that driver init routine is really bad about error > handling. Carl-Daniel? David? > It hurts to look at this: static struct pci_device_id ck804xrom_pci_tbl[] = { { PCI_VENDOR_ID_NVIDIA, 0x0051, PCI_ANY_ID, PCI_ANY_ID, DEV_CK804 }, { PCI_VENDOR_ID_NVIDIA, 0x0360, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0361, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0362, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0363, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0364, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0365, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0366, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { PCI_VENDOR_ID_NVIDIA, 0x0367, PCI_ANY_ID, PCI_ANY_ID, DEV_MCP55 }, { 0, } }; considering how struct pci_device_id looks like: struct pci_device_id { __u32 vendor, device; /* Vendor and device ID or PCI_ANY_ID*/ __u32 subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */ __u32 class, class_mask; /* (class,subclass,prog-if) triplet */ kernel_ulong_t driver_data; /* Data private to the driver */ }; DEV_CK804 and DEV_MCP55 actually end up in class instead of driver_data. I'd send a patch, but I'm traveling and my only code access is gitweb. New code should look like static struct pci_device_id ck804xrom_pci_tbl[] = { { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0051), .driver_data = DEV_CK804 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0360), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0361), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0362), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0363), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0364), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0365), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0366), .driver_data = DEV_MCP55 }, { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0367), .driver_data = DEV_MCP55 }, { 0, } }; Regards, Carl-Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists