<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/unix, branch dev-4.6</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.6</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2016-02-23T05:09:14+00:00</updated>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2016-02-23T05:09:14+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2016-02-23T05:09:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b633353115e352d3c31c12d4c61978c810f05ea1'/>
<id>urn:sha1:b633353115e352d3c31c12d4c61978c810f05ea1</id>
<content type='text'>
Conflicts:
	drivers/net/phy/bcm7xxx.c
	drivers/net/phy/marvell.c
	drivers/net/vxlan.c

All three conflicts were cases of simple overlapping changes.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_unix: Don't use continue to re-execute unix_stream_read_generic loop</title>
<updated>2016-02-20T04:50:31+00:00</updated>
<author>
<name>Rainer Weikusat</name>
<email>rweikusat@mobileactivedefense.com</email>
</author>
<published>2016-02-18T12:39:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=18eceb818dc37bbc783ec7ef7703f270cc6cd281'/>
<id>urn:sha1:18eceb818dc37bbc783ec7ef7703f270cc6cd281</id>
<content type='text'>
The unix_stream_read_generic function tries to use a continue statement
to restart the receive loop after waiting for a message. This may not
work as intended as the caller might use a recvmsg call to peek at
control messages without specifying a message buffer. If this was the
case, the continue will cause the function to return without an error
and without the credential information if the function had to wait for a
message while it had returned with the credentials otherwise. Change to
using goto to restart the loop without checking the condition first in
this case so that credentials are returned either way.

Signed-off-by: Rainer Weikusat &lt;rweikusat@mobileactivedefense.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>unix_diag: fix incorrect sign extension in unix_lookup_by_ino</title>
<updated>2016-02-20T04:49:23+00:00</updated>
<author>
<name>Dmitry V. Levin</name>
<email>ldv@altlinux.org</email>
</author>
<published>2016-02-19T01:27:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b5f0549231ffb025337be5a625b0ff9f52b016f0'/>
<id>urn:sha1:b5f0549231ffb025337be5a625b0ff9f52b016f0</id>
<content type='text'>
The value passed by unix_diag_get_exact to unix_lookup_by_ino has type
__u32, but unix_lookup_by_ino's argument ino has type int, which is not
a problem yet.
However, when ino is compared with sock_i_ino return value of type
unsigned long, ino is sign extended to signed long, and this results
to incorrect comparison on 64-bit architectures for inode numbers
greater than INT_MAX.

This bug was found by strace test suite.

Fixes: 5d3cae8bc39d ("unix_diag: Dumping exact socket core")
Signed-off-by: Dmitry V. Levin &lt;ldv@altlinux.org&gt;
Acked-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_unix: Guard against other == sk in unix_dgram_sendmsg</title>
<updated>2016-02-16T17:53:35+00:00</updated>
<author>
<name>Rainer Weikusat</name>
<email>rweikusat@mobileactivedefense.com</email>
</author>
<published>2016-02-11T19:37:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a5527dda344fff0514b7989ef7a755729769daa1'/>
<id>urn:sha1:a5527dda344fff0514b7989ef7a755729769daa1</id>
<content type='text'>
The unix_dgram_sendmsg routine use the following test

