linux-stable.git/drivers/net, branch v3.4.111 Linux kernel stable tree ppp, slip: Validate VJ compression slot parameters completely 2016-03-21T01:17:54+00:00 Ben Hutchings ben@decadent.org.uk 2015-11-01T16:22:53+00:00 a1c3860d3c5fc62bd35f089bcb03f18a37242de9 commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae upstream. Currently slhc_init() treats out-of-range values of rslots and tslots as equivalent to 0, except that if tslots is too large it will dereference a null pointer (CVE-2015-7799). Add a range-check at the top of the function and make it return an ERR_PTR() on error instead of NULL. Change the callers accordingly. Compile-tested only. Reported-by: 郭永刚 <guoyonggang@360.cn> References: http://article.gmane.org/gmane.comp.security.oss.general/17908 Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae upstream.

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 <guoyonggang@360.cn>
References: http://article.gmane.org/gmane.comp.security.oss.general/17908
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
virtio-net: drop NETIF_F_FRAGLIST 2016-03-21T01:17:54+00:00 Jason Wang jasowang@redhat.com 2015-08-05T02:34:04+00:00 35464982a0fb1dcaf540c4dd5564de3f90f7a1a5 commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 upstream. virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 upstream.

virtio declares support for NETIF_F_FRAGLIST, but assumes
that there are at most MAX_SKB_FRAGS + 2 fragments which isn't
always true with a fraglist.

A longer fraglist in the skb will make the call to skb_to_sgvec overflow
the sg array, leading to memory corruption.

Drop NETIF_F_FRAGLIST so we only get what we can handle.

Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
pptp: verify sockaddr_len in pptp_bind() and pptp_connect() 2016-03-21T01:17:53+00:00 WANG Cong xiyou.wangcong@gmail.com 2015-12-14T21:48:36+00:00 0cf0ae366ff94870075cbe0a8f3a16a2107ae853 commit 09ccfd238e5a0e670d8178cf50180ea81ae09ae1 upstream. Reported-by: Dmitry Vyukov <dvyukov@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 09ccfd238e5a0e670d8178cf50180ea81ae09ae1 upstream.

Reported-by: Dmitry Vyukov <dvyukov@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
niu: don't count tx error twice in case of headroom realloc fails 2016-03-21T01:17:48+00:00 Jiri Pirko jiri@resnulli.us 2015-07-23T10:20:37+00:00 50f46c9771c42d5d21979d93155ec8bb9f4ea69a commit 42288830494cd51873ca745a7a229023df061226 upstream. Fixes: a3138df9 ("[NIU]: Add Sun Neptune ethernet driver.") Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 42288830494cd51873ca745a7a229023df061226 upstream.

