linux-kernel - [PATCH 0/4] Avoid panic in case of buggy bios

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>] [day] [month] [year] [list]

Message-Id: <1203368168-30257-1-git-send-email-gcosta@redhat.com>
Date:	Mon, 18 Feb 2008 17:56:08 -0300
From:	Glauber Costa <gcosta@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, andrew.grover@...el.com,
	paul.s.diefenbaugh@...el.com, linux@...do.de,
	anil.s.keshavamurthy@...el.com, lenb@...nel.org,
	linux-acpi@...r.kernel.org
Subject: [PATCH 0/4] Avoid panic in case of buggy bios

Hi,

I've came across a panic today after failing acpi_processor_start()
in this condition:

        if (processor_device_array[pr->id] != NULL &&
            processor_device_array[pr->id] != device) {
                printk(KERN_WARNING "BIOS reported wrong ACPI id "
                        "for the processor\n");
                return -ENODEV;
        }

The problem is that there are some data structures that are not initialized
if we exit that early, but the removal functions assume to be present. One
solution would be to move the checks to the bottom of this function, after
all the initializations are complete, but I personally think this is
not a good idea, from the waste point of view.

So I'm attaching a series of 4 patches that provides a criteria to decide
whether or not we got past the point of initializing that data structures,
and using it to conditionally unregister them latter.

Hope it's okay with you

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