<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include, branch v3.10.46</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include?h=v3.10.46</id>
<link rel='self' href='https://git.amat.us/linux/atom/include?h=v3.10.46'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-07-01T03:09:45Z</updated>
<entry>
<title>genirq: Sanitize spurious interrupt detection of threaded irqs</title>
<updated>2014-07-01T03:09:45Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2013-03-07T13:53:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=72aeabd74a7154d560efcd14afa0244f4393cf8b'/>
<id>urn:sha1:72aeabd74a7154d560efcd14afa0244f4393cf8b</id>
<content type='text'>
commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann &lt;strauman@slac.stanford.edu&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Cc: Pavel Pisa &lt;pisa@cmp.felk.cvut.cz&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Report correct response length for some commands</title>
<updated>2014-07-01T03:09:45Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2014-06-10T18:07:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=be03ed7ca0bd65ced3cc033587c9034bd2eedc0b'/>
<id>urn:sha1:be03ed7ca0bd65ced3cc033587c9034bd2eedc0b</id>
<content type='text'>
commit 2426bd456a61407388b6e61fc5f98dbcbebc50e2 upstream.

When an initiator sends an allocation length bigger than what its
command consumes, the target should only return the actual response data
and set the residual length to the unused part of the allocation length.

Add a helper function that command handlers (INQUIRY, READ CAPACITY,
etc) can use to do this correctly, and use this code to get the correct
residual for commands that don't use the full initiator allocation in the
handlers for READ CAPACITY, READ CAPACITY(16), INQUIRY, MODE SENSE and
REPORT LUNS.

This addresses a handful of failures as reported by Christophe with
the Windows Certification Kit:

  http://permalink.gmane.org/gmane.linux.scsi.target.devel/6515

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Tested-by: Christophe Vu-Brugier &lt;cvubrugier@yahoo.fr&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ptrace: fix fork event messages across pid namespaces</title>
<updated>2014-07-01T03:09:42Z</updated>
<author>
<name>Matthew Dempsky</name>
<email>mdempsky@chromium.org</email>
</author>
<published>2014-06-06T21:36:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1a2d973242a5ce1baec9dbef62548b7095b7f5aa'/>
<id>urn:sha1:1a2d973242a5ce1baec9dbef62548b7095b7f5aa</id>
<content type='text'>
commit 4e52365f279564cef0ddd41db5237f0471381093 upstream.

When tracing a process in another pid namespace, it's important for fork
event messages to contain the child's pid as seen from the tracer's pid
namespace, not the parent's.  Otherwise, the tracer won't be able to
correlate the fork event with later SIGTRAP signals it receives from the
child.

We still risk a race condition if a ptracer from a different pid
namespace attaches after we compute the pid_t value.  However, sending a
bogus fork event message in this unlikely scenario is still a vast
improvement over the status quo where we always send bogus fork event
messages to debuggers in a different pid namespace than the forking
process.

Signed-off-by: Matthew Dempsky &lt;mdempsky@chromium.org&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Julien Tinnes &lt;jln@chromium.org&gt;
Cc: Roland McGrath &lt;mcgrathr@chromium.org&gt;
Cc: Jan Kratochvil &lt;jan.kratochvil@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: control: Protect user controls against concurrent access</title>
<updated>2014-06-26T19:12:43Z</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2014-06-18T11:32:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=be3bae536eaf0a98926006a8ec00417a48b6a587'/>
<id>urn:sha1:be3bae536eaf0a98926006a8ec00417a48b6a587</id>
<content type='text'>
commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream.

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Acked-by: Jaroslav Kysela &lt;perex@perex.cz&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: compress: Cancel the optimization of compiler and fix the size of struct for all platform.</title>
<updated>2014-06-26T19:12:41Z</updated>
<author>
<name>Wang, Xiaoming</name>
<email>xiaoming.wang@intel.com</email>
</author>
<published>2014-06-12T22:47:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d2c44167ecbabae2c55f4777f351203282cb8ab2'/>
<id>urn:sha1:d2c44167ecbabae2c55f4777f351203282cb8ab2</id>
<content type='text'>
commit 2bd0ae464a6cf7363bbf72c8545e0aa43caa57f0 upstream.

Cancel the optimization of compiler for struct snd_compr_avail
which size will be 0x1c in 32bit kernel while 0x20 in 64bit
kernel under the optimizer. That will make compaction between
32bit and 64bit. So add packed to fix the size of struct
snd_compr_avail to 0x1c for all platform.

