linux-kernel - Re: x86: fix macro with bad_bios_dmi

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: <20080923081650.GA19003@elte.hu>
Date:	Tue, 23 Sep 2008 10:16:50 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: x86: fix macro with bad_bios_dmi_table


* Yinghai Lu <yhlu.kernel@...il.com> wrote:

> need one blank tail.
> 
> fix the crash on ingo's test box.

applied to tip/x86/memory-corruption-check, thanks Yinghai!

> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -760,8 +760,8 @@ static struct dmi_system_id __initdata bad_bios_dmi_table[] = {
>  			DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
>  		},
>  	},
> -	{}
>  #endif
> +	{}
>  };

i've seen such DMI crashes numerous times, caused by a missing NULL at 
the end of the table. Is there no sane way to detect or robustly avoid 
such run-off-the-end bugs?

how about changing dmi_check_system(table) to a macro, which does 
something like:

   __dmi_check_system(&(table), sizeof(table)) 

and rename dmi_check_system() in drivers/firmware/dmi_scan.c to 
__dmi_check_system() and add the size parameter? That way we could 
remove the need for NULL termination and it's even a size optimization: 
it shrinks those tables a tiny bit.

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