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]
Date:	Wed, 13 Jan 2016 00:51:17 +0100
From:	Jann Horn <jann@...jh.net>
To:	Daniel Axtens <dja@...ens.net>
Cc:	kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Baoquan He <bhe@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [RFC] kernel/panic: place an upper limit on number of oopses

On Wed, Jan 13, 2016 at 10:34:39AM +1100, Daniel Axtens wrote:
> Jann Horn <jann@...jh.net> writes:
> > +	 * limit is reached, just panic.
> > +	 * The constant used as limit should be low enough to
> > +	 * mitigate this kind of exploitation attempt, but high
> > +	 * enough to avoid unnecessary panics.
> > +	 */
> > +	if (atomic_inc_return(&oops_counter) >= 0x100000 &&
> > +			panic_on_oops == 0) {
> Do you need to check panic_on_oops? If it was 1 you'd already have
> paniced, right?
[...]
> > +		pr_emerg("oopsed too often, setting panic_on_oops=1\n");
> > +		panic_on_oops = 1;
> Would it be easier to just panic here, rather than wait for another oops?

Ah, yes. So the code would be just this, apart from the definition of
oops_counter:

        if (atomic_inc_return(&oops_counter) >= 0x100000)
                panic("oopsed too often\n");

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