commit fad79858d2f2d8d18c3a1a4d1f4bb87a0c49b1d1 Author: Ben Hutchings Date: Sun May 1 00:05:28 2016 +0200 Linux 3.2.80 commit 985970fd0118576d9853d1d1a9c4309ae4d248bb Author: Florian Westphal Date: Tue Mar 22 18:02:52 2016 +0100 netfilter: x_tables: fix unconditional helper commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream. Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that mark_source_chains should not have been called -- the rule doesn't have a next entry, so its supposed to return an absolute verdict of either ACCEPT or DROP. However, the function conditional() doesn't work as the name implies. It only checks that the rule is using wildcard address matching. However, an unconditional rule must also not be using any matches (no -m args). The underflow validator only checked the addresses, therefore passing the 'unconditional absolute verdict' test, while mark_source_chains also tested for presence of matches, and thus proceeeded to the next (not-existent) rule. Unify this so that all the callers have same idea of 'unconditional rule'. Reported-by: Ben Hawkes Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Ben Hutchings commit c424794bbb79a8127eccecaf2b48f1784772ac7a Author: Guo-Fu Tseng Date: Sat Mar 5 08:11:56 2016 +0800 jme: Fix device PM wakeup API usage commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream. According to Documentation/power/devices.txt The driver should not use device_set_wakeup_enable() which is the policy for user to decide. Using device_init_wakeup() to initialize dev->power.should_wakeup and dev->power.can_wakeup on driver initialization. And use device_may_wakeup() on suspend to decide if WoL function should be enabled on NIC. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5d90b35f7350a307a890fc5efaecf3e411c718e3 Author: Guo-Fu Tseng Date: Sat Mar 5 08:11:55 2016 +0800 jme: Do not enable NIC WoL functions on S0 commit 0772a99b818079e628a1da122ac7ee023faed83e upstream. Otherwise it might be back on resume right after going to suspend in some hardware. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 429c3307b4fe47204e4de3e61b943d63cfcda743 Author: Jakub Sitnicki Date: Tue Apr 5 18:41:08 2016 +0200 ipv6: Count in extension headers in skb->network_header [ Upstream commit 3ba3458fb9c050718b95275a3310b74415e767e2 ] When sending a UDPv6 message longer than MTU, account for the length of fragmentable IPv6 extension headers in skb->network_header offset. Same as we do in alloc_new_skb path in __ip6_append_data(). This ensures that later on __ip6_make_skb() will make space in headroom for fragmentable extension headers: /* move skb->data to ip header from ext header */ if (skb->data < skb_network_header(skb)) __skb_pull(skb, skb_network_offset(skb)); Prevents a splat due to skb_under_panic: skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \ head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] KASAN CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65 [...] Call Trace: [] skb_push+0x79/0x80 [] eth_header+0x2b/0x100 [] neigh_resolve_output+0x210/0x310 [] ip6_finish_output2+0x4a7/0x7c0 [] ip6_output+0x16a/0x280 [] ip6_local_out+0xb1/0xf0 [] ip6_send_skb+0x45/0xd0 [] udp_v6_send_skb+0x246/0x5d0 [] udpv6_sendmsg+0xa6e/0x1090 [...] Reported-by: Ji Jianwen Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit f56bbe05031ec62fed752671fdf510cc202b67cf Author: Haishuang Yan Date: Sun Apr 3 22:09:23 2016 +0800 ipv4: l2tp: fix a potential issue in l2tp_ip_recv [ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ] pskb_may_pull() can change skb->data, so we have to load ptr/optr at the right place. Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 8b59e5023e8255a91418bd7831b5ef03621499d5 Author: subashab@codeaurora.org Date: Wed Mar 23 22:39:50 2016 -0600 xfrm: Fix crash observed during device unregistration and decryption [ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ] A crash is observed when a decrypted packet is processed in receive path. get_rps_cpus() tries to dereference the skb->dev fields but it appears that the device is freed from the poison pattern. [] get_rps_cpu+0x94/0x2f0 [] netif_rx_internal+0x140/0x1cc [] netif_rx+0x74/0x94 [] xfrm_input+0x754/0x7d0 [] xfrm_input_resume+0x10/0x1c [] esp_input_done+0x20/0x30 [] process_one_work+0x244/0x3fc [] worker_thread+0x2f8/0x418 [] kthread+0xe0/0xec -013|get_rps_cpu( | dev = 0xFFFFFFC08B688000, | skb = 0xFFFFFFC0C76AAC00 -> ( | dev = 0xFFFFFFC08B688000 -> ( | name = "...................................................... | name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev = 0xAAAAAAAAAAA Following are the sequence of events observed - - Encrypted packet in receive path from netdevice is queued - Encrypted packet queued for decryption (asynchronous) - Netdevice brought down and freed - Packet is decrypted and returned through callback in esp_input_done - Packet is queued again for process in network stack using netif_rx Since the device appears to have been freed, the dereference of skb->dev in get_rps_cpus() leads to an unhandled page fault exception. Fix this by holding on to device reference when queueing packets asynchronously and releasing the reference on call back return. v2: Make the change generic to xfrm as mentioned by Steffen and update the title to xfrm Suggested-by: Herbert Xu Signed-off-by: Jerome Stanislaus Signed-off-by: Subash Abhinov Kasiviswanathan Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit eccb4a6e115459ae3063eb67f0e44e9ac53dc1c2 Author: Manish Chopra Date: Tue Mar 15 07:13:45 2016 -0400 qlge: Fix receive packets drop. [ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ] When running small packets [length < 256 bytes] traffic, packets were being dropped due to invalid data in those packets which were delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu ensures copying latest and updated data into skb from the receive buffer. Signed-off-by: Sony Chacko Signed-off-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 286749896d272a60a75c9897f6fe60f42d60747f Author: Arnd Bergmann Date: Mon Mar 14 15:18:35 2016 +0100 farsync: fix off-by-one bug in fst_add_one [ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ] gcc-6 finds an out of bounds access in the fst_add_one function when calculating the end of the mmio area: drivers/net/wan/farsync.c: In function 'fst_add_one': drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds] #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^ include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof' __builtin_offsetof(a, b) ^ drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof' #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^~~~~~~~ drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET' + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]); ^~~~~~~~~~ The warning is correct, but not critical because this appears to be a write-only variable that is set by each WAN driver but never accessed afterwards. I'm taking the minimal fix here, using the correct pointer by pointing 'mem_end' to the last byte inside of the register area as all other WAN drivers do, rather than the first byte outside of it. An alternative would be to just remove the mem_end member entirely. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 283c01d3fe7b9458e394155c2f9bb24c82524bde Author: Willem de Bruijn Date: Tue Mar 8 15:18:54 2016 -0500 macvtap: always pass ethernet header in linear [ Upstream commit 8e2ad4113ce4671686740f808ff2795395c39eef ] The stack expects link layer headers in the skb linear section. Macvtap can create skbs with llheader in frags in edge cases: when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and prepad + len > PAGE_SIZE and vnet_hdr.flags has no or bad csum. Add checks to ensure linear is always at least ETH_HLEN. At this point, len is already ensured to be >= ETH_HLEN. For backwards compatiblity, rounds up short vnet_hdr.hdr_len. This differs from tap and packet, which return an error. Fixes b9fb9ee07e67 ("macvtap: add GSO/csum offload support") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller [bwh: Backported to 3.2: don't use macvtap16_to_cpu()] Signed-off-by: Ben Hutchings commit 6e0784b636cc75d81c870fde19cfbd7a58267edf Author: Sergei Shtylyov Date: Tue Mar 8 01:36:28 2016 +0300 sh_eth: fix NULL pointer dereference in sh_eth_ring_format() [ Upstream commit c1b7fca65070bfadca94dd53a4e6b71cd4f69715 ] In a low memory situation, if netdev_alloc_skb() fails on a first RX ring loop iteration in sh_eth_ring_format(), 'rxdesc' is still NULL. Avoid kernel oops by adding the 'rxdesc' check after the loop. Reported-by: Wolfram Sang Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0954b59d9f4b2dcc59f28d1f64c3a21062a64372 Author: Willem de Bruijn Date: Wed Mar 9 21:58:33 2016 -0500 ax25: add link layer header validation function [ Upstream commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa ] As variable length protocol, AX25 fails link layer header validation tests based on a minimum length. header_ops.validate allows protocols to validate headers that are shorter than hard_header_len. Implement this callback for AX25. See also http://comments.gmane.org/gmane.linux.network/401064 Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b5518429e70cd783b8ca52335456172c1a0589f6 Author: Willem de Bruijn Date: Wed Mar 9 21:58:32 2016 -0500 net: validate variable length ll headers [ Upstream commit 2793a23aacbd754dbbb5cb75093deb7e4103bace ] Netdevice parameter hard_header_len is variously interpreted both as an upper and lower bound on link layer header length. The field is used as upper bound when reserving room at allocation, as lower bound when validating user input in PF_PACKET. Clarify the definition to be maximum header length. For validation of untrusted headers, add an optional validate member to header_ops. Allow bypassing of validation by passing CAP_SYS_RAWIO, for instance for deliberate testing of corrupt input. In this case, pad trailing bytes, as some device drivers expect completely initialized headers. See also http://comments.gmane.org/gmane.linux.network/401064 Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller [bwh: Backported to 3.2: net_device has inline comments instead of kernel-doc] Signed-off-by: Ben Hutchings commit 8b4375878ae845a8b5e672cdcf7e38dcfdef508e Author: Bjørn Mork Date: Thu Mar 3 22:20:53 2016 +0100 cdc_ncm: toggle altsetting to force reset before setup [ Upstream commit 48906f62c96cc2cd35753e59310cb70eb08cc6a5 ] Some devices will silently fail setup unless they are reset first. This is necessary even if the data interface is already in altsetting 0, which it will be when the device is probed for the first time. Briefly toggling the altsetting forces a function reset regardless of the initial state. This fixes a setup problem observed on a number of Huawei devices, appearing to operate in NTB-32 mode even if we explicitly set them to NTB-16 mode. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller [bwh: Backported to 3.2: hard-code 1 for data_altsetting] Signed-off-by: Ben Hutchings commit ceae7c032f44ba08de4a325100b77bc9abdc0fbd Author: Xin Long Date: Sun Feb 28 10:03:51 2016 +0800 sctp: lack the check for ports in sctp_v6_cmp_addr [ Upstream commit 40b4f0fd74e46c017814618d67ec9127ff20f157 ] As the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check the port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by sctp_cmp_addr_exact(). Now sctp_v6_cmp_addr just check the port when two addresses have different family, and lack the port check for two ipv6 addresses. that will make sctp_hash_cmp() cannot work well. so fix it by adding ports comparison in sctp_v6_cmp_addr(). Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 29238febcfd1a1c4e6c4f8473896a664dfdc869f Author: Diego Viola Date: Tue Feb 23 12:04:04 2016 -0300 net: jme: fix suspend/resume on JMC260 [ Upstream commit ee50c130c82175eaa0820c96b6d3763928af2241 ] The JMC260 network card fails to suspend/resume because the call to jme_start_irq() was too early, moving the call to jme_start_irq() after the call to jme_reset_link() makes it work. Prior this change suspend/resume would fail unless /sys/power/pm_async=0 was explicitly specified. Relevant bug report: https://bugzilla.kernel.org/show_bug.cgi?id=112351 Signed-off-by: Diego Viola Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 6bd428ff0eddf816393f30e0fca877f509affb57 Author: Geert Uytterhoeven Date: Mon Apr 4 16:36:25 2016 +0200 serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream. The BSP team noticed that there is spin/mutex lock issue on sh-sci when CPUFREQ is used. The issue is that the notifier function may call mutex_lock() while the spinlock is held, which can lead to a BUG(). This may happen if CPUFREQ is changed while another CPU calls clk_get_rate(). Taking the spinlock was added to the notifier function in commit e552de2413edad1a ("sh-sci: add platform device private data"), to protect the list of serial ports against modification during traversal. At that time the Common Clock Framework didn't exist yet, and clk_get_rate() just returned clk->rate without taking a mutex. Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a device per port mapping."), there's no longer a list of serial ports to traverse, and taking the spinlock became superfluous. To fix the issue, just remove the cpufreq notifier: 1. The notifier doesn't work correctly: all it does is update the stored clock rate; it does not update the divider in the hardware. The divider will only be updated when calling sci_set_termios(). I believe this was broken back in 2004, when the old drivers/char/sh-sci.c driver (where the notifier did update the divider) was replaced by drivers/serial/sh-sci.c (where the notifier just updated port->uartclk). Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH] Remove old sh-sci driver"). 2. On modern SoCs, the sh-sci parent clock rate is no longer related to the CPU clock rate anyway, so using a cpufreq notifier is futile. Signed-off-by: Geert Uytterhoeven [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6253ea8e80a4773ffe970a2c96b0f92b61f2452b Author: Hannes Reinecke Date: Fri Feb 12 09:39:15 2016 +0100 bio: return EINTR if copying to user space got interrupted commit 2d99b55d378c996b9692a0c93dd25f4ed5d58934 upstream. Commit 35dc248383bbab0a7203fca4d722875bc81ef091 introduced a check for current->mm to see if we have a user space context and only copies data if we do. Now if an IO gets interrupted by a signal data isn't copied into user space any more (as we don't have a user space context) but user space isn't notified about it. This patch modifies the behaviour to return -EINTR from bio_uncopy_user() to notify userland that a signal has interrupted the syscall, otherwise it could lead to a situation where the caller may get a buffer with no data returned. This can be reproduced by issuing SG_IO ioctl()s in one thread while constantly sending signals to it. Fixes: 35dc248 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal Signed-off-by: Johannes Thumshirn Signed-off-by: Hannes Reinecke Signed-off-by: Jens Axboe [bwh: Backported to 3.2: - Adjust filename - Put the assignment in the existing 'else' block] Signed-off-by: Ben Hutchings commit 8964ed98495ed1758a2ac4a5de32c86ec664cfcd Author: Neil Horman Date: Thu Feb 18 16:10:57 2016 -0500 sctp: Fix port hash table size computation [ Upstream commit d9749fb5942f51555dc9ce1ac0dbb1806960a975 ] Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in its size computation, observing that the current method never guaranteed that the hashsize (measured in number of entries) would be a power of two, which the input hash function for that table requires. The root cause of the problem is that two values need to be computed (one, the allocation order of the storage requries, as passed to __get_free_pages, and two the number of entries for the hash table). Both need to be ^2, but for different reasons, and the existing code is simply computing one order value, and using it as the basis for both, which is wrong (i.e. it assumes that ((1< Reported-by: Dmitry Vyukov CC: Dmitry Vyukov CC: Vladislav Yasevich CC: "David S. Miller" Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7a00475cff7c92157b60a8a135913cca9232c5f6 Author: Guillaume Nault Date: Mon Feb 15 17:01:10 2016 +0100 pppoe: fix reference counting in PPPoE proxy [ Upstream commit 29e73269aa4d36f92b35610c25f8b01c789b0dc8 ] Drop reference on the relay_po socket when __pppoe_xmit() succeeds. This is already handled correctly in the error path. Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 86f1994adf420f3b47409301eb225e77eafc5b12 Author: Eric Dumazet Date: Thu Feb 4 06:23:28 2016 -0800 ipv4: fix memory leaks in ip_cmsg_send() callers [ Upstream commit 919483096bfe75dda338e98d56da91a263746a0a ] Dmitry reported memory leaks of IP options allocated in ip_cmsg_send() when/if this function returns an error. Callers are responsible for the freeing. Many thanks to Dmitry for the report and diagnostic. Reported-by: Dmitry Vyukov Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 619d48665f45c3a9ccadd8cf171cb8ce230900ec Author: Hangbin Liu Date: Thu Jul 30 14:28:42 2015 +0800 net/ipv6: add sysctl option accept_ra_min_hop_limit [ Upstream commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 ] Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface") disabled accept hop limit from RA if it is smaller than the current hop limit for security stuff. But this behavior kind of break the RFC definition. RFC 4861, 6.3.4. Processing Received Router Advertisements A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value. So add sysctl option accept_ra_min_hop_limit to let user choose the minimum hop limit value they can accept from RA. And set default to 1 to meet RFC standards. Signed-off-by: Hangbin Liu Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust filename, context - Number DEVCONF enumerators explicitly to match upstream] Signed-off-by: Ben Hutchings commit cc84cca6a658e456cb4479adb4ff22308fa802d4 Author: Paolo Abeni Date: Fri Jan 29 12:30:20 2016 +0100 ipv6/udp: use sticky pktinfo egress ifindex on connect() [ Upstream commit 1cdda91871470f15e79375991bd2eddc6e86ddb1 ] Currently, the egress interface index specified via IPV6_PKTINFO is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7 can be subverted when the user space application calls connect() before sendmsg(). Fix it by initializing properly flowi6_oif in connect() before performing the route lookup. Signed-off-by: Paolo Abeni Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2f3361f333a5937dd3f20d17a826bf1bb150ea54 Author: Manfred Rudigier Date: Wed Jan 20 11:22:28 2016 +0100 net: dp83640: Fix tx timestamp overflow handling. [ Upstream commit 81e8f2e930fe76b9814c71b9d87c30760b5eb705 ] PHY status frames are not reliable, the PHY may not be able to send them during heavy receive traffic. This overflow condition is signaled by the PHY in the next status frame, but the driver did not make use of it. Instead it always reported wrong tx timestamps to user space after an overflow happened because it assigned newly received tx timestamps to old packets in the queue. This commit fixes this issue by clearing the tx timestamp queue every time an overflow happens, so that no timestamps are delivered for overflow packets. This way time stamping will continue correctly after an overflow. Signed-off-by: Manfred Rudigier Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d942c7354aa7b406403c42ad946157448a9157f3 Author: Ursula Braun Date: Tue Jan 19 10:41:33 2016 +0100 af_iucv: Validate socket address length in iucv_sock_bind() [ Upstream commit 52a82e23b9f2a9e1d429c5207f8575784290d008 ] Signed-off-by: Ursula Braun Reported-by: Dmitry Vyukov Reviewed-by: Evgeny Cherkashin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 58b45f408a8821b6d9f0003c3fdfa179145c90e7 Author: Eric Dumazet Date: Fri Jan 15 04:56:56 2016 -0800 ipv6: update skb->csum when CE mark is propagated [ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ] When a tunnel decapsulates the outer header, it has to comply with RFC 6080 and eventually propagate CE mark into inner header. It turns out IP6_ECN_set_ce() does not correctly update skb->csum for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure" messages and stack traces. Signed-off-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust context - Add skb argument to other callers of IP6_ECN_set_ce()] Signed-off-by: Ben Hutchings commit 37e9e7ac0e4c75dc516aa1f552ad4b2d8b72a89f Author: Eric Dumazet Date: Tue Jan 12 08:58:00 2016 -0800 phonet: properly unshare skbs in phonet_rcv() [ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ] Ivaylo Dimitrov reported a regression caused by commit 7866a621043f ("dev: add per net_device packet type chains"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without major crash. But the root cause is that phonet_rcv() can queue skb without checking if skb is shared or not. Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests. Reported-by: Ivaylo Dimitrov Tested-by: Ivaylo Dimitrov Signed-off-by: Eric Dumazet Cc: Remi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2fdc41c8a852611a3251462e3c8539626ecb3b4f Author: Neal Cardwell Date: Mon Jan 11 13:42:43 2016 -0500 tcp_yeah: don't set ssthresh below 2 [ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ] For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno and CUBIC, per RFC 5681 (equation 4). tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh value if the intended reduction is as big or bigger than the current cwnd. Congestion control modules should never return a zero or negative ssthresh. A zero ssthresh generally results in a zero cwnd, causing the connection to stall. A negative ssthresh value will be interpreted as a u32 and will set a target cwnd for PRR near 4 billion. Oleksandr Natalenko reported that a system using tcp_yeah with ECN could see a warning about a prior_cwnd of 0 in tcp_cwnd_reduction(). Testing verified that this was due to tcp_yeah_ssthresh() misbehaving in this way. Reported-by: Oleksandr Natalenko Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 9def77212c9b8a2e35f28879363cbbbf34923b3d Author: Hannes Frederic Sowa Date: Tue Jan 5 10:46:00 2016 +0100 bridge: Only call /sbin/bridge-stp for the initial network namespace [ Upstream commit ff62198553e43cdffa9d539f6165d3e83f8a42bc ] [I stole this patch from Eric Biederman. He wrote:] > There is no defined mechanism to pass network namespace information > into /sbin/bridge-stp therefore don't even try to invoke it except > for bridge devices in the initial network namespace. > > It is possible for unprivileged users to cause /sbin/bridge-stp to be > invoked for any network device name which if /sbin/bridge-stp does not > guard against unreasonable arguments or being invoked twice on the > same network device could cause problems. [Hannes: changed patch using netns_eq] Cc: Eric W. Biederman Signed-off-by: Eric W. Biederman Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 18cd56e82f3d6bea991345e7584b87d104d327b0 Author: Florian Westphal Date: Thu Dec 31 14:26:33 2015 +0100 connector: bump skb->users before callback invocation [ Upstream commit 55285bf09427c5abf43ee1d54e892f352092b1f1 ] Dmitry reports memleak with syskaller program. Problem is that connector bumps skb usecount but might not invoke callback. So move skb_get to where we invoke the callback. Reported-by: Dmitry Vyukov Signed-off-by: Florian Westphal Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 20d1dcfc4dc4b61b369d0aaa6d412b5a08d7917d Author: Xin Long Date: Tue Dec 29 17:49:25 2015 +0800 sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close [ Upstream commit 068d8bd338e855286aea54e70d1c101569284b21 ] In sctp_close, sctp_make_abort_user may return NULL because of memory allocation failure. If this happens, it will bypass any state change and never free the assoc. The assoc has no chance to be freed and it will be kept in memory with the state it had even after the socket is closed by sctp_close(). So if sctp_make_abort_user fails to allocate memory, we should abort the asoc via sctp_primitive_ABORT as well. Just like the annotation in sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said, "Even if we can't send the ABORT due to low memory delete the TCB. This is a departure from our typical NOMEM handling". But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would dereference the chunk pointer, and system crash. So we should add SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other places where it adds SCTP_CMD_REPLY cmd. Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0a14e6d415c374bc554eb45b7b3fb259c7e665e7 Author: Eryu Guan Date: Sat Mar 12 21:40:32 2016 -0500 ext4: fix NULL pointer dereference in ext4_mark_inode_dirty() commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 upstream. ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is ignored in the following "if" condition and ext4_expand_extra_isize() might be called with NULL iloc.bh set, which triggers NULL pointer dereference. This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for the project quota feature"), which enlarges the ext4_inode size, and run the following script on new kernel but with old mke2fs: #/bin/bash mnt=/mnt/ext4 devname=ext4-error dev=/dev/mapper/$devname fsimg=/home/fs.img trap cleanup 0 1 2 3 9 15 cleanup() { umount $mnt >/dev/null 2>&1 dmsetup remove $devname losetup -d $backend_dev rm -f $fsimg exit 0 } rm -f $fsimg fallocate -l 1g $fsimg backend_dev=`losetup -f --show $fsimg` devsize=`blockdev --getsz $backend_dev` good_tab="0 $devsize linear $backend_dev 0" error_tab="0 $devsize error $backend_dev 0" dmsetup create $devname --table "$good_tab" mkfs -t ext4 $dev mount -t ext4 -o errors=continue,strictatime $dev $mnt dmsetup load $devname --table "$error_tab" && dmsetup resume $devname echo 3 > /proc/sys/vm/drop_caches ls -l $mnt exit 0 [ Patch changed to simplify the function a tiny bit. -- Ted ] Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit d72b450666d8d0ee1dc01911c4193bc27b71af3d Author: David S. Miller Date: Sun Mar 13 23:28:00 2016 -0400 ipv4: Don't do expensive useless work during inetdev destroy. commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 upstream. When an inetdev is destroyed, every address assigned to the interface is removed. And in this scenerio we do two pointless things which can be very expensive if the number of assigned interfaces is large: 1) Address promotion. We are deleting all addresses, so there is no point in doing this. 2) A full nf conntrack table purge for every address. We only need to do this once, as is already caught by the existing masq_dev_notifier so masq_inet_event() can skip this. Reported-by: Solar Designer Signed-off-by: David S. Miller Tested-by: Cyrill Gorcunov [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit 7ce55b83fbf2ff341aacfe825001d40e7bbccbe2 Author: Ignat Korchagin Date: Thu Mar 17 18:00:29 2016 +0000 USB: usbip: fix potential out-of-bounds write commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream. Fix potential out-of-bounds write to urb->transfer_buffer usbip handles network communication directly in the kernel. When receiving a packet from its peer, usbip code parses headers according to protocol. As part of this parsing urb->actual_length is filled. Since the input for urb->actual_length comes from the network, it should be treated as untrusted. Any entity controlling the network may put any value in the input and the preallocated urb->transfer_buffer may not be large enough to hold the data. Thus, the malicious entity is able to write arbitrary data to kernel memory. Signed-off-by: Ignat Korchagin Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit 2897ac4a5bf460ed350675c44bef5ae9d679d748 Author: Oliver Neukum Date: Mon Mar 7 11:31:10 2016 +0100 usbnet: cleanup after bind() in probe() commit 1666984c8625b3db19a9abc298931d35ab7bc64b upstream. In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to cdc-ncm. Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 84f60bacb3084374a161bcb3e847dd22ed65f0a2 Author: Hector Marco-Gisbert Date: Thu Mar 10 20:51:00 2016 +0100 x86/mm/32: Enable full randomization on i386 and X86_32 commit 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb upstream. Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). This patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. By default on i386 there are 8 bits for the randomization of the libraries, vDSO and mmaps which only uses 1MB of VA. This patch preserves the original randomness, using 1MB of VA out of 3GB or 4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR. The first obvious security benefit is that all objects are randomized (not only the stack and the executable) in legacy mode which highly increases the ASLR effectiveness, otherwise the attackers may use these non-randomized areas. But also sensitive setuid/setgid applications are more secure because currently, attackers can disable the randomization of these applications by setting the ulimit stack to "unlimited". This is a very old and widely known trick to disable the ASLR in i386 which has been allowed for too long. Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE personality flag, but fortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Signed-off-by: Hector Marco-Gisbert Acked-by: Ismael Ripoll Ripoll Acked-by: Kees Cook Acked-by: Arjan van de Ven Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: kees Cook Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 333d0cf28913c5d52dc7a15d0f0a4c1444f67632 Author: Kees Cook Date: Tue Apr 14 15:47:45 2015 -0700 x86: standardize mmap_rnd() usage commit 82168140bc4cec7ec9bad39705518541149ff8b7 upstream. In preparation for splitting out ET_DYN ASLR, this refactors the use of mmap_rnd() to be used similarly to arm, and extracts the checking of PF_RANDOMIZE. Signed-off-by: Kees Cook Reviewed-by: Ingo Molnar Cc: Oleg Nesterov Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b8cea33c6279e43cf0a222f3709f54e7d7c5a9be Author: Florian Westphal Date: Tue Mar 22 18:02:50 2016 +0100 netfilter: x_tables: make sure e->next_offset covers remaining blob size commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream. Otherwise this function may read data beyond the ruleset blob. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Ben Hutchings commit 2fcf67674aeafe62db7b17091050b811883524fe Author: Florian Westphal Date: Tue Mar 22 18:02:49 2016 +0100 netfilter: x_tables: validate e->target_offset early commit bdf533de6968e9686df777dc178486f600c6e617 upstream. We should check that e->target_offset is sane before mark_source_chains gets called since it will fetch the target entry for loop detection. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 14313e39f3b33368020206940fe88fcf777b657e Author: Helge Deller Date: Fri Apr 8 18:32:52 2016 +0200 parisc: Unbreak handling exceptions from kernel modules commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 upstream. Handling exceptions from modules never worked on parisc. It was just masked by the fact that exceptions from modules don't happen during normal use. When a module triggers an exception in get_user() we need to load the main kernel dp value before accessing the exception_data structure, and afterwards restore the original dp value of the module on exit. Noticed-by: Mikulas Patocka Signed-off-by: Helge Deller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 2e5c1b752c46b2bc61aa81f23b5a10f3a97bda76 Author: Helge Deller Date: Fri Apr 8 18:18:48 2016 +0200 parisc: Fix kernel crash with reversed copy_from_user() commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 upstream. The kernel module testcase (lib/test_user_copy.c) exhibited a kernel crash on parisc if the parameters for copy_from_user were reversed ("illegal reversed copy_to_user" testcase). Fix this potential crash by checking the fault handler if the faulting address is in the exception table. Signed-off-by: Helge Deller Cc: Kees Cook Signed-off-by: Ben Hutchings commit ae75f6aa46fa384ff0bb417ae9fa4ebcc97acfc6 Author: Helge Deller Date: Fri Apr 8 18:11:33 2016 +0200 parisc: Avoid function pointers for kernel exception routines commit e3893027a300927049efc1572f852201eb785142 upstream. We want to avoid the kernel module loader to create function pointers for the kernel fixup routines of get_user() and put_user(). Changing the external reference from function type to int type fixes this. This unbreaks exception handling for get_user() and put_user() when called from a kernel module. Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 9499f0fdd691c25800808f4eb7eb47924396ed8d Author: Martyn Welch Date: Tue Mar 29 17:47:29 2016 +0100 USB: serial: cp210x: Adding GE Healthcare Device ID commit cddc9434e3dcc37a85c4412fb8e277d3a582e456 upstream. The CP2105 is used in the GE Healthcare Remote Alarm Box, with the Manufacturer ID of 0x1901 and Product ID of 0x0194. Signed-off-by: Martyn Welch Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 0ab6e069f05ce5b9f321922e5d934af0d7a7c805 Author: Josh Boyer Date: Thu Mar 10 09:48:52 2016 -0500 USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices commit ea6db90e750328068837bed34cb1302b7a177339 upstream. A Fedora user reports that the ftdi_sio driver works properly for the ICP DAS I-7561U device. Further, the user manual for these devices instructs users to load the driver and add the ids using the sysfs interface. Add support for these in the driver directly so that the devices work out of the box instead of needing manual configuration. Reported-by: Signed-off-by: Josh Boyer Signed-off-by: Johan Hovold [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b74d4eb2fea52b6e29852fd1ac3d5dc71b56ccc5 Author: Boris Ostrovsky Date: Fri Mar 18 10:11:07 2016 -0400 xen/events: Mask a moving irq commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream. Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can happen as follows: On source CPU: evtchn_2l_handle_events() -> generic_handle_irq() -> handle_edge_irq() -> eoi_pirq(): irq_move_irq(data); /***** WE ARE HERE *****/ if (VALID_EVTCHN(evtchn)) clear_evtchn(evtchn); If at this moment target processor is handling an unrelated event in evtchn_2l_handle_events()'s loop it may pick up our event since target's cpu_evtchn_mask claims that this event belongs to it *and* the event is unmasked and still pending. At the same time, source CPU will continue executing its own handle_edge_irq(). With FIFO interrupt the scenario is similar: irq_move_irq() may result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel [bwh: Backported to 3.2: - Adjust filename - Add a suitable definition of test_and_set_mask()] Signed-off-by: Ben Hutchings commit 6d834a77e5724fe5f0bc92bc2964b661323e4875 Author: Takashi Iwai Date: Fri Apr 1 12:28:16 2016 +0200 ALSA: timer: Use mod_timer() for rearming the system timer commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream. ALSA system timer backend stops the timer via del_timer() without sync and leaves del_timer_sync() at the close instead. This is because of the restriction by the design of ALSA timer: namely, the stop callback may be called from the timer handler, and calling the sync shall lead to a hangup. However, this also triggers a kernel BUG() when the timer is rearmed immediately after stopping without sync: kernel BUG at kernel/time/timer.c:966! Call Trace: [] snd_timer_s_start+0x13e/0x1a0 [] snd_timer_interrupt+0x504/0xec0 [] ? debug_check_no_locks_freed+0x290/0x290 [] snd_timer_s_function+0xb4/0x120 [] call_timer_fn+0x162/0x520 [] ? call_timer_fn+0xcd/0x520 [] ? snd_timer_interrupt+0xec0/0xec0 .... It's the place where add_timer() checks the pending timer. It's clear that this may happen after the immediate restart without sync in our cases. So, the workaround here is just to use mod_timer() instead of add_timer(). This looks like a band-aid fix, but it's a right move, as snd_timer_interrupt() takes care of the continuous rearm of timer. Reported-by: Jiri Slaby Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 3252026aa92e2f271a4d5292d233356fbdbdd8a6 Author: Yuki Shibuya Date: Thu Mar 24 05:17:03 2016 +0000 KVM: x86: Inject pending interrupt even if pending nmi exist commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 upstream. Non maskable interrupts (NMI) are preferred to interrupts in current implementation. If a NMI is pending and NMI is blocked by the result of nmi_allowed(), pending interrupt is not injected and enable_irq_window() is not executed, even if interrupts injection is allowed. In old kernel (e.g. 2.6.32), schedule() is often called in NMI context. In this case, interrupts are needed to execute iret that intends end of NMI. The flag of blocking new NMI is not cleared until the guest execute the iret, and interrupts are blocked by pending NMI. Due to this, iret can't be invoked in the guest, and the guest is starved until block is cleared by some events (e.g. canceling injection). This patch injects pending interrupts, when it's allowed, even if NMI is blocked. And, If an interrupts is pending after executing inject_pending_event(), enable_irq_window() is executed regardless of NMI pending counter. Signed-off-by: Yuki Shibuya Suggested-by: Paolo Bonzini Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - vcpu_enter_guest() is simpler because inject_pending_event() can't fail - Adjust context] Signed-off-by: Ben Hutchings commit e7a5fd7811c541922d3a7c86fdee11c332492f74 Author: Martin K. Petersen Date: Mon Mar 28 21:18:56 2016 -0400 sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream. During revalidate we check whether device capacity has changed before we decide whether to output disk information or not. The check for old capacity failed to take into account that we scaled sdkp->capacity based on the reported logical block size. And therefore the capacity test would always fail for devices with sectors bigger than 512 bytes and we would print several copies of the same discovery information. Avoid scaling sdkp->capacity and instead adjust the value on the fly when setting the block device capacity and generating fake C/H/S geometry. Signed-off-by: Martin K. Petersen Reported-by: Hannes Reinecke Reviewed-by: Hannes Reinicke Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen [bwh: Backported to 3.2: - logical_to_sectors() is a new function - Adjust context] Signed-off-by: Ben Hutchings commit 3867082924673a9371792e822fe3ed403eeff4d9 Author: Oliver Neukum Date: Thu Mar 31 12:04:26 2016 -0400 USB: digi_acceleport: do sanity checking for the number of ports commit 5a07975ad0a36708c6b0a5b9fea1ff811d0b0c1f upstream. The driver can be crashed with devices that expose crafted descriptors with too few endpoints. See: http://seclists.org/bugtraq/2016/Mar/61 Signed-off-by: Oliver Neukum [johan: fix OOB endpoint check and add error messages ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 2f974f8dc1e451dedb79eeac94f24e667c09917a Author: Oliver Neukum Date: Thu Mar 31 12:04:25 2016 -0400 USB: cypress_m8: add endpoint sanity check commit c55aee1bf0e6b6feec8b2927b43f7a09a6d5f754 upstream. An attack using missing endpoints exists. CVE-2016-3137 Signed-off-by: Oliver Neukum Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b323f6de337f4904272172958322b5f2bf50984d Author: Oliver Neukum Date: Thu Mar 31 12:04:24 2016 -0400 USB: mct_u232: add sanity checking in probe commit 4e9a0b05257f29cf4b75f3209243ed71614d062e upstream. An attack using the lack of sanity checking in probe is known. This patch checks for the existence of a second port. CVE-2016-3136 Signed-off-by: Oliver Neukum [johan: add error message ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: put the check in mct_u232_startup(), which already has a 'serial' variable] Signed-off-by: Ben Hutchings commit 7836b6be3ecf04a48076892e8dfa445e5349ad64 Author: Vladis Dronov Date: Thu Mar 31 12:05:43 2016 -0400 ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call commit 836b34a935abc91e13e63053d0a83b24dfb5ea78 upstream. create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and create_uaxx_quirk() functions allocate the audioformat object by themselves and free it upon error before returning. However, once the object is linked to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be double-freed, eventually resulting in a memory corruption. This patch fixes these failures in the error paths by unlinking the audioformat object before freeing it. Based on a patch by Takashi Iwai [Note for stable backports: this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()')] Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c26badfc853730dcf20820fd1d4f66fd0a2e6c92 Author: Takashi Iwai Date: Tue Mar 15 12:14:49 2016 +0100 ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk() commit 902eb7fd1e4af3ac69b9b30f8373f118c92b9729 upstream. Just a minor code cleanup: unify the error paths. Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 12ecd2fa1d46fd8025a51d3a02d23766a9241117 Author: Yoshihiro Shimoda Date: Thu Mar 10 11:30:15 2016 +0900 usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer commit 6490865c67825277b29638e839850882600b48ec upstream. This patch adds a code to surely disable TX IRQ of the pipe before starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs may happen in rare cases when DMAC is used. Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 7eef619339101468be84bfe14329f2ed54874b74 Author: Yoshihiro Shimoda Date: Thu Mar 10 11:30:14 2016 +0900 usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream. When unexpected situation happened (e.g. tx/rx irq happened while DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL pointer dereference like the followings: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 80000007 [#1] SMP ARM Modules linked in: usb_f_acm u_serial g_serial libcomposite CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63 Hardware name: Generic R8A7790 (Flattened Device Tree) task: c0729c00 ti: c0724000 task.ti: c0724000 PC is at 0x0 LR is at usbhsf_pkt_handler+0xac/0x118 pc : [<00000000>] lr : [] psr: 60000193 sp : c0725db8 ip : 00000000 fp : c0725df4 r10: 00000001 r9 : 00000193 r8 : ef3ccab4 r7 : ef3cca10 r6 : eea4586c r5 : 00000000 r4 : ef19ceb4 r3 : 00000000 r2 : 0000009c r1 : c0725dc4 r0 : ef19ceb4 This patch adds a condition to avoid the dereference. Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit ad955a93242a640292829df79de17165b47cd0d1 Author: Guenter Roeck Date: Sat Mar 26 12:28:05 2016 -0700 hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated commit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f upstream. arm:pxa_defconfig can result in the following crash if the max1111 driver is not instantiated. Unhandled fault: page domain fault (0x01b) at 0x00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: : 1b [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10 Hardware name: SHARP Akita Workqueue: events sharpsl_charge_toggle task: c390a000 ti: c391e000 task.ti: c391e000 PC is at max1111_read_channel+0x20/0x30 LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c pc : [] lr : [] psr: 20000013 ... [] (max1111_read_channel) from [] (sharpsl_pm_pxa_read_max1111+0x2c/0x3c) [] (sharpsl_pm_pxa_read_max1111) from [] (spitzpm_read_devdata+0x5c/0xc4) [] (spitzpm_read_devdata) from [] (sharpsl_check_battery_temp+0x78/0x110) [] (sharpsl_check_battery_temp) from [] (sharpsl_charge_toggle+0x48/0x110) [] (sharpsl_charge_toggle) from [] (process_one_work+0x14c/0x48c) [] (process_one_work) from [] (worker_thread+0x3c/0x5d4) [] (worker_thread) from [] (kthread+0xd0/0xec) [] (kthread) from [] (ret_from_fork+0x14/0x24) This can occur because the SPI controller driver (SPI_PXA2XX) is built as module and thus not necessarily loaded. While building SPI_PXA2XX into the kernel would make the problem disappear, it appears prudent to ensure that the driver is instantiated before accessing its data structures. Cc: Arnd Bergmann Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 2998e4fe069a14ed352eb78f742a681aff5d3861 Author: Joseph Qi Date: Fri Mar 25 14:21:29 2016 -0700 ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream. When master handles convert request, it queues ast first and then returns status. This may happen that the ast is sent before the request status because the above two messages are sent by two threads. And right after the ast is sent, if master down, it may trigger BUG in dlm_move_lockres_to_recovery_list in the requested node because ast handler moves it to grant list without clear lock->convert_pending. So remove BUG_ON statement and check if the ast is processed in dlmconvert_remote. Signed-off-by: Joseph Qi Reported-by: Yiwen Jiang Cc: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Tariq Saeed Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 8d02fd0b8dea430a144fad6239334ecf9b00791e Author: Joseph Qi Date: Fri Mar 25 14:21:26 2016 -0700 ocfs2/dlm: fix race between convert and recovery commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac upstream. There is a race window between dlmconvert_remote and dlm_move_lockres_to_recovery_list, which will cause a lock with OCFS2_LOCK_BUSY in grant list, thus system hangs. dlmconvert_remote { spin_lock(&res->spinlock); list_move_tail(&lock->list, &res->converting); lock->convert_pending = 1; spin_unlock(&res->spinlock); status = dlm_send_remote_convert_request(); >>>>>> race window, master has queued ast and return DLM_NORMAL, and then down before sending ast. this node detects master down and calls dlm_move_lockres_to_recovery_list, which will revert the lock to grant list. Then OCFS2_LOCK_BUSY won't be cleared as new master won't send ast any more because it thinks already be authorized. spin_lock(&res->spinlock); lock->convert_pending = 0; if (status != DLM_NORMAL) dlm_revert_pending_convert(res, lock); spin_unlock(&res->spinlock); } In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set (res is still in recovering) or res master changed (new master has finished recovery), reset the status to DLM_RECOVERING, then it will retry convert. Signed-off-by: Joseph Qi Reported-by: Yiwen Jiang Reviewed-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Tariq Saeed Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit f3a602c6a0d8518f0b34d5a7fd3d1145dd71902b Author: Guenter Roeck Date: Tue Mar 22 15:11:03 2016 -0700 MAINTAINERS: Update mailing list and web page for hwmon subsystem commit 968ce1b1f45a7d76b5471b19bd035dbecc72f32d upstream. The old web page for the hwmon subsystem is no longer operational, and the mailing list has become unreliable. Move both to kernel.org. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck [bwh: Backported to 3.2: the set of hwmon drivers is different, so do a search-and-replace for the same addresses] Signed-off-by: Ben Hutchings commit ae211053c771562a27a53c2a49f20f720a7c473d Author: Vladis Dronov Date: Wed Mar 23 11:53:46 2016 -0700 Input: ati_remote2 - fix crashes on detecting device with invalid descriptor commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream. The ati_remote2 driver expects at least two interfaces with one endpoint each. If given malicious descriptor that specify one interface or no endpoints, it will crash in the probe function. Ensure there is at least two interfaces and one endpoint for each interface before using it. The full disclosure: http://seclists.org/bugtraq/2016/Mar/90 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 7fda126c5155acc3e61596ce4c5dcf3859e22444 Author: Guillaume Nault Date: Wed Mar 23 16:38:55 2016 +0100 ppp: take reference on channels netns commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89 upstream. Let channels hold a reference on their network namespace. Some channel types, like ppp_async and ppp_synctty, can have their userspace controller running in a different namespace. Therefore they can't rely on them to preclude their netns from being removed from under them. ================================================================== BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at addr ffff880064e217e0 Read of size 8 by task syz-executor/11581 ============================================================================= BUG net_namespace (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906 [< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440 [< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469 [< inline >] slab_alloc_node kernel/mm/slub.c:2532 [< inline >] slab_alloc kernel/mm/slub.c:2574 [< none >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579 [< inline >] kmem_cache_zalloc kernel/include/linux/slab.h:597 [< inline >] net_alloc kernel/net/core/net_namespace.c:325 [< none >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360 [< none >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95 [< none >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150 [< none >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451 [< inline >] copy_process kernel/kernel/fork.c:1274 [< none >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723 [< inline >] SYSC_clone kernel/kernel/fork.c:1832 [< none >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826 [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185 INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631 [< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650 [< inline >] slab_free kernel/mm/slub.c:2805 [< none >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814 [< inline >] net_free kernel/net/core/net_namespace.c:341 [< none >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348 [< none >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448 [< none >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036 [< none >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170 [< none >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303 [< none >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468 INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000 flags=0x5fffc0000004080 INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200 CPU: 1 PID: 11581 Comm: syz-executor Tainted: G B 4.4.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300 ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054 ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000 Call Trace: [< inline >] __dump_stack kernel/lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50 [] print_trailer+0xf4/0x150 kernel/mm/slub.c:654 [] object_err+0x2f/0x40 kernel/mm/slub.c:661 [< inline >] print_address_description kernel/mm/kasan/report.c:138 [] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236 [< inline >] kasan_report kernel/mm/kasan/report.c:259 [] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280 [< inline >] ? ppp_pernet kernel/include/linux/compiler.h:218 [] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ppp_pernet kernel/include/linux/compiler.h:218 [] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293 [] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241 [] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000 [] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478 [] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744 [] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772 [] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901 [] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688 [] __fput+0x236/0x780 kernel/fs/file_table.c:208 [] ____fput+0x15/0x20 kernel/fs/file_table.c:244 [] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115 [< inline >] exit_task_work kernel/include/linux/task_work.h:21 [] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750 [] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123 [] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357 [] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550 [] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145 [] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880 [] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307 [< inline >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113 [] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158 [] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712 [] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655 [] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165 [] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692 [< inline >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099 [] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678 [< inline >] ? context_switch kernel/kernel/sched/core.c:2807 [] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283 [] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247 [< inline >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282 [] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344 [] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281 Memory state around the buggy address: ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2") Reported-by: Baozeng Ding Signed-off-by: Guillaume Nault Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e1962b0906c362efd496813d6704714200608eb9 Author: Aurelien Jacquiot Date: Tue Mar 22 14:25:42 2016 -0700 rapidio/rionet: fix deadlock on SMP commit 36915976eca58f2eefa040ba8f9939672564df61 upstream. Fix deadlocking during concurrent receive and transmit operations on SMP platforms caused by the use of incorrect lock: on transmit 'tx_lock' spinlock should be used instead of 'lock' which is used for receive operation. This fix is applicable to kernel versions starting from v2.15. Signed-off-by: Aurelien Jacquiot Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Andre van Herk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit b1bf6857ac304ee1c05cb3d804f70312e947887c Author: Jann Horn Date: Tue Mar 22 14:25:36 2016 -0700 fs/coredump: prevent fsuid=0 dumps into user-controlled directories commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream. This commit fixes the following security hole affecting systems where all of the following conditions are fulfilled: - The fs.suid_dumpable sysctl is set to 2. - The kernel.core_pattern sysctl's value starts with "/". (Systems where kernel.core_pattern starts with "|/" are not affected.) - Unprivileged user namespace creation is permitted. (This is true on Linux >=3.8, but some distributions disallow it by default using a distro patch.) Under these conditions, if a program executes under secure exec rules, causing it to run with the SUID_DUMP_ROOT flag, then unshares its user namespace, changes its root directory and crashes, the coredump will be written using fsuid=0 and a path derived from kernel.core_pattern - but this path is interpreted relative to the root directory of the process, allowing the attacker to control where a coredump will be written with root privileges. To fix the security issue, always interpret core_pattern for dumps that are written under SUID_DUMP_ROOT relative to the root directory of init. Signed-off-by: Jann Horn Acked-by: Kees Cook Cc: Al Viro Cc: "Eric W. Biederman" Cc: Andy Lutomirski Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit df79c015fd0655b0ff4f429c89654b47367285b4 Author: Dan Carpenter Date: Wed Mar 16 10:45:10 2016 +0300 ethernet: micrel: fix some error codes commit 3af0d554c1ce11e9d0953381ff566271f9ab81a9 upstream. There were two issues here: 1) dma_mapping_error() return true/false but we want to return -ENOMEM 2) If dmaengine_prep_slave_sg() failed then "err" wasn't set but presumably that should be -ENOMEM as well. I changed the success path to "return 0;" instead of "return ret;" for clarity. Fixes: 94fe8c683cea ('ks8842: Support DMA when accessed via timberdale') Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit f84eda3a12397427302fd17a2c20b26299192951 Author: Rabin Vincent Date: Thu Mar 10 21:19:06 2016 +0100 splice: handle zero nr_pages in splice_to_pipe() commit d6785d9152147596f60234157da2b02540c3e60f upstream. Running the following command: busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null with any tracing enabled pretty very quickly leads to various NULL pointer dereferences and VM BUG_ON()s, such as these: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [] generic_pipe_buf_release+0xc/0x40 Call Trace: [] splice_direct_to_actor+0x143/0x1e0 [] ? generic_pipe_buf_nosteal+0x10/0x10 [] do_splice_direct+0x8f/0xb0 [] do_sendfile+0x199/0x380 [] SyS_sendfile64+0x90/0xa0 [] entry_SYSCALL_64_fastpath+0x12/0x6d page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0) kernel BUG at include/linux/mm.h:367! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC RIP: [] generic_pipe_buf_release+0x3c/0x40 Call Trace: [] splice_direct_to_actor+0x143/0x1e0 [] ? generic_pipe_buf_nosteal+0x10/0x10 [] do_splice_direct+0x8f/0xb0 [] do_sendfile+0x199/0x380 [] SyS_sendfile64+0x90/0xa0 [] tracesys_phase2+0x84/0x89 (busybox's cat uses sendfile(2), unlike the coreutils version) This is because tracing_splice_read_pipe() can call splice_to_pipe() with spd->nr_pages == 0. spd_pages underflows in splice_to_pipe() and we fill the page pointers and the other fields of the pipe_buffers with garbage. All other callers of splice_to_pipe() avoid calling it when nr_pages == 0, and we could make tracing_splice_read_pipe() do that too, but it seems reasonable to have splice_to_page() handle this condition gracefully. Signed-off-by: Rabin Vincent Reviewed-by: Christoph Hellwig Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 1719bf67d6c52a9bc84ddf24a3e85d5f69fe3f90 Author: Steven Rostedt (Red Hat) Date: Fri Mar 18 15:46:48 2016 -0400 tracing: Fix crash from reading trace_pipe with sendfile commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream. If tracing contains data and the trace_pipe file is read with sendfile(), then it can trigger a NULL pointer dereference and various BUG_ON within the VM code. There's a patch to fix this in the splice_to_pipe() code, but it's also a good idea to not let that happen from trace_pipe either. Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.in Reported-by: Rabin Vincent Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit 567d4fb42c192875472d0455e4f2ab5611088771 Author: Arnd Bergmann Date: Mon Mar 14 15:29:44 2016 +0100 lpfc: fix misleading indentation commit aeb6641f8ebdd61939f462a8255b316f9bfab707 upstream. gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array() call in lpfc_online(), which clearly doesn't look right: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online': drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] lpfc_destroy_vport_work_array(phba, vports); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not if (vports != NULL) ^~ Looking at the patch that introduced this code, it's clear that the behavior is correct and the indentation is wrong. This fixes the indentation and adds curly braces around the previous if() block for clarity, as that is most likely what caused the code to be misindented in the first place. Signed-off-by: Arnd Bergmann Fixes: 549e55cd2a1b ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list") Reviewed-by: Sebastian Herbszt Reviewed-by: Hannes Reinecke Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 9e1128ecd9cab0f5af43cb4f8a6ff9091aaf15b8 Author: Steven Rostedt (Red Hat) Date: Fri Mar 18 12:27:43 2016 -0400 tracing: Have preempt(irqs)off trace preempt disabled functions commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream. Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well. Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted: <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit <...>-2265 1d..1 3419us : __do_softirq <-irq_exit <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit. Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers" Cc: stable@vget.kernel.org # 2.6.37+ Reported-by: Joel Fernandes Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit c50eccdcbb5df7830e4a0229844a154855ac13ff Author: Oliver Neukum Date: Tue Mar 15 10:14:04 2016 +0100 USB: cdc-acm: more sanity checking commit 8835ba4a39cf53f705417b3b3a94eb067673f2c9 upstream. An attack has become available which pretends to be a quirky device circumventing normal sanity checks and crashes the kernel by an insufficient number of interfaces. This patch adds a check to the code path for quirky devices. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 79a575e829ba789c462c103c54fd9554f60079db Author: Oliver Neukum Date: Wed Mar 16 13:26:17 2016 +0100 USB: usb_driver_claim_interface: add sanity checking commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd upstream. Attacks that trick drivers into passing a NULL pointer to usb_driver_claim_interface() using forged descriptors are known. This thwarts them by sanity checking. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit e0dbd4b2f2a1bbb1485eb26c5dedf540db9f2d59 Author: Josh Boyer Date: Mon Mar 14 10:42:38 2016 -0400 USB: iowarrior: fix oops with malicious USB descriptors commit 4ec0ef3a82125efc36173062a50624550a900ae0 upstream. The iowarrior driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. The full report of this issue can be found here: http://seclists.org/bugtraq/2016/Mar/87 Reported-by: Ralf Spenneberg Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c3814d37897141ae16619d9682f4e416114ee9b0 Author: Benjamin Tissoires Date: Thu Mar 17 17:12:54 2016 -0700 Input: synaptics - handle spurious release of trackstick buttons, again commit 82be788c96ed5978d3cb4a00079e26b981a3df3f upstream. Looks like the fimware 8.2 still has the extra buttons spurious release bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321 Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 33a3e89aacee6a385dd59ab4fa193ff2dd412d98 Author: Shaohua Li Date: Mon Mar 14 11:49:32 2016 -0700 raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang commit 23ddba80ebe836476bb2fa1f5ef305dd1c63dc0b upstream. This is the raid10 counterpart of the bug fixed by Nate (raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang) Fixes: 95af587e95(md/raid10: ensure device failure recorded before write request returns) Cc: Nate Dailey Signed-off-by: Shaohua Li Signed-off-by: Ben Hutchings commit 11266d296f0376640b67a28847e613961159d907 Author: Nate Dailey Date: Mon Feb 29 10:43:58 2016 -0500 raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang commit ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb upstream. If raid1d is handling a mix of read and write errors, handle_read_error's call to freeze_array can get stuck. This can happen because, though the bio_end_io_list is initially drained, writes can be added to it via handle_write_finished as the retry_list is processed. These writes contribute to nr_pending but are not included in nr_queued. If a later entry on the retry_list triggers a call to handle_read_error, freeze array hangs waiting for nr_pending == nr_queued+extra. The writes on the bio_end_io_list aren't included in nr_queued so the condition will never be satisfied. To prevent the hang, include bio_end_io_list writes in nr_queued. There's probably a better way to handle decrementing nr_queued, but this seemed like the safest way to avoid breaking surrounding code. I'm happy to supply the script I used to repro this hang. Fixes: 55ce74d4bfe1b(md/raid1: ensure device failure recorded before write request returns.) Signed-off-by: Nate Dailey Signed-off-by: Shaohua Li Signed-off-by: Ben Hutchings commit 64731eb996c201464143d6ee701c3ff2e95c1a2c Author: Andy Lutomirski Date: Wed Mar 16 14:14:22 2016 -0700 x86/iopl: Fix iopl capability check on Xen PV commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e upstream. iopl(3) is supposed to work if iopl is already 3, even if unprivileged. This didn't work right on Xen PV. Fix it. Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 880ee9d2f52a511bb603ef79030d6fbd30c5d878 Author: Andy Lutomirski Date: Wed Mar 16 14:14:21 2016 -0700 x86/iopl/64: Properly context-switch IOPL on Xen PV commit b7a584598aea7ca73140cb87b40319944dd3393f upstream. On Xen PV, regs->flags doesn't reliably reflect IOPL and the exit-to-userspace code doesn't change IOPL. We need to context switch it manually. I'm doing this without going through paravirt because this is specific to Xen PV. After the dust settles, we can merge this with the 32-bit code, tidy up the iopl syscall implementation, and remove the set_iopl pvop entirely. Fixes XSA-171. Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: - Use xen_pv_domain() directly as X86_FEATURE_XENPV is not defined - Adjust context] Signed-off-by: Ben Hutchings commit e4391ae144e76c324e842cdb61c4dde74c332eaf Author: Guillaume Nault Date: Mon Mar 14 21:17:16 2016 +0100 ppp: ensure file->private_data can't be overridden commit e8e56ffd9d2973398b60ece1f1bebb8d67b4d032 upstream. Locking ppp_mutex must be done before dereferencing file->private_data, otherwise it could be modified before ppp_unattached_ioctl() takes the lock. This could lead ppp_unattached_ioctl() to override ->private_data, thus leaking reference to the ppp_file previously pointed to. v2: lock all ppp_ioctl() instead of just checking private_data in ppp_unattached_ioctl(), to avoid ambiguous behaviour. Fixes: f3ff8a4d80e8 ("ppp: push BKL down into the driver") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2ec876e355fe6cefc340178e82f5dfd17306adcf Author: J. Bruce Fields Date: Wed Mar 2 16:36:21 2016 -0800 nfsd: fix deadlock secinfo+readdir compound commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 upstream. nfsd_lookup_dentry exits with the parent filehandle locked. fh_put also unlocks if necessary (nfsd filehandle locking is probably too lenient), so it gets unlocked eventually, but if the following op in the compound needs to lock it again, we can deadlock. A fuzzer ran into this; normal clients don't send a secinfo followed by a readdir in the same compound. Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit c0e9921c951610c287650bf70495d7ccac8bee7f Author: Takashi Iwai Date: Tue Mar 15 15:20:58 2016 +0100 ALSA: usb-audio: Add sanity checks for endpoint accesses commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a upstream. Add some sanity check codes before actually accessing the endpoint via get_endpoint() in order to avoid the invalid access through a malformed USB descriptor. Mostly just checking bNumEndpoints, but in one place (snd_microii_spdif_default_get()), the validity of iface and altsetting index is checked as well. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: drop changes to code we don't have] Signed-off-by: Ben Hutchings commit 8e5c3482b5c7bcbd7df6b10ddb6d7bcc578f3553 Author: Takashi Iwai Date: Tue Mar 15 12:09:10 2016 +0100 ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk() commit 0f886ca12765d20124bd06291c82951fd49a33be upstream. create_fixed_stream_quirk() may cause a NULL-pointer dereference by accessing the non-existing endpoint when a USB device with a malformed USB descriptor is used. This patch avoids it simply by adding a sanity check of bNumEndpoints before the accesses. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: - There's no altsd variable - Adjust context] Signed-off-by: Ben Hutchings commit 1b8363d0f0b36155d823e6c99f6c818de1b697cc Author: Arnd Bergmann Date: Mon Mar 14 15:18:36 2016 +0100 ath9k: fix buffer overrun for ar9287 commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 upstream. Code that was added back in 2.6.38 has an obvious overflow when accessing a static array, and at the time it was added only a code comment was put in front of it as a reminder to have it reviewed properly. This has not happened, but gcc-6 now points to the specific overflow: drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs': drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds] maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4]; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ It turns out that the correct array length exists in the local 'intercepts' variable of this function, so we can just use that instead of hardcoding '4', so this patch changes all three instances to use that variable. The other two instances were already correct, but it's more consistent this way. Signed-off-by: Arnd Bergmann Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs") Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 61934d093bc3acbd3d968b4b2f31c7c98b3edc10 Author: Arnaldo Carvalho de Melo Date: Mon Mar 14 09:56:35 2016 -0300 net: Fix use after free in the recvmmsg exit path commit 34b88a68f26a75e4fded796f1a49c40f82234b7d upstream. The syzkaller fuzzer hit the following use-after-free: Call Trace: [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295 [] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261 [< inline >] SYSC_recvmmsg net/socket.c:2281 [] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 And, as Dmitry rightly assessed, that is because we can drop the reference and then touch it when the underlying recvmsg calls return some packets and then hit an error, which will make recvmmsg to set sock->sk->sk_err, oops, fix it. Reported-and-Tested-by: Dmitry Vyukov Cc: Alexander Potapenko Cc: Eric Dumazet Cc: Kostya Serebryany Cc: Sasha Levin Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall") http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 615fd7f1ce2ced5bd401aeac55cda44295c2ae58 Author: Josh Boyer Date: Mon Mar 14 09:33:40 2016 -0700 Input: powermate - fix oops with malicious USB descriptors commit 9c6ba456711687b794dcf285856fc14e2c76074f upstream. The powermate driver expects at least one valid USB endpoint in its probe function. If given malicious descriptors that specify 0 for the number of endpoints, it will crash. Validate the number of endpoints on the interface before using them. The full report for this issue can be found here: http://seclists.org/bugtraq/2016/Mar/85 Reported-by: Ralf Spenneberg Signed-off-by: Josh Boyer Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit b303809d60e3b7ab43d1c06cee90556f5d04c4be Author: Geert Uytterhoeven Date: Tue Mar 1 09:50:01 2016 +0100 rtc: vr41xx: Wire up alarm_irq_enable commit a25f4a95ec3cded34c1250364eba704c5e4fdac4 upstream. drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used Apparently the conversion to alarm_irq_enable forgot to wire up the callback. Fixes: 16380c153a69c378 ("RTC: Convert rtc drivers to use the alarm_irq_enable method") Signed-off-by: Geert Uytterhoeven Signed-off-by: Alexandre Belloni Signed-off-by: Ben Hutchings commit 3e074035497e567bd73c170754fcf235df16a3e9 Author: Vittorio Gambaletta (VittGam) Date: Sun Mar 13 22:19:34 2016 +0100 ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41. commit 4061db03dd71d195b9973ee466f6ed32f6a3fc16 upstream. The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41 will often fail, so add a quirk entry to fix it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087 Signed-off-by: Vittorio Gambaletta Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 9d4ac2d1b8b858afc6178317d9b2977dc6f2c747 Author: DingXiang Date: Tue Feb 2 12:29:18 2016 +0800 dm snapshot: disallow the COW and origin devices from being identical commit 4df2bf466a9c9c92f40d27c4aa9120f4e8227bfc upstream. Otherwise loading a "snapshot" table using the same device for the origin and COW devices, e.g.: echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap will trigger: BUG: unable to handle kernel NULL pointer dereference at 0000000000000098 [ 1958.979934] IP: [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1958.989655] PGD 0 [ 1958.991903] Oops: 0000 [#1] SMP ... [ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G IO 4.5.0-rc5.snitm+ #150 ... [ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000 [ 1959.091865] RIP: 0010:[] [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1959.104295] RSP: 0018:ffff88032a957b30 EFLAGS: 00010246 [ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001 [ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00 [ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001 [ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80 [ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80 [ 1959.150021] FS: 00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000 [ 1959.159047] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0 [ 1959.173415] Stack: [ 1959.175656] ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc [ 1959.183946] ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000 [ 1959.192233] ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf [ 1959.200521] Call Trace: [ 1959.203248] [] dm_exception_store_create+0x1d5/0x240 [dm_snapshot] [ 1959.211986] [] snapshot_ctr+0x140/0x630 [dm_snapshot] [ 1959.219469] [] ? dm_split_args+0x64/0x150 [dm_mod] [ 1959.226656] [] dm_table_add_target+0x177/0x440 [dm_mod] [ 1959.234328] [] table_load+0x143/0x370 [dm_mod] [ 1959.241129] [] ? retrieve_status+0x1b0/0x1b0 [dm_mod] [ 1959.248607] [] ctl_ioctl+0x255/0x4d0 [dm_mod] [ 1959.255307] [] ? memzero_explicit+0x12/0x20 [ 1959.261816] [] dm_ctl_ioctl+0x13/0x20 [dm_mod] [ 1959.268615] [] do_vfs_ioctl+0xa6/0x5c0 [ 1959.274637] [] ? __audit_syscall_entry+0xaf/0x100 [ 1959.281726] [] ? do_audit_syscall_entry+0x66/0x70 [ 1959.288814] [] SyS_ioctl+0x79/0x90 [ 1959.294450] [] entry_SYSCALL_64_fastpath+0x12/0x71 ... [ 1959.323277] RIP [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1959.333090] RSP [ 1959.336978] CR2: 0000000000000098 [ 1959.344121] ---[ end trace b049991ccad1169e ]--- Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899 Signed-off-by: Ding Xiang Signed-off-by: Mike Snitzer [bwh: Backported to 3.2: the device path parsing code is rather different, but move it into dm_get_dev_t() anyway] Signed-off-by: Ben Hutchings commit dd47ac8cda0022e61a277936afc7de90c667ce62 Author: Dmitry Tunin Date: Fri Mar 4 01:32:19 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3472 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1552925 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit e250393572a6507e2c6a0e8c3dfd67b703198b1d Author: OGAWA Hirofumi Date: Wed Mar 9 23:47:25 2016 -0500 jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 upstream. On umount path, jbd2_journal_destroy() writes latest transaction ID (->j_tail_sequence) to be used at next mount. The bug is that ->j_tail_sequence is not holding latest transaction ID in some cases. So, at next mount, there is chance to conflict with remaining (not overwritten yet) transactions. mount (id=10) write transaction (id=11) write transaction (id=12) umount (id=10) <= the bug doesn't write latest ID mount (id=10) write transaction (id=11) crash mount [recovery process] transaction (id=11) transaction (id=12) <= valid transaction ID, but old commit must not replay Like above, this bug become the cause of recovery failure, or FS corruption. So why ->j_tail_sequence doesn't point latest ID? Because if checkpoint transactions was reclaimed by memory pressure (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated. (And another case is, __jbd2_journal_clean_checkpoint_list() is called with empty transaction.) So in above cases, ->j_tail_sequence is not pointing latest transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not done too. So, to fix this problem with minimum changes, this patch updates ->j_tail_sequence, and issue REQ_FLUSH. (With more complex changes, some optimizations would be possible to avoid unnecessary REQ_FLUSH for example though.) BTW, journal->j_tail_sequence = ++journal->j_transaction_sequence; Increment of ->j_transaction_sequence seems to be unnecessary, but ext3 does this. Signed-off-by: OGAWA Hirofumi Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 88a8579c74e69b888d94dd886bbe5edba3d3be3f Author: Douglas Gilbert Date: Thu Mar 3 00:31:29 2016 -0500 sg: fix dxferp in from_to case commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream. One of the strange things that the original sg driver did was let the user provide both a data-out buffer (it followed the sg_header+cdb) _and_ specify a reply length greater than zero. What happened was that the user data-out buffer was copied into some kernel buffers and then the mid level was told a read type operation would take place with the data from the device overwriting the same kernel buffers. The user would then read those kernel buffers back into the user space. From what I can tell, the above action was broken by commit fad7f01e61bf ("sg: set dxferp to NULL for READ with the older SG interface") in 2008 and syzkaller found that out recently. Make sure that a user space pointer is passed through when data follows the sg_header structure and command. Fix the abnormal case when a non-zero reply_len is also given. Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6 Signed-off-by: Douglas Gilbert Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit a8bb201277bd103bc8c7cd140f44734b016cb0a4 Author: Mario Kleiner Date: Sun Mar 6 02:39:53 2016 +0100 drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream. As observed on Apple iMac10,1, DCE-3.2, RV-730, link rate of 2.7 Ghz is not selected, because the args.v1.ucConfig flag setting for 2.7 Ghz gets overwritten by a following assignment of the transmitter to use. Move link rate setup a few lines down to fix this. In practice this didn't have any positive or negative effect on display setup on the tested iMac10,1 so i don't know if backporting to stable makes sense or not. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 701566be7af6f64018658fb1db3634182106c0f4 Author: Maurizio Lombardi Date: Fri Mar 4 10:41:49 2016 +0100 be2iscsi: set the boot_kset pointer to NULL in case of failure commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream. In beiscsi_setup_boot_info(), the boot_kset pointer should be set to NULL in case of failure otherwise an invalid pointer dereference may occur later. Signed-off-by: Maurizio Lombardi Reviewed-by: Johannes Thumshirn Reviewed-by: Jitendra Bhivare Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit ac8f5acfbcdec0475361790281405936b511d345 Author: Bjorn Helgaas Date: Fri Feb 26 09:15:11 2016 -0600 x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs commit b894157145e4ac7598d7062bc93320898a5e059e upstream. The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register where a BAR should be. We don't know what the side effects of sizing the "BAR" would be, and we don't know what address space the "BAR" might appear to describe. Mark these devices as having non-compliant BARs so the PCI core doesn't touch them. Signed-off-by: Bjorn Helgaas Tested-by: Andi Kleen Signed-off-by: Ben Hutchings commit e8238ed21c14dcd0979e1b35850ee65062221b5f Author: Marco Angaroni Date: Sat Mar 5 12:10:02 2016 +0100 ipvs: correct initial offset of Call-ID header search in SIP persistence engine commit 7617a24f83b5d67f4dab1844956be1cebc44aec8 upstream. The IPVS SIP persistence engine is not able to parse the SIP header "Call-ID" when such header is inserted in the first positions of the SIP message. When IPVS is configured with "--pe sip" option, like for example: ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o some particular messages (see below for details) do not create entries in the connection template table, which can be listed with: ipvsadm -Lcn --persistent-conn Problematic SIP messages are SIP responses having "Call-ID" header positioned just after message first line: SIP/2.0 200 OK [Call-ID header here] [rest of the headers] When "Call-ID" header is positioned down (after a few other headers) it is correctly recognized. This is due to the data offset used in get_callid function call inside ip_vs_pe_sip.c file: since dptr already points to the start of the SIP message, the value of dataoff should be initially 0. Otherwise the header is searched starting from some bytes after the first character of the SIP message. Fixes: 758ff0338722 ("IPVS: sip persistence engine") Signed-off-by: Marco Angaroni Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings commit a41e182b6aa057417054cb61bbae7ec891397484 Author: Thomas Gleixner Date: Fri Mar 4 15:59:42 2016 +0100 sched/cputime: Fix steal time accounting vs. CPU hotplug commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream. On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time value over CPU down and up. So after the CPU comes up again the delta calculation in steal_account_process_tick() wreckages itself due to the unsigned math: u64 steal = paravirt_steal_clock(smp_processor_id()); steal -= this_rq()->prev_steal_time; So if steal is smaller than rq->prev_steal_time we end up with an insane large value which then gets added to rq->prev_steal_time, resulting in a permanent wreckage of the accounting. As a consequence the per CPU stats in /proc/stat become stale. Nice trick to tell the world how idle the system is (100%) while the CPU is 100% busy running tasks. Though we prefer realistic numbers. None of the accounting values which use a previous value to account for fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity check for prev_irq_time and prev_steal_time_rq, but that sanity check solely deals with clock warps and limits the /proc/stat visible wreckage. The prev_time values are still wrong. Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again. Signed-off-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Frederic Weisbecker Cc: Glauber Costa Cc: Linus Torvalds Cc: Peter Zijlstra Fixes: commit 095c0aa83e52 "sched: adjust scheduler cpu power for stolen time" Fixes: commit aa483808516c "sched: Remove irq time from available CPU power" Fixes: commit e6e6685accfa "KVM guest: Steal time accounting" Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603041539490.3686@nanos Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust filenames] Signed-off-by: Ben Hutchings commit e2599de1e4856740fe2d482c3990a64924140545 Author: Radim Krčmář Date: Wed Mar 2 22:56:38 2016 +0100 KVM: i8254: change PIT discard tick policy commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 upstream. Discard policy uses ack_notifiers to prevent injection of PIT interrupts before EOI from the last one. This patch changes the policy to always try to deliver the interrupt, which makes a difference when its vector is in ISR. Old implementation would drop the interrupt, but proposed one injects to IRR, like real hardware would. The old policy breaks legacy NMI watchdogs, where PIT is used through virtual wire (LVT0): PIT never sends an interrupt before receiving EOI, thus a guest deadlock with disabled interrupts will stop NMIs. Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt through IOAPIC. (KVM's PIT is deeply rotten and luckily not used much in modern systems.) Even though there is a chance of regressions, I think we can fix the LVT0 NMI bug without introducing a new tick policy. Reported-by: Yuki Shibuya Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - s/ps->reinject/ps->pit_timer.reinject/ - Adjust context] Signed-off-by: Ben Hutchings commit 6a1fbc0770f7af526108eed8fb474ea87dd804e4 Author: Oliver Neukum Date: Wed Feb 17 11:52:43 2016 +0100 usb: hub: fix a typo in hub_port_init() leading to wrong logic commit 0d5ce778c43bf888328231bcdce05d5c860655aa upstream. A typo of j for i led to a logic bug. To rule out future confusion, the variable names are made meaningful. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit d352582ff873b3ea6c84492b79a4416a9a0d578f Author: Michael Hennerich Date: Mon Feb 22 10:20:24 2016 +0100 drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors commit f3df53e4d70b5736368a8fe8aa1bb70c1cb1f577 upstream. Fix RDAC read back errors caused by a typo. Value must shift by 2. Fixes: a4bd394956f2 ("drivers/misc/ad525x_dpot.c: new features") Signed-off-by: Michael Hennerich Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f9b3ef7e5d25db9c35ebb61ba70bb502174c8b5d Author: Mateusz Guzik Date: Wed Mar 2 09:51:09 2016 +1100 xfs: fix two memory leaks in xfs_attr_list.c error paths commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream. This plugs 2 trivial leaks in xfs_attr_shortform_list and xfs_attr3_leaf_list_int. Signed-off-by: Mateusz Guzik Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 49c27d2f5606239806bb4527c2fd19d488094fb6 Author: J. Bruce Fields Date: Mon Feb 29 20:21:21 2016 -0500 nfsd4: fix bad bounds checking commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 upstream. A number of spots in the xdr decoding follow a pattern like n = be32_to_cpup(p++); READ_BUF(n + 4); where n is a u32. The only bounds checking is done in READ_BUF itself, but since it's checking (n + 4), it won't catch cases where n is very large, (u32)(-4) or higher. I'm not sure exactly what the consequences are, but we've seen crashes soon after. Instead, just break these up into two READ_BUF()s. Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit d7058ed73b99dbe694ac4a38332deae662986a4e Author: Michael S. Tsirkin Date: Sun Feb 28 17:44:09 2016 +0200 watchdog: rc32434_wdt: fix ioctl error handling commit 10e7ac22cdd4d211cef99afcb9371b70cb175be6 upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up watchdog/rc32434_wdt to do return copy_to_user(...)) ? -EFAULT : 0; instead. Signed-off-by: Michael S. Tsirkin Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Ben Hutchings commit 2ef430239c8c08c7180bc41611e01b175a0743ac Author: Hans de Goede Date: Sun Feb 7 09:24:29 2016 -0200 bttv: Width must be a multiple of 16 when capturing planar formats commit 5c915c68763889f0183a1cc61c84bb228b60124a upstream. On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max size results in a solid green rectangle being captured (all colors 0 in YUV). This turns out to be caused by max-width (924) not being a multiple of 16. We've likely never hit this problem before since normally xawtv / tvtime, etc. will prefer packed pixel formats. But when using a video card which is using xf86-video-modesetting + glamor, only planar XVideo fmts are available, and xawtv will chose a matching capture format to avoid needing to do conversion, triggering the solid green window problem. Signed-off-by: Hans de Goede Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit ebbab5519da3ca7537772f145dbd3360dda421ad Author: Dmitry Tunin Date: Sun Feb 28 11:04:06 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 04ca:3014 commit 81d90442eac779938217c3444b240aa51fd3db47 upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3014 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1546694 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit 5c85e3d6901273bf7b28af947e5d6b6ede3111f7 Author: Bjorn Helgaas Date: Thu Feb 25 14:35:57 2016 -0600 PCI: Disable IO/MEM decoding for devices with non-compliant BARs commit b84106b4e2290c081cdab521fa832596cdfea246 upstream. The PCI config header (first 64 bytes of each device's config space) is defined by the PCI spec so generic software can identify the device and manage its usage of I/O, memory, and IRQ resources. Some non-spec-compliant devices put registers other than BARs where the BARs should be. When the PCI core sizes these "BARs", the reads and writes it does may have unwanted side effects, and the "BAR" may appear to describe non-sensical address space. Add a flag bit to mark non-compliant devices so we don't touch their BARs. Turn off IO/MEM decoding to prevent the devices from consuming address space, since we can't read the BARs to find out what that address space would be. Signed-off-by: Bjorn Helgaas Tested-by: Andi Kleen [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 214bc320f8846c3b065d19ae8a66dc0c522c69f8 Author: Sudip Mukherjee Date: Tue Feb 2 13:21:14 2016 +0530 mac80211: fix memory leak commit ea32f065bd3e3e09f0bcb3042f1664caf6b3e233 upstream. On error we jumped to the error label and returned the error code but we missed releasing sinfo. Fixes: 5fe74014172d ("mac80211: avoid excessive stack usage in sta_info") Reviewed-by: Julian Calaby Signed-off-by: Sudip Mukherjee Signed-off-by: Johannes Berg [bwh: Backported to 3.2: there's no out_err label but there is another error case that would leak sinfo] Signed-off-by: Ben Hutchings commit eefa363eb2e49f371f6fc2cd4f4def4de5943fc1 Author: Arnd Bergmann Date: Tue Jan 26 23:05:31 2016 +0100 mac80211: avoid excessive stack usage in sta_info commit 0ef049dc1167fe834d0ad5d63f89eddc5c70f6e4 upstream. When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish function consumes more stack than normally, exceeding the 1024 byte limit on ARM: net/mac80211/sta_info.c: In function 'sta_info_insert_finish': net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] It turns out that there are two functions that put a 'struct station_info' on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and this structure alone requires up to 792 bytes. Hoping that both are called rarely enough, this replaces the on-stack structure with a dynamic allocation, which unfortunately requires some suboptimal error handling for out-of-memory. The __sta_info_destroy_part2 function is actually affected by the stack usage twice because it calls cfg80211_del_sta_sinfo(), which has another instance of struct station_info on its stack. Signed-off-by: Arnd Bergmann Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events") Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event") Signed-off-by: Johannes Berg [bwh: Backported to 3.2: - There's only one instance to fix - Adjust context,indentation - Use 'return' instead of 'goto out_err'] Signed-off-by: Ben Hutchings commit dccef52958cc5d654a8e8be3e1578a2b435c538f Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:02 2016 -0800 aacraid: Fix memory leak in aac_fib_map_free commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream. aac_fib_map_free() calls pci_free_consistent() without checking that dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are indeed NULL/0, this will result in a hang as pci_free_consistent() will attempt to invalidate cache for the entire 64-bit address space (which would take a very long time). Fixed by adding a check to make sure that dev->hw_fib_va and dev->max_fib_size are not NULL and 0 respectively. Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset" Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit a2a19068f78a35b04b034397e64e23a0501cf96c Author: Dmitry Tunin Date: Wed Feb 10 00:49:11 2016 +0300 Bluetooth: Add new AR3012 ID 0489:e095 commit 28c971d82fb58ef7cba22e5308be6d2d2590473d upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e095 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb This device requires ar3k/AthrBT_0x31010100.dfu and ar3k/ramps_0x31010100_40.dfu firmware files that are not in linux-firmware yet. BugLink: https://bugs.launchpad.net/bugs/1542944 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit e36ba87be8ae9faf2801fee6065b7c03d56104aa Author: Dmitry Tunin Date: Wed Feb 10 15:33:17 2016 +0300 Bluetooth: btusb: Add new AR3012 ID 13d3:3395 commit 609574eb46335cfac1421a07c0505627cbbab1f0 upstream. T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3395 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1542564 Reported-and-tested-by: Christopher Simerly Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit 4a18f291cbb555319084ed072da98cd0c1961c85 Author: Hans de Goede Date: Sun Feb 14 17:51:37 2016 -0200 saa7134: Fix bytesperline not being set correctly for planar formats commit 3e71da19f9dc22e39a755d6ae9678661abb66adc upstream. bytesperline should be the bytesperline for the first plane for planar formats, not that of all planes combined. This fixes a crash in xawtv caused by the wrong bpl. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389 Reported-and-tested-by: Stas Sergeev Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit 325d8837beeb60ab8dd53f6df56860654fa8cdd7 Author: Oliver Neukum Date: Wed Feb 10 11:33:18 2016 +0100 usb: retry reset if a device times out commit 264904ccc33c604d4b3141bbd33808152dfac45b upstream. Some devices I got show an inability to operate right after power on if they are already connected. They are beyond recovery if the descriptors are requested multiple times. So in case of a timeout we rather bail early and reset again. But it must be done only on the first loop lest we get into a reset/time out spiral that can be overcome with a retry. This patch is a rework of a patch that fell through the cracks. http://www.spinics.net/lists/linux-usb/msg103263.html Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 23397e31d3c8243b07b3b4cca6663a5672ffadfa Author: Peter Hurley Date: Sat Jan 9 17:48:45 2016 -0800 net: irda: Fix use-after-free in irtty_open() commit 401879c57f01cbf2da204ad2e8db910525c6dbea upstream. The N_IRDA line discipline may access the previous line discipline's closed and already-fre private data on open [1]. The tty->disc_data field _never_ refers to valid data on entry to the line discipline's open() method. Rather, the ldisc is expected to initialize that field for its own use for the lifetime of the instance (ie. from open() to close() only). [1] ================================================================== BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr ffff8800331dd068 Read of size 4 by task a.out/13960 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- ... Call Trace: [] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279 [] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436 [] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447 [] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883 [< inline >] vfs_ioctl fs/ioctl.c:43 [] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607 [< inline >] SYSC_ioctl fs/ioctl.c:622 [] SyS_ioctl+0x74/0x80 fs/ioctl.c:613 [] entry_SYSCALL_64_fastpath+0x16/0x7a Reported-and-tested-by: Dmitry Vyukov Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8fb7e4488e20229828e54187b6aa3ed5cd7cb315 Author: Sebastian Frias Date: Fri Dec 18 17:40:05 2015 +0100 8250: use callbacks to access UART_DLL/UART_DLM commit 0b41ce991052022c030fd868e03877700220b090 upstream. Some UART HW has a single register combining UART_DLL/UART_DLM (this was probably forgotten in the change that introduced the callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9) Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...") Signed-off-by: Sebastian Frias Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust filename - We're using serial_{in,out}p for 8-bit I/O] Signed-off-by: Ben Hutchings commit 04f9f49992bc7097e2f408b18c1523ca58169196 Author: Hans de Goede Date: Fri Jan 22 08:53:55 2016 -0200 pwc: Add USB id for Philips Spc880nc webcam commit 7445e45d19a09e5269dc85f17f9635be29d2f76c upstream. SPC 880NC PC camera discussions: http://www.pclinuxos.com/forum/index.php/topic,135688.0.html Reported-by: Kikim Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit e0d2e02bdbc134227459f0feccc7fa6a14b50966 Author: Dan Carpenter Date: Wed Jan 20 12:54:51 2016 +0300 EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr() commit 6f3508f61c814ee852c199988a62bd954c50dfc1 upstream. dct_sel_base_off is declared as a u64 but we're only using the lower 32 bits because of a shift wrapping bug. This can possibly truncate the upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS row. Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset') Signed-off-by: Dan Carpenter Cc: Aravind Gopalakrishnan Cc: linux-edac Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings