linux-kernel - Re: [GIT PATCH] another tranche of SCSI updates for 2.6.26

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2008 09:05:34 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PATCH] another tranche of SCSI updates for 2.6.26

On Sun, 27 Apr 2008, James Bottomley wrote:
> 
> Try this; the signature for an uninitialised free list is easy (both
> list pointers NULL), so the patch detects that and doesn't try to run
> over the uninitialised list head.

Why aren't these things initialized?

You say that the signature of an uninitialised free list is trivial, but 
that's not at all true in general. It depends intimately on how the memory 
was allocated, and is thus very subtle indeed - some change to allocations 
can break something simple like this, by initializing it with random old 
memory contents.

So why not just initialize lists like this so early (ie at allocation 
time) that problems like this cannot happen? Instead of adding ugly and 
fragile cases to the freeing?

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