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: <20111110114732.GA2217@redhat.com>
Date:	Thu, 10 Nov 2011 12:47:33 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Tomáš Janoušek <tomi@...i.cz>
Cc:	linux-kernel@...r.kernel.org, Wey-Yi Guy <wey-yi.w.guy@...el.com>,
	linux-wireless@...r.kernel.org
Subject: Re: iwlagn: memory corruption with WPA enterprise

Hello Tomáš

On Thu, Nov 10, 2011 at 10:18:16AM +0100, Tomáš Janoušek wrote:
> On Wed, Nov 09, 2011 at 05:51:59PM +0100, Stanislaw Gruszka wrote:
> > I just discovered that CONFIG_DEBUG_PAGEALLOC does not work as expected.
> > It leave most of free pages unprotected, hence unintentional write to
> > them is not discovered. I'm attaching additional patch, which should
> > make detection actually work.
> > 
> > If kernel will does not boot with corrupt_dbg=1, you may try to catch
> > corruption without that option. Attached patch should make it possible,
> > however having corrupt_dbg=1 increase probability of the catch.
> 
> Okay, I applied this additional patch, and by the increased memory usage (as
> shown by free) I concluded that it indeed works. However, I was still able to
> reproduce the issue without a single error being written to dmesg. :-(
If "dmesg | grep corrupt" will show "Setting corrupt debug order to 1"
patches are in use. Anyway I need to test the patches locally, to see
if they work as expected, perhaps exception is generated but call-trace
is not printed.

Is this happen only with "Intel Corporation Centrino Advanced-N 6205" or
with some other adapters?

> I will try some really old kernels as Wey suggested to see whether it makes
> any sense to bisect it, but if it does, it might take more time than I can
> make free.
Yes, bisection is very time consuming, especially when reproducing
is not easy.

> Perhaps it would be cheaper to just get another card in that case.
> :-)
That will left issue unresolved :-(

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