linux-kernel - Re: [bug] ata subsystem related crash with latest -git

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, 17 Oct 2007 18:07:19 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
cc:	jens.axboe@...cle.com, mingo@...e.hu, linux-kernel@...r.kernel.org,
	jgarzik@...ox.com, alan@...rguk.ukuu.org.uk, tomof@....org
Subject: Re: [bug] ata subsystem related crash with latest -git

On Thu, 18 Oct 2007, FUJITA Tomonori wrote:
> 
> Looks that (sglist) - 1 isn't initialized and we use sg_next for it?

sg_next() - as it stands now - never actually looks at the SG that its 
argument points to: it explicitly *only* looks at the next one.

That's the bug. If sg_next() looked at the actual *current* sg entry, we 
wouldn't have any issues to begin with, and that's what I'm arguing we 
should do in the longer run (where "longer run" is defined as "when Jens 
does it asap").

So the hacky solution as it stands right now is to actually use the 
behaviour of "sg_next()" to our advantage in for_each_sg(), and starting 
off by setting sg to (sglist)-1. That way we can do the "sg_next()" (which 
will *not* look at the uninitialized space before the array) before 
entering the loop, regardless of whether it's the first time through the 
loop or not.

So no, it's not technically "strictly conforming ANSI C", because we use a 
pointer (not do not dereference it!) outside of its allocation, which is 
strictly speaking against the standard. However, the kernel does those 
kinds of things all the time, since the kernel does its own memory 
allocation, so that's not actually relevant.

The *standard* may say that you cannot decrement a pointer to before the 
beginning of the object and then increment it back up again and be 
strictly conforming, but the fact is, we very much depend on contiguous 
and flat kernel pointer model, and always have (and probably always will)

		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/