<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v3.2.57</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.2.57</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.2.57'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2014-04-09T01:20:47+00:00</updated>
<entry>
<title>Linux 3.2.57</title>
<updated>2014-04-09T01:20:47+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-04-09T01:20:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a2601fcca1caa1645a8bf6c7719ec9e41f590a28'/>
<id>urn:sha1:a2601fcca1caa1645a8bf6c7719ec9e41f590a28</id>
<content type='text'>
</content>
</entry>
<entry>
<title>s390: fix kernel crash due to linkage stack instructions</title>
<updated>2014-04-09T01:20:46+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2014-02-03T16:37:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1664028240024d96721a5328c93ff206661cd9e1'/>
<id>urn:sha1:1664028240024d96721a5328c93ff206661cd9e1</id>
<content type='text'>
commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream.

The kernel currently crashes with a low-address-protection exception
if a user space process executes an instruction that tries to use the
linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
of the dispatchable-unit-control-table to point to a dummy ASTE.
Set up control register 15 to point to an empty linkage stack with no
room left.

A user space process with a linkage stack instruction will still crash
but with a different exception which is correctly translated to a
segmentation fault instead of a kernel oops.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>cifs: ensure that uncached writes handle unmapped areas correctly</title>
<updated>2014-04-09T01:20:46+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2014-02-14T12:20:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b1a292f3ccbbfe864cb4931e8fed4baea6b17eb8'/>
<id>urn:sha1:b1a292f3ccbbfe864cb4931e8fed4baea6b17eb8</id>
<content type='text'>
commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream.

It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069

cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata-&gt;tailsz, which will confuse the sending routines and
cause an oops at the very least.

Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.

[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
       v2.6.38 may have a similar problem and may need similar fix]

Reviewed-by: Pavel Shilovsky &lt;piastry@etersoft.ru&gt;
Reported-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
[bwh: Backported to 3.2:
 - Adjust context
 - s/nr_pages/npages/
 - s/wdata-&gt;pages/pages/
 - In case of an error with no data copied, we must kunmap() page 0,
   but in neither case should we free anything else]
 Thanks to Raphael Geissert for an independent backport that showed some
 bugs in my first version.]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: VMX: fix use after free of vmx-&gt;loaded_vmcs</title>
<updated>2014-04-09T01:20:46+00:00</updated>
<author>
<name>Marcelo Tosatti</name>
<email>mtosatti@redhat.com</email>
</author>
<published>2014-01-03T19:00:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f5652b31f13ab198ed6802349d6b472e222596c2'/>
<id>urn:sha1:f5652b31f13ab198ed6802349d6b472e222596c2</id>
<content type='text'>
commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx-&gt;loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx-&gt;loaded_vmcs.

Switch the order to avoid the problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1047892

Reviewed-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: MMU: handle invalid root_hpa at __direct_map</title>
<updated>2014-04-09T01:20:46+00:00</updated>
<author>
<name>Marcelo Tosatti</name>
<email>mtosatti@redhat.com</email>
</author>
<published>2013-12-19T17:28:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=738638c53d523683bc4b761be9a58da843f26a10'/>
<id>urn:sha1:738638c53d523683bc4b761be9a58da843f26a10</id>
<content type='text'>
commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:

1) try_async_pf -&gt; can_do_async_pf
    -&gt; vmx_interrupt_allowed -&gt; nested_vmx_vmexit
2) vmx_handle_exit -&gt; vmx_interrupt_allowed -&gt; nested_vmx_vmexit

Then to load_vmcs12_host_state and kvm_mmu_reset_context.

Check for this possibility, let fault exception be regenerated.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916

Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>net: asix: add missing flag to struct driver_info</title>
<updated>2014-04-09T01:20:46+00:00</updated>
<author>
<name>Emil Goode</name>
<email>emilgoode@gmail.com</email>
</author>
<published>2014-02-13T18:30:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=615139289271610f38aa0b23f36583cee9afc7e5'/>
<id>urn:sha1:615139289271610f38aa0b23f36583cee9afc7e5</id>
<content type='text'>
commit d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.

The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.

Signed-off-by: Emil Goode &lt;emilgoode@gmail.com&gt;
Reported-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>net: asix: handle packets crossing URB boundaries</title>
<updated>2014-04-09T01:20:45+00:00</updated>
<author>
<name>Emil Goode</name>
<email>emilgoode@gmail.com</email>
</author>
<published>2014-03-31T15:41:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbc321cec0e7dee2b06c86026b73c1562dc32c39'/>
<id>urn:sha1:bbc321cec0e7dee2b06c86026b73c1562dc32c39</id>
<content type='text'>
commit 8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.

ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
header may now cross URB boundaries. To handle this we have to introduce
some state between individual calls to asix_rx_fixup().

Signed-off-by: Lucas Stach &lt;dev@lynxeye.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[ Emil: backported to 3.2:
 - dropped changes to drivers/net/usb/ax88172a.c 
 - Introduced some static function declarations as the functions
   are not used outside of asix.c (sparse is complaining about it) ]
Signed-off-by: Emil Goode &lt;emilgoode@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>asix: asix_rx_fixup surgery to reduce skb truesizes</title>
<updated>2014-04-09T01:20:45+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2012-03-14T20:18:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a94c450fea945252e3beebacacd5d3b913f38f4b'/>
<id>urn:sha1:a94c450fea945252e3beebacacd5d3b913f38f4b</id>
<content type='text'>
commit a9e0aca4b37885b5599e52211f098bd7f565e749 upstream.

asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)

Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.

Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)

With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Aurelien Jacobs &lt;aurel@gnuage.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Trond Wuellner &lt;trond@chromium.org&gt;
Cc: Grant Grundler &lt;grundler@chromium.org&gt;
Cc: Paul Stewart &lt;pstew@chromium.org&gt;
Reviewed-by: Grant Grundler &lt;grundler@chromium.org&gt;
Reviewed-by: Grant Grundler &lt;grundler@chromium.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[ Emil: Backported to 3.2: fixed small conflict ]
Signed-off-by: Emil Goode &lt;emilgoode@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>deb-pkg: Fix cross-building linux-headers package</title>
<updated>2014-04-09T01:20:45+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2013-12-05T14:37:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9be2956736261b04b270bcd9746b80c872ef4934'/>
<id>urn:sha1:9be2956736261b04b270bcd9746b80c872ef4934</id>
<content type='text'>
commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture.  This
breaks cross-building configurations.  We should use $debarch for this
instead.

Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.

Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." &lt;shniew@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
</content>
</entry>
<entry>
<title>deb-pkg: Fix building for MIPS big-endian or ARM OABI</title>
<updated>2014-04-09T01:20:45+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2013-12-05T14:39:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=448a779f01583c6fda27d4229641615fdedfb4c5'/>
<id>urn:sha1:448a779f01583c6fda27d4229641615fdedfb4c5</id>
<content type='text'>
commit c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream.

These commands will mysteriously fail:

$ make ARCH=arm versatile_defconfig
[...]
$ make ARCH=arm deb-pkg
[...]
make[1]: *** [deb-pkg] Error 1
make: *** [deb-pkg] Error 2

The Debian architecture selection for these kernel architectures does
'grep FOO=y $KCONFIG_CONFIG &amp;&amp; echo bar', and after 'set -e' this
aborts the script if grep does not find the given config symbol.

Fixes: 10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE')
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
</content>
</entry>
</feed>
