linux-kernel - Re: Linux 2.6.26-rc4

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <483B60DB.7020402@gmx.net>
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/