user/sven/linux.git, branch v3.2.69

Linux 3.2.69

2015-05-09T22:16:42Z

Revert "KVM: s390: flush CPU on load control"

2015-05-09T22:16:41Z

This reverts commit 823f14022fd2335affc8889a9c7e1b60258883a3, which was commit 2dca485f8740208604543c3960be31a5dd3ea603 upstream. It depends on functionality that is not present in 3.2.y. Signed-off-by: Ben Hutchings Cc: Christian Borntraeger

ipvs: uninitialized data with IP_VS_IPV6

2015-05-09T22:16:41Z

commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream. The app_tcp_pkt_out() function expects "*diff" to be set and ends up using uninitialized data if CONFIG_IP_VS_IPV6 is turned on. The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov for noticing that. Signed-off-by: Dan Carpenter Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings Cc: Pablo Neira Ayuso

ipvs: rerouting to local clients is not needed anymore

2015-05-09T22:16:40Z

commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream. commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP") from 2.6.37 introduced ip_route_me_harder() call for responses to local clients, so that we can provide valid rt_src after SNAT. It was used by TCP to provide valid daddr for ip_send_reply(). After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to ip_send_reply()." from 3.0 this rerouting is not needed anymore and should be avoided, especially in LOCAL_IN. Fixes 3.12.33 crash in xfrm reported by Florian Wiessner: "3.12.33 - BUG xfrm_selector_match+0x25/0x2f6" Reported-by: Smart Weblications GmbH - Florian Wiessner Tested-by: Smart Weblications GmbH - Florian Wiessner Signed-off-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings Cc: Pablo Neira Ayuso

IB/core: Avoid leakage from kernel to user space

2015-05-09T22:16:40Z

commit 377b513485fd885dea1083a9a5430df65b35e048 upstream. Clear the reserved field of struct ib_uverbs_async_event_desc which is copied to user space. Signed-off-by: Eli Cohen Reviewed-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings Cc: Yann Droneaud

spi: spidev: fix possible arithmetic overflow for multi-transfer message

2015-05-09T22:16:40Z

commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream. `spidev_message()` sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value. Thanks to Dan Carpenter for reporting the potential integer overflow. Signed-off-by: Ian Abbott Signed-off-by: Mark Brown [Ian Abbott: Note: original commit compares the lengths to INT_MAX instead of bufsiz due to changes in earlier commits.] Signed-off-by: Ben Hutchings

net: make skb_gso_segment error handling more robust

2015-05-09T22:16:40Z

commit 330966e501ffe282d7184fde4518d5e0c24bc7f8 upstream. skb_gso_segment has three possible return values: 1. a pointer to the first segmented skb 2. an errno value (IS_ERR()) 3. NULL. This can happen when GSO is used for header verification. However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL and would oops when NULL is returned. Note that these call sites should never actually see such a NULL return value; all callers mask out the GSO bits in the feature argument. However, there have been issues with some protocol handlers erronously not respecting the specified feature mask in some cases. It is preferable to get 'have to turn off hw offloading, else slow' reports rather than 'kernel crashes'. Signed-off-by: Florian Westphal Signed-off-by: David S. Miller [Brad Spengler: backported to 3.2] Signed-off-by: Brad Spengler Signed-off-by: Ben Hutchings

tcp: avoid looping in tcp_send_fin()

2015-05-09T22:16:40Z

[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ] Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets. Lets try a different strategy : In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation. By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory. In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Drop inapplicable change to sk_forced_wmem_schedule() - s/sk_under_memory_pressure(sk)/tcp_memory_pressure/] Signed-off-by: Ben Hutchings

ip_forward: Drop frames with attached skb->sk

2015-05-09T22:16:40Z

[ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ] Initial discussion was: [FYI] xfrm: Don't lookup sk_policy for timewait sockets Forwarded frames should not have a socket attached. Especially tw sockets will lead to panics later-on in the stack. This was observed with TPROXY assigning a tw socket and broken policy routing (misconfigured). As a result frame enters forwarding path instead of input. We cannot solve this in TPROXY as it cannot know that policy routing is broken. v2: Remove useless comment Signed-off-by: Sebastian Poehn Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

gianfar: Carefully free skbs in functions called by netpoll.

2015-05-09T22:16:40Z

commit c9974ad4aeb36003860100221a594f3c0ccc3f78 upstream. netpoll can call functions in hard irq context that are ordinarily called in lesser contexts. For those functions use dev_kfree_skb_any and dev_consume_skb_any so skbs are freed safely from hard irq context. Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller [bwh: Backported to 3.2: use only dev_kfree_skb() and not dev_consume_skb_any()] Signed-off-by: Ben Hutchings