linux-kernel - Re: 2.6.18-stable release plans?

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: <200701252326.50719.s0348365@sms.ed.ac.uk>
Date:	Thu, 25 Jan 2007 23:26:50 +0000
From:	Alistair John Strachan <s0348365@....ed.ac.uk>
To:	Chris Rankin <rankincj@...oo.com>
Cc:	Ken Moffat <zarniwhoop@...world.com>,
	Alan <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.18-stable release plans?

On Thursday 25 January 2007 09:16, Chris Rankin wrote:
> But anyway - can someone please tell me what "Eeek! page_mapcount(page)
> went negative! (-1)" is *really* saying/implying? Because I am currently
> translating this as "I WANT TO EAT YOUR FILESYSTEMS".

Hugh already did, multiple times. If there's an external hardware event that 
corrupts memory, code executing on your CPU is no longer going to behave 
deterministically. So cases that are typically "impossible" in the design of 
the code have a chance to trigger.

You can continue to flame 2.6.19, but you're an extreme minority when it comes 
to this kind of bug and as, again, Hugh already said, almost all of the 
reports of this and similar other bugs have led to hardware problems that 
were either unchecked or difficult to detect.

Imagine this scenario. It might seem unrealistic to you, but it's not 
impossible!

First Use of Linux -> Upgrading to 2.6.19
	Undetected hardware error never triggered.

Running 2.6.19
	Hardware error triggers. Linux crashes.

Going back to 2.6.18
	Hardware error has not yet triggered again.

Will it eat your filesystem? Maybe. But it probably won't, if you claim the 
memory is tested, it could have been a single bit error, or a cosmic ray 
event, or a brownout, or anything similar. It's much more likely to simply 
crash your machine, as it did.

Not running the affected kernel again is a sure way to have _nobody_ listen to 
your complaints about 2.6.19 having a real software bug, because you're 
totally unwilling to test the kernel again and see if it triggers. A single 
report is simply not enough evidence. 

Additionally, reports from other users (who may have a million different 
experimental variables involved) are also insufficient, for reasons which 
have already been explained (drivers, proprietary code, et cetera).

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
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/