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:	Fri, 25 Apr 2008 00:45:23 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jirislaby@...il.com
Cc:	torvalds@...ux-foundation.org, zdenek.kabelac@...il.com,
	mingo@...e.hu, rjw@...k.pl, paulmck@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	penberg@...helsinki.fi, clameter@....com,
	johannes@...solutions.net, flamingice@...rmilk.net, jbenc@...e.cz
Subject: Re: 2.6.25-git2: BUG: unable to handle kernel paging request at
 ffffffffffffffff

From: Jiri Slaby <jirislaby@...il.com>
Date: Fri, 25 Apr 2008 09:41:12 +0200

> Added 3 80211 experts.
> 
> On 04/25/2008 03:57 AM, David Miller wrote:
> > From: Linus Torvalds <torvalds@...ux-foundation.org>
> > Date: Thu, 24 Apr 2008 18:48:32 -0700 (PDT)
> > 
> >> But that 0xf0 definitely has shown up before. It's not the *only* 
> >> corruption, but it's definitely a very interesting pattern. And the other 
> >> ones that didn't show the 0xf0 pattern could obviously be due to pointers 
> >> that were corrupted by 0xf0 in low bytes, so it _may_ be the source of the 
> >> other corruptions too that didn't have an obvious 0xf0 directly in them.
> > 
> > Ok.
> > 
> > Do we know of any pattern of the wireless device type in use?
> > If there is a pattern to that, it would be a huge clue.
> > 
> > And if it is predominantly one particular wireless device type, we
> > should be able to come up with a patch to test.
> 
> Johannes, Michael, Jiri? Someone writes to freed memory patterns 0xf0 (not 
> aligned to anything, addressed per byte), one of suspects is mac80211, don't you 
> know that pattern from anywhere?

I notice Jiri, in your hardware list, you have an ath5k Atheros AR5212 chip
in there.

I took a look at the resume code for ath5k but nothing really suspicious
there except:

	err = pci_enable_device(pdev);
	if (err)
		return err;

	pci_restore_state(pdev);

Shouldn't we restore state before we turn the chip back on and thus
potentially let it start DMA'ing all over the place?
--
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