linux-kernel - Re: [PATCH] af_unix: Don't set err in unix_stream_read

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]

Message-Id: <20160216.125157.1927195719504877809.davem@davemloft.net>
Date:	Tue, 16 Feb 2016 12:51:57 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	rweikusat@...ileactivedefense.com
Cc:	hannes@...essinduktion.org, edumazet@...gle.com,
	dhowells@...hat.com, ying.xue@...driver.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, joseph.salisbury@...onical.com
Subject: Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic
 unless there was an error

From: Rainer Weikusat <rweikusat@...ileactivedefense.com>
Date: Mon, 08 Feb 2016 18:47:19 +0000

> The present unix_stream_read_generic contains various code sequences of
> the form
> 
> err = -EDISASTER;
> if (<test>)
> 	goto out;
> 
> This has the unfortunate side effect of possibly causing the error code
> to bleed through to the final
> 
> out:
> 	return copied ? : err;
> 
> and then to be wrongly returned if no data was copied because the caller
> didn't supply a data buffer, as demonstrated by the program available at
> 
> http://pad.lv/1540731
> 
> Change it such that err is only set if an error condition was detected.
> 
> Fixes: 3822b5c2fc62 ("af_unix: Revert 'lock_interruptible' in stream receive code")
> Reported-by: Joseph Salisbury <joseph.salisbury@...onical.com>
> Signed-off-by: Rainer Weikusat <rweikusat@...ileactivedefense.com>

Applied, thanks Rainer.

And BTW I disagree with some of the feedback I saw in these threads
about "if (x) goto out;" being unreadable and that it should be avoided.

That's completely wrong.

Fact is, we've all been reading code of that form for multiple decades.
So it's the style we are _MOST_ familiar with, and it is therefore the
style that is the easiest and clearest for kernel developers to understand.

Especially those of us who review hundreds of patches per day.

And it doesn't matter at all what the compiler does underneath.

Furthermore, such a style works best in the long term because if real
cleanup operations are added for exit from the function, less has to
change and such patches are therefore significantly easier to review.