linux-kernel - Re: [3.9-rc1 x86] Bug in ioremap code?

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: <51367104.5050200@linux.vnet.ibm.com>
Date:	Tue, 05 Mar 2013 14:26:12 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
CC:	bp@...en8.de, hpa@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [3.9-rc1 x86] Bug in ioremap code?

Just booted a qemu-kvm guest with this .config.  It didn't trip over
anything, so I'm looking for some more ACPI tables to feed in to it.

Looking through the code, it looks like this is the __pa() that's
hitting the BUG_ON():

static int __cpa_process_fault(struct cpa_data *cpa, unsigned long
...
        if (within(vaddr, PAGE_OFFSET,
                   PAGE_OFFSET + (max_pfn_mapped << PAGE_SHIFT))) {
                cpa->numpages = 1;
                cpa->pfn = __pa(vaddr) >> PAGE_SHIFT;
                return 0;
        } else {

The within() check should ensure that we're not doing __pa() on
vmalloc() addresses.  So, either somebody managed to remap part of the
kernel identity mapping, or that within() check is failing us somehow.

What kind of hardware is this?

--
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/