Signed-off-by: Zhang Dongxing &lt;dongxing.zhang@intel.com&gt;
Signed-off-by: xiaoming wang &lt;xiaoming.wang@intel.com&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>team: fix mtu setting</title>
<updated>2014-06-26T19:12:38Z</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2014-05-29T18:46:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=35f8524540ad82b1af784ebd7002753ffb8e953c'/>
<id>urn:sha1:35f8524540ad82b1af784ebd7002753ffb8e953c</id>
<content type='text'>
[ Upstream commit 9d0d68faea6962d62dd501cd6e71ce5cc8ed262b ]

Now it is not possible to set mtu to team device which has a port
enslaved to it. The reason is that when team_change_mtu() calls
dev_set_mtu() for port device, notificator for NETDEV_PRECHANGEMTU
event is called and team_device_event() returns NOTIFY_BAD forbidding
the change. So fix this by returning NOTIFY_DONE here in case team is
changing mtu in team_change_mtu().

Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Acked-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: fix inet_getid() and ipv6_select_ident() bugs</title>
<updated>2014-06-26T19:12:38Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-05-29T15:45:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=25bc3126ccbe553b5cc293ca9c77d44bb40ff62d'/>
<id>urn:sha1:25bc3126ccbe553b5cc293ca9c77d44bb40ff62d</id>
<content type='text'>
[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]

I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer-&gt;ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>netlink: Only check file credentials for implicit destinations</title>
<updated>2014-06-26T19:12:37Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-05-30T18:04:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8ab02acdf274cbd6b10f7dd990f42c9b40469141'/>
<id>urn:sha1:8ab02acdf274cbd6b10f7dd990f42c9b40469141</id>
<content type='text'>
[ Upstream commit 2d7a85f4b06e9c27ff629f07a524c48074f07f81 ]

It was possible to get a setuid root or setcap executable to write to
it's stdout or stderr (which has been set made a netlink socket) and
inadvertently reconfigure the networking stack.

To prevent this we check that both the creator of the socket and
the currentl applications has permission to reconfigure the network
stack.

Unfortunately this breaks Zebra which always uses sendto/sendmsg
and creates it's socket without any privileges.

To keep Zebra working don't bother checking if the creator of the
socket has privilege when a destination address is specified.  Instead
rely exclusively on the privileges of the sender of the socket.

Note from Andy: This is exactly Eric's code except for some comment
clarifications and formatting fixes.  Neither I nor, I think, anyone
else is thrilled with this approach, but I'm hesitant to wait on a
better fix since 3.15 is almost here.

Note to stable maintainers: This is a mess.  An earlier series of
patches in 3.15 fix a rather serious security issue (CVE-2014-0181),
but they did so in a way that breaks Zebra.  The offending series
includes:

    commit aa4cf9452f469f16cea8c96283b641b4576d4a7b
    Author: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
    Date:   Wed Apr 23 14:28:03 2014 -0700

        net: Add variants of capable for use on netlink messages

If a given kernel version is missing that series of fixes, it's
probably worth backporting it and this patch.  if that series is
present, then this fix is critical if you care about Zebra.

Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: Add variants of capable for use on netlink messages</title>
<updated>2014-06-26T19:12:37Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-04-23T21:28:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=738f378d77b04f685f2cd01aa4240d1bce5c9668'/>
<id>urn:sha1:738f378d77b04f685f2cd01aa4240d1bce5c9668</id>
<content type='text'>
[ Upstream commit aa4cf9452f469f16cea8c96283b641b4576d4a7b ]

netlink_net_capable - The common case use, for operations that are safe on a network namespace
netlink_capable - For operations that are only known to be safe for the global root
netlink_ns_capable - The general case of capable used to handle special cases

__netlink_ns_capable - Same as netlink_ns_capable except taking a netlink_skb_parms instead of
		       the skbuff of a netlink message.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: Add variants of capable for use on on sockets</title>
<updated>2014-06-26T19:12:37Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-04-23T21:26:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c35b4e287f5ede32bae6db1aef1ae3e9174bb2ff'/>
<id>urn:sha1:c35b4e287f5ede32bae6db1aef1ae3e9174bb2ff</id>
<content type='text'>
[ Upstream commit a3b299da869d6e78cf42ae0b1b41797bcb8c5e4b ]

sk_net_capable - The common case, operations that are safe in a network namespace.
sk_capable - Operations that are not known to be safe in a network namespace
sk_ns_capable - The general case for special cases.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