Fixes: a3138df9 ("[NIU]: Add Sun Neptune ethernet driver.")
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
can: mcp251x: fix resume when device is down 2016-03-21T01:17:45+00:00 Stefan Agner stefan@agner.ch 2015-05-18T16:33:27+00:00 45ceb60e13119ead510fb76882e5744a5802c5e1 commit 25b401c1816ae64bcc5dcb1d39ab41812522a0ce upstream. If a valid power regulator or a dummy regulator is used (which happens to be the case when no regulator is specified), restart_work is queued no matter whether the device was running or not at suspend time. Since work queues get initialized in the ndo_open callback, resuming leads to a NULL pointer exception. Reverse exactly the steps executed at suspend time: - Enable the power regulator in any case - Enable the transceiver regulator if the device was running, even in case we have a power regulator - Queue restart_work only in case the device was running Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> [lizf: Backported to 3.4: - adjust filename - adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 25b401c1816ae64bcc5dcb1d39ab41812522a0ce upstream.

If a valid power regulator or a dummy regulator is used (which
happens to be the case when no regulator is specified), restart_work
is queued no matter whether the device was running or not at suspend
time. Since work queues get initialized in the ndo_open callback,
resuming leads to a NULL pointer exception.

Reverse exactly the steps executed at suspend time:
- Enable the power regulator in any case
- Enable the transceiver regulator if the device was running, even in
  case we have a power regulator
- Queue restart_work only in case the device was running

Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
[lizf: Backported to 3.4:
 - adjust filename
 - adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
stmmac: troubleshoot unexpected bits in des0 & des1 2015-10-22T01:20:06+00:00 Alexey Brodkin Alexey.Brodkin@synopsys.com 2015-06-24T08:47:41+00:00 176a2eacd65fbc3b3d911605a83d3262770fc213 commit f1590670ce069eefeb93916391a67643e6ad1630 upstream. Current implementation of descriptor init procedure only takes care about setting/clearing ownership flag in "des0"/"des1" fields while it is perfectly possible to get unexpected bits set because of the following factors: [1] On driver probe underlying memory allocated with dma_alloc_coherent() might not be zeroed and so it will be filled with garbage. [2] During driver operation some bits could be set by SD/MMC controller (for example error flags etc). And unexpected and/or randomly set flags in "des0"/"des1" fields may lead to unpredictable behavior of GMAC DMA block. This change addresses both items above with: [1] Use of dma_zalloc_coherent() instead of simple dma_alloc_coherent() to make sure allocated memory is zeroed. That shouldn't affect performance because this allocation only happens once on driver probe. [2] Do explicit zeroing of both "des0" and "des1" fields of all buffer descriptors during initialization of DMA transfer. And while at it fixed identation of dma_free_coherent() counterpart as well. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Cc: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> [lizf: Backported to 3.4: - adjust contest - adjust allocations in init_dma_desc_rings()] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
     dma_alloc_coherent() might not be zeroed and so
     it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
     controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
     dma_alloc_coherent() to make sure allocated memory is
     zeroed. That shouldn't affect performance because
     this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
     of all buffer descriptors during initialization of
     DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: arc-linux-dev@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[lizf: Backported to 3.4:
 - adjust contest
 - adjust allocations in init_dma_desc_rings()]
Signed-off-by: Zefan Li <lizefan@huawei.com>
ath9k: fix DMA stop sequence for AR9003+ 2015-10-22T01:20:03+00:00 Felix Fietkau nbd@openwrt.org 2015-06-02T08:38:32+00:00 675350c16cb51f1fc0037e60f6315830c541ca60 commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream. AR93xx and newer needs to stop rx before tx to avoid getting the DMA engine or MAC into a stuck state. This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> [lizf: Backported to 3.4: - initialize ret - ath_drain_all_txq() takes a second argument] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[lizf: Backported to 3.4:
 - initialize ret
 - ath_drain_all_txq() takes a second argument]
Signed-off-by: Zefan Li <lizefan@huawei.com>
rndis_wlan: harmless issue calling set_bit() 2015-10-22T01:20:02+00:00 Dan Carpenter dan.carpenter@oracle.com 2015-05-14T08:37:50+00:00 c645884784fb37eceee48e7024585e580942e0c9 commit e3958e9d60b4570fff709f397ef5c6b8483f40f7 upstream. These are used like: set_bit(WORK_LINK_UP, &priv->work_pending); The problem is that set_bit() takes the actual bit number and not a mask so static checkers get upset. It doesn't affect run time because we do it consistently, but we may as well clean it up. Fixes: 6010ce07a66c ('rndis_wlan: do link-down state change in worker thread') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit e3958e9d60b4570fff709f397ef5c6b8483f40f7 upstream.

These are used like:

	set_bit(WORK_LINK_UP, &priv->work_pending);

The problem is that set_bit() takes the actual bit number and not a mask
so static checkers get upset.  It doesn't affect run time because we do
it consistently, but we may as well clean it up.

Fixes: 6010ce07a66c ('rndis_wlan: do link-down state change in worker thread')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
rtlwifi: rtl8192cu: Fix kernel deadlock 2015-09-18T01:20:37+00:00 Larry Finger Larry.Finger@lwfinger.net 2015-04-24T16:03:37+00:00 b7e7b11a149e6b3a0c12ab3f9699c014d509b615 commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg() with a timeout value of 0. In some instances where the interface is shutting down, this infinite wait results in a CPU deadlock. A one second timeout fixes this problem without affecting any normal operations. This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786. Reported-by: Bernhard Wiedemann <bwiedemann@suse.com> Tested-by: Bernhard Wiedemann <bwiedemann@suse.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Bernhard Wiedemann <bwiedemann@suse.com> Cc: Takashi Iwai<tiwai@suse.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.

The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.

This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786.

Reported-by: Bernhard Wiedemann <bwiedemann@suse.com>
Tested-by: Bernhard Wiedemann <bwiedemann@suse.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Bernhard Wiedemann <bwiedemann@suse.com>
Cc: Takashi Iwai<tiwai@suse.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
rtlwifi: rtl8192cu: Add new USB ID 2015-09-18T01:20:26+00:00 Larry Finger Larry.Finger@lwfinger.net 2015-03-23T23:14:10+00:00 971fb0e210d8ea24e453f111341724807e491f3e commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream. USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.

USB ID 2001:330d is used for a D-Link DWA-131.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>