if (unlikely(unix_peer(other) != sk &amp;&amp; unix_recvq_full(other))) {

to determine if sk and other are in an n:1 association (either
established via connect or by using sendto to send messages to an
unrelated socket identified by address). This isn't correct as the
specified address could have been bound to the sending socket itself or
because this socket could have been connected to itself by the time of
the unix_peer_get but disconnected before the unix_state_lock(other). In
both cases, the if-block would be entered despite other == sk which
might either block the sender unintentionally or lead to trying to unlock
the same spin lock twice for a non-blocking send. Add a other != sk
check to guard against this.

Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
Reported-By: Philipp Hahn &lt;pmhahn@pmhahn.de&gt;
Signed-off-by: Rainer Weikusat &lt;rweikusat@mobileactivedefense.com&gt;
Tested-by: Philipp Hahn &lt;pmhahn@pmhahn.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_unix: Don't set err in unix_stream_read_generic unless there was an error</title>
<updated>2016-02-16T17:48:04+00:00</updated>
<author>
<name>Rainer Weikusat</name>
<email>rweikusat@mobileactivedefense.com</email>
</author>
<published>2016-02-08T18:47:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1b92ee3d03af6643df395300ba7748f19ecdb0c5'/>
<id>urn:sha1:1b92ee3d03af6643df395300ba7748f19ecdb0c5</id>
<content type='text'>
The present unix_stream_read_generic contains various code sequences of
the form

err = -EDISASTER;
if (&lt;test&gt;)
	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 &lt;joseph.salisbury@canonical.com&gt;
Signed-off-by: Rainer Weikusat &lt;rweikusat@mobileactivedefense.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>unix: correctly track in-flight fds in sending process user_struct</title>
<updated>2016-02-08T15:30:42+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2016-02-03T01:11:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=415e3d3e90ce9e18727e8843ae343eda5a58fad6'/>
<id>urn:sha1:415e3d3e90ce9e18727e8843ae343eda5a58fad6</id>
<content type='text'>
The commit referenced in the Fixes tag incorrectly accounted the number
of in-flight fds over a unix domain socket to the original opener
of the file-descriptor. This allows another process to arbitrary
deplete the original file-openers resource limit for the maximum of
open files. Instead the sending processes and its struct cred should
be credited.

To do so, we add a reference counted struct user_struct pointer to the
scm_fp_list and use it to account for the number of inflight unix fds.

Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
Reported-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Cc: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: drop write-only stack variable</title>
<updated>2016-02-07T19:06:26+00:00</updated>
<author>
<name>David Herrmann</name>
<email>dh.herrmann@gmail.com</email>
</author>
<published>2016-02-02T17:17:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3575dbf2cbbc8e598f17ec441aed526dbea0e1bd'/>
<id>urn:sha1:3575dbf2cbbc8e598f17ec441aed526dbea0e1bd</id>
<content type='text'>
Remove a write-only stack variable from unix_attach_fds(). This is a
left-over from the security fix in:

    commit 712f4aad406bb1ed67f3f98d04c044191f0ff593
    Author: willy tarreau &lt;w@1wt.eu&gt;
    Date:   Sun Jan 10 07:54:56 2016 +0100

        unix: properly account for FDs passed over unix sockets

Signed-off-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_unix: fix struct pid memory leak</title>
<updated>2016-01-25T06:04:49+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2016-01-24T21:53:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fa0dc04df259ba2df3ce1920e9690c7842f8fa4b'/>
<id>urn:sha1:fa0dc04df259ba2df3ce1920e9690c7842f8fa4b</id>
<content type='text'>
Dmitry reported a struct pid leak detected by a syzkaller program.

Bug happens in unix_stream_recvmsg() when we break the loop when a
signal is pending, without properly releasing scm.

Fixes: b3ca9b02b007 ("net: fix multithreaded signal handling in unix recv routines")
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Rainer Weikusat &lt;rweikusat@mobileactivedefense.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2016-01-12T04:55:43+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2016-01-12T04:55:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9d367eddf363553c7668ba92c3b9d187ec4f71f7'/>
<id>urn:sha1:9d367eddf363553c7668ba92c3b9d187ec4f71f7</id>
<content type='text'>
Conflicts:
	drivers/net/bonding/bond_main.c
	drivers/net/ethernet/mellanox/mlxsw/spectrum.h
	drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c

The bond_main.c and mellanox switch conflicts were cases of
overlapping changes.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>unix: properly account for FDs passed over unix sockets</title>
<updated>2016-01-11T05:05:30+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2016-01-10T06:54:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=712f4aad406bb1ed67f3f98d04c044191f0ff593'/>
<id>urn:sha1:712f4aad406bb1ed67f3f98d04c044191f0ff593</id>
<content type='text'>
It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.

This change addresses this problem by keeping track of the number of FDs
in flight per user and preventing non-privileged processes from having
more FDs in flight than their configured FD limit.

Reported-by: socketpair@gmail.com
Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
