* [PATCH AUTOSEL 5.1 005/219] wil6210: fix potential out-of-bounds read
From: Sasha Levin @ 2019-07-15 14:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gustavo A. R. Silva, Maya Erez, Kalle Valo, Sasha Levin,
linux-wireless, wil6210, netdev
In-Reply-To: <20190715140341.6443-1-sashal@kernel.org>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
[ Upstream commit bfabdd6997323adbedccb13a3fed1967fb8cf8f5 ]
Notice that *rc* can evaluate to up to 5, include/linux/netdevice.h:
enum gro_result {
GRO_MERGED,
GRO_MERGED_FREE,
GRO_HELD,
GRO_NORMAL,
GRO_DROP,
GRO_CONSUMED,
};
typedef enum gro_result gro_result_t;
In case *rc* evaluates to 5, we end up having an out-of-bounds read
at drivers/net/wireless/ath/wil6210/txrx.c:821:
wil_dbg_txrx(wil, "Rx complete %d bytes => %s\n",
len, gro_res_str[rc]);
Fix this by adding element "GRO_CONSUMED" to array gro_res_str.
Addresses-Coverity-ID: 1444666 ("Out-of-bounds read")
Fixes: 194b482b5055 ("wil6210: Debug print GRO Rx result")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/wil6210/txrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 4ccfd1404458..d74837cce67f 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -750,6 +750,7 @@ void wil_netif_rx_any(struct sk_buff *skb, struct net_device *ndev)
[GRO_HELD] = "GRO_HELD",
[GRO_NORMAL] = "GRO_NORMAL",
[GRO_DROP] = "GRO_DROP",
+ [GRO_CONSUMED] = "GRO_CONSUMED",
};
wil->txrx_ops.get_netif_rx_params(skb, &cid, &security);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 004/219] ath9k: Don't trust TX status TID number when reporting airtime
From: Sasha Levin @ 2019-07-15 14:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Toke Høiland-Jørgensen, Miguel Catalan Cid, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715140341.6443-1-sashal@kernel.org>
From: Toke Høiland-Jørgensen <toke@redhat.com>
[ Upstream commit 389b72e58259336c2d56d58b660b79cf4b9e0dcb ]
As already noted a comment in ath_tx_complete_aggr(), the hardware will
occasionally send a TX status with the wrong tid number. If we trust the
value, airtime usage will be reported to the wrong AC, which can cause the
deficit on that AC to become very low, blocking subsequent attempts to
transmit.
To fix this, account airtime usage to the TID number from the original skb,
instead of the one in the hardware TX status report.
Reported-by: Miguel Catalan Cid <miguel.catalan@i2cat.net>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b17e1ca40995..3be0aeedb9b5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -668,7 +668,8 @@ static bool bf_is_ampdu_not_probing(struct ath_buf *bf)
static void ath_tx_count_airtime(struct ath_softc *sc,
struct ieee80211_sta *sta,
struct ath_buf *bf,
- struct ath_tx_status *ts)
+ struct ath_tx_status *ts,
+ u8 tid)
{
u32 airtime = 0;
int i;
@@ -679,7 +680,7 @@ static void ath_tx_count_airtime(struct ath_softc *sc,
airtime += rate_dur * bf->rates[i].count;
}
- ieee80211_sta_register_airtime(sta, ts->tid, airtime, 0);
+ ieee80211_sta_register_airtime(sta, tid, airtime, 0);
}
static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
@@ -709,7 +710,7 @@ static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
if (sta) {
struct ath_node *an = (struct ath_node *)sta->drv_priv;
tid = ath_get_skb_tid(sc, an, bf->bf_mpdu);
- ath_tx_count_airtime(sc, sta, bf, ts);
+ ath_tx_count_airtime(sc, sta, bf, ts, tid->tidno);
if (ts->ts_status & (ATH9K_TXERR_FILT | ATH9K_TXERR_XRETRY))
tid->clear_ps_filter = true;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 003/219] ath10k: fix incorrect multicast/broadcast rate setting
From: Sasha Levin @ 2019-07-15 14:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Pradeep kumar Chitrapu, Zhi Chen, Sven Eckelmann, Kalle Valo,
Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20190715140341.6443-1-sashal@kernel.org>
From: Pradeep kumar Chitrapu <pradeepc@codeaurora.org>
[ Upstream commit 93ee3d108fc77e19efeac3ec5aa7d5886711bfef ]
Invalid rate code is sent to firmware when multicast rate value of 0 is
sent to driver indicating disabled case, causing broken mesh path.
so fix that.
Tested on QCA9984 with firmware 10.4-3.6.1-00827
Sven tested on IPQ4019 with 10.4-3.5.3-00057 and QCA9888 with 10.4-3.5.3-00053
(ath10k-firmware) and 10.4-3.6-00140 (linux-firmware 2018-12-16-211de167).
Fixes: cd93b83ad92 ("ath10k: support for multicast rate control")
Co-developed-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..e8997e22ceec 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5588,8 +5588,8 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
struct cfg80211_chan_def def;
u32 vdev_param, pdev_param, slottime, preamble;
u16 bitrate, hw_value;
- u8 rate, basic_rate_idx;
- int rateidx, ret = 0, hw_rate_code;
+ u8 rate, basic_rate_idx, rateidx;
+ int ret = 0, hw_rate_code, mcast_rate;
enum nl80211_band band;
const struct ieee80211_supported_band *sband;
@@ -5776,7 +5776,11 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_MCAST_RATE &&
!ath10k_mac_vif_chan(arvif->vif, &def)) {
band = def.chan->band;
- rateidx = vif->bss_conf.mcast_rate[band] - 1;
+ mcast_rate = vif->bss_conf.mcast_rate[band];
+ if (mcast_rate > 0)
+ rateidx = mcast_rate - 1;
+ else
+ rateidx = ffs(vif->bss_conf.basic_rates) - 1;
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 002/219] ath10k: htt: don't use txdone_fifo with SDIO
From: Sasha Levin @ 2019-07-15 14:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alagu Sankar, Wen Gong, Kalle Valo, Sasha Levin, ath10k,
linux-wireless, netdev
In-Reply-To: <20190715140341.6443-1-sashal@kernel.org>
From: Alagu Sankar <alagusankar@silex-india.com>
[ Upstream commit e2a6b711282a371c5153239e0468a48254f17ca6 ]
HTT High Latency (ATH10K_DEV_TYPE_HL) does not use txdone_fifo at all, we don't
even initialise it by skipping ath10k_htt_tx_alloc_buf() in
ath10k_htt_tx_start(). Because of this using QCA6174 SDIO
ath10k_htt_rx_tx_compl_ind() will crash when it accesses unitialised
txdone_fifo. So skip txdone_fifo when using High Latency mode.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 1acc622d2183..f22840bbc389 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2277,7 +2277,9 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
* Note that with only one concurrent reader and one concurrent
* writer, you don't need extra locking to use these macro.
*/
- if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
+ if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) {
+ ath10k_txrx_tx_unref(htt, &tx_done);
+ } else if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status %d\n",
tx_done.msdu_id, tx_done.status);
ath10k_txrx_tx_unref(htt, &tx_done);
--
2.20.1
^ permalink raw reply related
* Re: INFO: rcu detected stall in ext4_write_checks
From: Paul E. McKenney @ 2019-07-15 14:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Theodore Ts'o, Dmitry Vyukov, syzbot, Andreas Dilger,
David Miller, eladr, Ido Schimmel, Jiri Pirko, John Stultz,
linux-ext4, LKML, netdev, syzkaller-bugs, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20190715133938.GH3419@hirez.programming.kicks-ass.net>
On Mon, Jul 15, 2019 at 03:39:38PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 15, 2019 at 06:01:01AM -0700, Paul E. McKenney wrote:
> > Title: Making SCHED_DEADLINE safe for kernel kthreads
> >
> > Abstract:
> >
> > Dmitry Vyukov's testing work identified some (ab)uses of sched_setattr()
> > that can result in SCHED_DEADLINE tasks starving RCU's kthreads for
> > extended time periods, not millisecond, not seconds, not minutes, not even
> > hours, but days. Given that RCU CPU stall warnings are issued whenever
> > an RCU grace period fails to complete within a few tens of seconds,
> > the system did not suffer silently. Although one could argue that people
> > should avoid abusing sched_setattr(), people are human and humans make
> > mistakes. Responding to simple mistakes with RCU CPU stall warnings is
> > all well and good, but a more severe case could OOM the system, which
> > is a particularly unhelpful error message.
> >
> > It would be better if the system were capable of operating reasonably
> > despite such abuse. Several approaches have been suggested.
> >
> > First, sched_setattr() could recognize parameter settings that put
> > kthreads at risk and refuse to honor those settings. This approach
> > of course requires that we identify precisely what combinations of
> > sched_setattr() parameters settings are risky, especially given that there
> > are likely to be parameter settings that are both risky and highly useful.
>
> So we (the people poking at the DEADLINE code) are all aware of this,
> and on the TODO list for making DEADLINE available for !priv users is
> the item:
>
> - put limits on deadline/period
>
> And note that that is both an upper and lower limit. The upper limit
> you've just found why we need it, the lower limit is required because
> you can DoS the hardware by causing deadlines/periods that are equal (or
> shorter) than the time it takes to program the hardware.
>
> There might have even been some patches that do some of this, but I've
> held off because we have bigger problems and they would've established
> an ABI while it wasn't clear it was sufficient or the right form.
So I should withdraw the proposal?
Thanx, Paul
^ permalink raw reply
* [PATCH AUTOSEL 5.2 249/249] net: mvmdio: defer probe of orion-mdio if a clock is not ready
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Josua Mayer, Andrew Lunn, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Josua Mayer <josua@solid-run.com>
[ Upstream commit 433a06d7d74e677c40b1148c70c48677ff62fb6b ]
Defer probing of the orion-mdio interface when getting a clock returns
EPROBE_DEFER. This avoids locking up the Armada 8k SoC when mdio is used
before all clocks have been enabled.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/marvell/mvmdio.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index c5dac6bd2be4..903836e334d8 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -321,6 +321,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+ if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out_clk;
+ }
if (IS_ERR(dev->clk[i]))
break;
clk_prepare_enable(dev->clk[i]);
@@ -362,6 +366,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
if (dev->err_interrupt > 0)
writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+out_clk:
for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
if (IS_ERR(dev->clk[i]))
break;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 247/249] gtp: fix use-after-free in gtp_newlink()
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Taehee Yoo, David S . Miller, Sasha Levin, osmocom-net-gprs,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ]
Current gtp_newlink() could be called after unregister_pernet_subsys().
gtp_newlink() uses gtp_net but it can be destroyed by
unregister_pernet_subsys().
So unregister_pernet_subsys() should be called after
rtnl_link_unregister().
Test commands:
#SHELL 1
while :
do
for i in {1..5}
do
./gtp-link add gtp$i &
done
killall gtp-link
done
#SHELL 2
while :
do
modprobe -rv gtp
done
Splat looks like:
[ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126
[ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50
[ 753.185801] Call Trace:
[ 753.186264] dump_stack+0x7c/0xbb
[ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.187583] print_address_description+0xc7/0x240
[ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.189846] __kasan_report+0x12a/0x16f
[ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.191298] kasan_report+0xe/0x20
[ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp]
[ 753.192580] ? __netlink_ns_capable+0xc3/0xf0
[ 753.193370] __rtnl_newlink+0xb9f/0x11b0
[ ... ]
[ 753.241201] Allocated by task 7186:
[ 753.241844] save_stack+0x19/0x80
[ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 753.243192] __kmalloc+0x13e/0x300
[ 753.243764] ops_init+0xd6/0x350
[ 753.244314] register_pernet_operations+0x249/0x6f0
[ ... ]
[ 753.251770] Freed by task 7178:
[ 753.252288] save_stack+0x19/0x80
[ 753.252833] __kasan_slab_free+0x111/0x150
[ 753.253962] kfree+0xc7/0x280
[ 753.254509] ops_free_list.part.11+0x1c4/0x2d0
[ 753.255241] unregister_pernet_operations+0x262/0x390
[ ... ]
[ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next.
[ 753.287241] ------------[ cut here ]------------
[ 753.287794] kernel BUG at lib/list_debug.c:25!
[ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50
[ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0
[ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b
[ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286
[ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000
[ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69
[ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21
[ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878
[ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458
[ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000
[ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0
[ 753.302183] Call Trace:
[ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp]
[ 753.303037] ? __netlink_ns_capable+0xc3/0xf0
[ 753.303576] __rtnl_newlink+0xb9f/0x11b0
[ 753.304092] ? rtnl_link_unregister+0x230/0x230
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 5615cdb7202c..607f38712b4e 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -1382,9 +1382,9 @@ late_initcall(gtp_init);
static void __exit gtp_fini(void)
{
- unregister_pernet_subsys(>p_net_ops);
genl_unregister_family(>p_genl_family);
rtnl_link_unregister(>p_link_ops);
+ unregister_pernet_subsys(>p_net_ops);
pr_info("GTP module unloaded\n");
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 248/249] xdp: fix race on generic receive path
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ilya Maximets, Magnus Karlsson, William Tu, Daniel Borkmann,
Sasha Levin, netdev, xdp-newbies, bpf
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Ilya Maximets <i.maximets@samsung.com>
[ Upstream commit bf0bdd1343efbbf65b4d53aef1fce14acbd79d50 ]
Unlike driver mode, generic xdp receive could be triggered
by different threads on different CPU cores at the same time
leading to the fill and rx queue breakage. For example, this
could happen while sending packets from two processes to the
first interface of veth pair while the second part of it is
open with AF_XDP socket.
Need to take a lock for each generic receive to avoid race.
Fixes: c497176cb2e4 ("xsk: add Rx receive functions and poll support")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Tested-by: William Tu <u9012063@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/xdp_sock.h | 2 ++
net/xdp/xsk.c | 31 ++++++++++++++++++++++---------
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index d074b6d60f8a..ac3c047d058c 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -67,6 +67,8 @@ struct xdp_sock {
* in the SKB destructor callback.
*/
spinlock_t tx_completion_lock;
+ /* Protects generic receive. */
+ spinlock_t rx_lock;
u64 rx_dropped;
};
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index a14e8864e4fa..5e0637db92ea 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -123,13 +123,17 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
u64 addr;
int err;
- if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
- return -EINVAL;
+ spin_lock_bh(&xs->rx_lock);
+
+ if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index) {
+ err = -EINVAL;
+ goto out_unlock;
+ }
if (!xskq_peek_addr(xs->umem->fq, &addr) ||
len > xs->umem->chunk_size_nohr - XDP_PACKET_HEADROOM) {
- xs->rx_dropped++;
- return -ENOSPC;
+ err = -ENOSPC;
+ goto out_drop;
}
addr += xs->umem->headroom;
@@ -138,13 +142,21 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
memcpy(buffer, xdp->data_meta, len + metalen);
addr += metalen;
err = xskq_produce_batch_desc(xs->rx, addr, len);
- if (!err) {
- xskq_discard_addr(xs->umem->fq);
- xsk_flush(xs);
- return 0;
- }
+ if (err)
+ goto out_drop;
+
+ xskq_discard_addr(xs->umem->fq);
+ xskq_produce_flush_desc(xs->rx);
+ spin_unlock_bh(&xs->rx_lock);
+
+ xs->sk.sk_data_ready(&xs->sk);
+ return 0;
+
+out_drop:
xs->rx_dropped++;
+out_unlock:
+ spin_unlock_bh(&xs->rx_lock);
return err;
}
@@ -765,6 +777,7 @@ static int xsk_create(struct net *net, struct socket *sock, int protocol,
xs = xdp_sk(sk);
mutex_init(&xs->mutex);
+ spin_lock_init(&xs->rx_lock);
spin_lock_init(&xs->tx_completion_lock);
mutex_lock(&net->xdp.lock);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 246/249] gtp: fix use-after-free in gtp_encap_destroy()
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Taehee Yoo, David S . Miller, Sasha Levin, osmocom-net-gprs,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ]
gtp_encap_destroy() is called twice.
1. When interface is deleted.
2. When udp socket is destroyed.
either gtp->sk0 or gtp->sk1u could be freed by sock_put() in
gtp_encap_destroy(). so, when gtp_encap_destroy() is called again,
it would uses freed sk pointer.
patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to
null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected
by rtnl_lock. so, rtnl_lock() is added.
Test command:
gtp-link add gtp1 &
killall gtp-link
ip link del gtp1
Splat looks like:
[ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0
[ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008
[ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50
[ 83.188469] Call Trace:
[ ... ]
[ 83.200126] lock_acquire+0x141/0x380
[ 83.200575] ? lock_sock_nested+0x3a/0xf0
[ 83.201069] _raw_spin_lock_bh+0x38/0x70
[ 83.201551] ? lock_sock_nested+0x3a/0xf0
[ 83.202044] lock_sock_nested+0x3a/0xf0
[ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp]
[ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp]
[ 83.203687] gtp_dellink+0x56/0x170 [gtp]
[ 83.204190] rtnl_delete_link+0xb4/0x100
[ ... ]
[ 83.236513] Allocated by task 976:
[ 83.236925] save_stack+0x19/0x80
[ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 83.237894] kmem_cache_alloc+0xd8/0x280
[ 83.238360] sk_prot_alloc.isra.42+0x50/0x200
[ 83.238874] sk_alloc+0x32/0x940
[ 83.239264] inet_create+0x283/0xc20
[ 83.239684] __sock_create+0x2dd/0x540
[ 83.240136] __sys_socket+0xca/0x1a0
[ 83.240550] __x64_sys_socket+0x6f/0xb0
[ 83.240998] do_syscall_64+0x9c/0x450
[ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 83.242061]
[ 83.242249] Freed by task 0:
[ 83.242616] save_stack+0x19/0x80
[ 83.243013] __kasan_slab_free+0x111/0x150
[ 83.243498] kmem_cache_free+0x89/0x250
[ 83.244444] __sk_destruct+0x38f/0x5a0
[ 83.245366] rcu_core+0x7e9/0x1c20
[ 83.245766] __do_softirq+0x213/0x8fa
Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/gtp.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index b770335c03c1..5615cdb7202c 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -285,13 +285,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb)
return gtp_rx(pctx, skb, hdrlen, gtp->role);
}
-static void gtp_encap_destroy(struct sock *sk)
+static void __gtp_encap_destroy(struct sock *sk)
{
struct gtp_dev *gtp;
lock_sock(sk);
gtp = sk->sk_user_data;
if (gtp) {
+ if (gtp->sk0 == sk)
+ gtp->sk0 = NULL;
+ else
+ gtp->sk1u = NULL;
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
@@ -299,12 +303,19 @@ static void gtp_encap_destroy(struct sock *sk)
release_sock(sk);
}
+static void gtp_encap_destroy(struct sock *sk)
+{
+ rtnl_lock();
+ __gtp_encap_destroy(sk);
+ rtnl_unlock();
+}
+
static void gtp_encap_disable_sock(struct sock *sk)
{
if (!sk)
return;
- gtp_encap_destroy(sk);
+ __gtp_encap_destroy(sk);
}
static void gtp_encap_disable(struct gtp_dev *gtp)
@@ -1043,6 +1054,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ rtnl_lock();
rcu_read_lock();
gtp = gtp_find_dev(sock_net(skb->sk), info->attrs);
@@ -1067,6 +1079,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info)
out_unlock:
rcu_read_unlock();
+ rtnl_unlock();
return err;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 245/249] gtp: fix Illegal context switch in RCU read-side critical section.
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Taehee Yoo, David S . Miller, Sasha Levin, osmocom-net-gprs,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ]
ipv4_pdp_add() is called in RCU read-side critical section.
So GFP_KERNEL should not be used in the function.
This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL.
Test commands:
gtp-link add gtp1 &
gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2
Splat looks like:
[ 130.618881] =============================
[ 130.626382] WARNING: suspicious RCU usage
[ 130.626994] 5.2.0-rc6+ #50 Not tainted
[ 130.627622] -----------------------------
[ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section!
[ 130.629684]
[ 130.629684] other info that might help us debug this:
[ 130.629684]
[ 130.631022]
[ 130.631022] rcu_scheduler_active = 2, debug_locks = 1
[ 130.632136] 4 locks held by gtp-tunnel/1025:
[ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40
[ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130
[ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp]
[ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp]
[ 130.638348]
[ 130.638348] stack backtrace:
[ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50
[ 130.641318] Call Trace:
[ 130.641707] dump_stack+0x7c/0xbb
[ 130.642252] ___might_sleep+0x2c0/0x3b0
[ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0
[ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp]
[ 130.644371] genl_family_rcv_msg+0x63a/0x1030
[ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090
[ 130.645845] ? genl_unregister_family+0x630/0x630
[ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0
[ 130.647293] ? check_flags.part.40+0x440/0x440
[ 130.648099] genl_rcv_msg+0xa3/0x130
[ ... ]
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 61f19e66be55..b770335c03c1 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -954,7 +954,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk,
}
- pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL);
+ pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC);
if (pctx == NULL)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 244/249] gtp: fix suspicious RCU usage
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Taehee Yoo, David S . Miller, Sasha Levin, osmocom-net-gprs,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ]
gtp_encap_enable_socket() and gtp_encap_destroy() are not protected
by rcu_read_lock(). and it's not safe to write sk->sk_user_data.
This patch make these functions to use lock_sock() instead of
rcu_dereference_sk_user_data().
Test commands:
gtp-link add gtp1
Splat looks like:
[ 83.238315] =============================
[ 83.239127] WARNING: suspicious RCU usage
[ 83.239702] 5.2.0-rc6+ #49 Not tainted
[ 83.240268] -----------------------------
[ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage!
[ 83.243828]
[ 83.243828] other info that might help us debug this:
[ 83.243828]
[ 83.246325]
[ 83.246325] rcu_scheduler_active = 2, debug_locks = 1
[ 83.247314] 1 lock held by gtp-link/1008:
[ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0
[ 83.251503]
[ 83.251503] stack backtrace:
[ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49
[ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 83.254562] Call Trace:
[ 83.254995] dump_stack+0x7c/0xbb
[ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp]
[ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp]
[ 83.257161] ? memset+0x1f/0x40
[ 83.257843] gtp_newlink+0x90/0xa21 [gtp]
[ 83.258497] ? __netlink_ns_capable+0xc3/0xf0
[ 83.259260] __rtnl_newlink+0xb9f/0x11b0
[ 83.260022] ? rtnl_link_unregister+0x230/0x230
[ ... ]
Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/gtp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 01fc51892e48..61f19e66be55 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -289,12 +289,14 @@ static void gtp_encap_destroy(struct sock *sk)
{
struct gtp_dev *gtp;
- gtp = rcu_dereference_sk_user_data(sk);
+ lock_sock(sk);
+ gtp = sk->sk_user_data;
if (gtp) {
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
}
+ release_sock(sk);
}
static void gtp_encap_disable_sock(struct sock *sk)
@@ -796,7 +798,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type,
goto out_sock;
}
- if (rcu_dereference_sk_user_data(sock->sk)) {
+ lock_sock(sock->sk);
+ if (sock->sk->sk_user_data) {
sk = ERR_PTR(-EBUSY);
goto out_sock;
}
@@ -812,6 +815,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type,
setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg);
out_sock:
+ release_sock(sock->sk);
sockfd_put(sock);
return sk;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 242/249] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Taehee Yoo, David S . Miller, Sasha Levin, osmocom-net-gprs,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ]
If an invalid role is sent from user space, gtp_encap_enable() will fail.
Then, it should call gtp_encap_disable_sock() but current code doesn't.
It makes memory leak.
Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/gtp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index fc45b749db46..01fc51892e48 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -843,8 +843,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[])
if (data[IFLA_GTP_ROLE]) {
role = nla_get_u32(data[IFLA_GTP_ROLE]);
- if (role > GTP_ROLE_SGSN)
+ if (role > GTP_ROLE_SGSN) {
+ if (sk0)
+ gtp_encap_disable_sock(sk0);
+ if (sk1u)
+ gtp_encap_disable_sock(sk1u);
return -EINVAL;
+ }
}
gtp->sk0 = sk0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 243/249] Bluetooth: validate BLE connection interval updates
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: csonsino, Marcel Holtmann, Sasha Levin, linux-bluetooth, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: csonsino <csonsino@gmail.com>
[ Upstream commit c49a8682fc5d298d44e8d911f4fa14690ea9485e ]
Problem: The Linux Bluetooth stack yields complete control over the BLE
connection interval to the remote device.
The Linux Bluetooth stack provides access to the BLE connection interval
min and max values through /sys/kernel/debug/bluetooth/hci0/
conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
These values are used for initial BLE connections, but the remote device
has the ability to request a connection parameter update. In the event
that the remote side requests to change the connection interval, the Linux
kernel currently only validates that the desired value is within the
acceptable range in the Bluetooth specification (6 - 3200, corresponding to
7.5ms - 4000ms). There is currently no validation that the desired value
requested by the remote device is within the min/max limits specified in
the conn_min_interval/conn_max_interval configurations. This essentially
leads to Linux yielding complete control over the connection interval to
the remote device.
The proposed patch adds a verification step to the connection parameter
update mechanism, ensuring that the desired value is within the min/max
bounds of the current connection. If the desired value is outside of the
current connection min/max values, then the connection parameter update
request is rejected and the negative response is returned to the remote
device. Recall that the initial connection is established using the local
conn_min_interval/conn_max_interval values, so this allows the Linux
administrator to retain control over the BLE connection interval.
The one downside that I see is that the current default Linux values for
conn_min_interval and conn_max_interval typically correspond to 30ms and
50ms respectively. If this change were accepted, then it is feasible that
some devices would no longer be able to negotiate to their desired
connection interval values. This might be remedied by setting the default
Linux conn_min_interval and conn_max_interval values to the widest
supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
behavior as the current implementation, where the remote device could
request to change the connection interval value to any value that is
permitted by the Bluetooth specification, and Linux would accept the
desired value.
Signed-off-by: Carey Sonsino <csonsino@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/hci_event.c | 5 +++++
net/bluetooth/l2cap_core.c | 9 ++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 9e4fcf406d9c..17c50a98e7f7 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5588,6 +5588,11 @@ static void hci_le_remote_conn_param_req_evt(struct hci_dev *hdev,
return send_conn_param_neg_reply(hdev, handle,
HCI_ERROR_UNKNOWN_CONN_ID);
+ if (min < hcon->le_conn_min_interval ||
+ max > hcon->le_conn_max_interval)
+ return send_conn_param_neg_reply(hdev, handle,
+ HCI_ERROR_INVALID_LL_PARAMS);
+
if (hci_check_conn_params(min, max, latency, timeout))
return send_conn_param_neg_reply(hdev, handle,
HCI_ERROR_INVALID_LL_PARAMS);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 771e3e17bb6a..32d2be9d6858 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5297,7 +5297,14 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
memset(&rsp, 0, sizeof(rsp));
- err = hci_check_conn_params(min, max, latency, to_multiplier);
+ if (min < hcon->le_conn_min_interval ||
+ max > hcon->le_conn_max_interval) {
+ BT_DBG("requested connection interval exceeds current bounds.");
+ err = -EINVAL;
+ } else {
+ err = hci_check_conn_params(min, max, latency, to_multiplier);
+ }
+
if (err)
rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
else
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 241/249] Bluetooth: hidp: NUL terminate a string in the compat ioctl
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Marcel Holtmann, Sasha Levin, linux-bluetooth,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit dcae9052ebb0c5b2614de620323d615fcbfda7f8 ]
This change is similar to commit a1616a5ac99e ("Bluetooth: hidp: fix
buffer overflow") but for the compat ioctl. We take a string from the
user and forgot to ensure that it's NUL terminated.
I have also changed the strncpy() in to strscpy() in hidp_setup_hid().
The difference is the strncpy() doesn't necessarily NUL terminate the
destination string. Either change would fix the problem but it's nice
to take a belt and suspenders approach and do both.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/hidp/core.c | 2 +-
net/bluetooth/hidp/sock.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index a442e21f3894..5abd423b55fa 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -775,7 +775,7 @@ static int hidp_setup_hid(struct hidp_session *session,
hid->version = req->version;
hid->country = req->country;
- strncpy(hid->name, req->name, sizeof(hid->name));
+ strscpy(hid->name, req->name, sizeof(hid->name));
snprintf(hid->phys, sizeof(hid->phys), "%pMR",
&l2cap_pi(session->ctrl_sock->sk)->chan->src);
diff --git a/net/bluetooth/hidp/sock.c b/net/bluetooth/hidp/sock.c
index 2151913892ce..03be6a4baef3 100644
--- a/net/bluetooth/hidp/sock.c
+++ b/net/bluetooth/hidp/sock.c
@@ -192,6 +192,7 @@ static int hidp_sock_compat_ioctl(struct socket *sock, unsigned int cmd, unsigne
ca.version = ca32.version;
ca.flags = ca32.flags;
ca.idle_to = ca32.idle_to;
+ ca32.name[sizeof(ca32.name) - 1] = '\0';
memcpy(ca.name, ca32.name, 128);
csock = sockfd_lookup(ca.ctrl_sock, &err);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 240/249] Bluetooth: Check state in l2cap_disconnect_rsp
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Matias Karhumaa, Matti Kamunen, Ari Timonen, Marcel Holtmann,
Sasha Levin, linux-bluetooth, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Matias Karhumaa <matias.karhumaa@gmail.com>
[ Upstream commit 28261da8a26f4915aa257d12d506c6ba179d961f ]
Because of both sides doing L2CAP disconnection at the same time, it
was possible to receive L2CAP Disconnection Response with CID that was
already freed. That caused problems if CID was already reused and L2CAP
Connection Request with same CID was sent out. Before this patch kernel
deleted channel context regardless of the state of the channel.
Example where leftover Disconnection Response (frame #402) causes local
device to delete L2CAP channel which was not yet connected. This in
turn confuses remote device's stack because same CID is re-used without
properly disconnecting.
Btmon capture before patch:
** snip **
> ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949
Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
RFCOMM: Disconnect (DISC) (0x43)
Address: 0x03 cr 1 dlci 0x00
Control: 0x53 poll/final 1
Length: 0
FCS: 0xfd
< ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062
Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
RFCOMM: Unnumbered Ack (UA) (0x63)
Address: 0x03 cr 1 dlci 0x00
Control: 0x73 poll/final 1
Length: 0
FCS: 0xd7
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073
L2CAP: Disconnection Request (0x06) ident 17 len 4
Destination CID: 65
Source CID: 65
> HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci1] 10.752391
Num handles: 1
Handle: 43
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #398 [hci1] 10.753394
Num handles: 1
Handle: 43
Count: 1
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #399 [hci1] 10.756499
L2CAP: Disconnection Request (0x06) ident 26 len 4
Destination CID: 65
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #400 [hci1] 10.756548
L2CAP: Disconnection Response (0x07) ident 26 len 4
Destination CID: 65
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #401 [hci1] 10.757459
L2CAP: Connection Request (0x02) ident 18 len 4
PSM: 1 (0x0001)
Source CID: 65
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #402 [hci1] 10.759148
L2CAP: Disconnection Response (0x07) ident 17 len 4
Destination CID: 65
Source CID: 65
= bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447
> HCI Event: Number of Completed Packets (0x13) plen 5 #403 [hci1] 10.759386
Num handles: 1
Handle: 43
Count: 1
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #404 [hci1] 10.760397
L2CAP: Connection Request (0x02) ident 27 len 4
PSM: 3 (0x0003)
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 16 #405 [hci1] 10.760441
L2CAP: Connection Response (0x03) ident 27 len 8
Destination CID: 65
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 43 flags 0x00 dlen 27 #406 [hci1] 10.760449
L2CAP: Configure Request (0x04) ident 19 len 19
Destination CID: 65
Flags: 0x0000
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 1013
Option: Retransmission and Flow Control (0x04) [mandatory]
Mode: Basic (0x00)
TX window size: 0
Max transmit: 0
Retransmission timeout: 0
Monitor timeout: 0
Maximum PDU size: 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci1] 10.761399
Num handles: 1
Handle: 43
Count: 1
> ACL Data RX: Handle 43 flags 0x02 dlen 16 #408 [hci1] 10.762942
L2CAP: Connection Response (0x03) ident 18 len 8
Destination CID: 66
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
*snip*
Similar case after the patch:
*snip*
> ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056
Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
RFCOMM: Disconnect (DISC) (0x43)
Address: 0x03 cr 1 dlci 0x00
Control: 0x53 poll/final 1
Length: 0
FCS: 0xfd
< ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136
Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
RFCOMM: Unnumbered Ack (UA) (0x63)
Address: 0x03 cr 1 dlci 0x00
Control: 0x73 poll/final 1
Length: 0
FCS: 0xd7
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143
L2CAP: Disconnection Request (0x06) ident 11 len 4
Destination CID: 65
Source CID: 65
> HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009
Num handles: 1
Handle: 43
Count: 1
> HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007
Num handles: 1
Handle: 43
Count: 1
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674
L2CAP: Disconnection Request (0x06) ident 17 len 4
Destination CID: 65
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762
L2CAP: Disconnection Response (0x07) ident 17 len 4
Destination CID: 65
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073
L2CAP: Connection Request (0x02) ident 12 len 4
PSM: 1 (0x0001)
Source CID: 65
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371
L2CAP: Disconnection Response (0x07) ident 11 len 4
Destination CID: 65
Source CID: 65
> HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082
Num handles: 1
Handle: 43
Count: 1
> HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040
Num handles: 1
Handle: 43
Count: 1
> ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103
L2CAP: Connection Request (0x02) ident 18 len 4
PSM: 3 (0x0003)
Source CID: 65
< ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186
L2CAP: Connection Response (0x03) ident 18 len 8
Destination CID: 66
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196
L2CAP: Configure Request (0x04) ident 13 len 19
Destination CID: 65
Flags: 0x0000
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 1013
Option: Retransmission and Flow Control (0x04) [mandatory]
Mode: Basic (0x00)
TX window size: 0
Max transmit: 0
Retransmission timeout: 0
Monitor timeout: 0
Maximum PDU size: 0
> ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804
L2CAP: Connection Response (0x03) ident 12 len 8
Destination CID: 66
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
*snip*
Fix is to check that channel is in state BT_DISCONN before deleting the
channel.
This bug was found while fuzzing Bluez's OBEX implementation using
Synopsys Defensics.
Reported-by: Matti Kamunen <matti.kamunen@synopsys.com>
Reported-by: Ari Timonen <ari.timonen@synopsys.com>
Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 5406d7cd46ad..771e3e17bb6a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4394,6 +4394,12 @@ static inline int l2cap_disconnect_rsp(struct l2cap_conn *conn,
l2cap_chan_lock(chan);
+ if (chan->state != BT_DISCONN) {
+ l2cap_chan_unlock(chan);
+ mutex_unlock(&conn->chan_lock);
+ return 0;
+ }
+
l2cap_chan_hold(chan);
l2cap_chan_del(chan, 0);
--
2.20.1
^ permalink raw reply related
* Re: INFO: rcu detected stall in ext4_write_checks
From: Paul E. McKenney @ 2019-07-15 14:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dmitry Vyukov, Theodore Ts'o, syzbot, Andreas Dilger,
David Miller, eladr, Ido Schimmel, Jiri Pirko, John Stultz,
linux-ext4, LKML, netdev, syzkaller-bugs, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20190715134651.GI3419@hirez.programming.kicks-ass.net>
On Mon, Jul 15, 2019 at 03:46:51PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 15, 2019 at 03:33:11PM +0200, Dmitry Vyukov wrote:
> > On Mon, Jul 15, 2019 at 3:29 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Sun, Jul 14, 2019 at 11:49:15AM -0700, Paul E. McKenney wrote:
> > > > On Sun, Jul 14, 2019 at 05:48:00PM +0300, Dmitry Vyukov wrote:
> > > > > But short term I don't see any other solution than stop testing
> > > > > sched_setattr because it does not check arguments enough to prevent
> > > > > system misbehavior. Which is a pity because syzkaller has found some
> > > > > bad misconfigurations that were oversight on checking side.
> > > > > Any other suggestions?
> > > >
> > > > Keep the times down to a few seconds? Of course, that might also
> > > > fail to find interesting bugs.
> > >
> > > Right, if syzcaller can put a limit on the period/deadline parameters
> > > (and make sure to not write "-1" to
> > > /proc/sys/kernel/sched_rt_runtime_us) then per the in-kernel
> > > access-control should not allow these things to happen.
> >
> > Since we are racing with emails, could you suggest a 100% safe
> > parameters? Because I only hear people saying "safe", "sane",
> > "well-behaving" :)
> > If we move the check to user-space, it does not mean that we can get
> > away without actually defining what that means.
>
> Right, well, that's part of the problem. I think Paul just did the
> reverse math and figured that 95% of X must not be larger than my
> watchdog timeout and landed on 14 seconds.
I was actually working backwards from thw 21-second RCU CPU stall
timeout, but there are likely many other limits to consider.
> I'm thinking 4 seconds (or rather 4.294967296) would be a very nice
> number.
Works for me! That should give the various RCU kthreads ample
opportunities to execute within the RCU CPU stall timeout.
The rcuo callback-offload kthreads will need special handling, but if
someone has 100 CPUs wildly generating callbacks and allocates but one
CPU to invoke them, there is not much either the RCU or the scheduler
can do to make that work. ;-)
Thanx, Paul
> > Now thinking of this, if we come up with some simple criteria, could
> > we have something like a sysctl that would allow only really "safe"
> > parameters?
>
> I suppose we could do that, something like:
> sysctl_deadline_period_{min,max}. I'll have to dig back a bit on where
> we last talked about that and what the problems where.
>
> For one, setting the min is a lot harder, but I suppose we can start at
> TICK_NSEC or something.
^ permalink raw reply
* [PATCH AUTOSEL 5.2 232/249] net: hns3: enable broadcast promisc mode when initializing VF
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jian Shen, Peng Li, Huazhong Tan, David S . Miller, Sasha Levin,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Jian Shen <shenjian15@huawei.com>
[ Upstream commit 2d5066fc175ea77a733d84df9ef414b34f311641 ]
For revision 0x20, the broadcast promisc is enabled by firmware,
it's unnecessary to enable it when initializing VF.
For revision 0x21, it's necessary to enable broadcast promisc mode
when initializing or re-initializing VF, otherwise, it will be
unable to send and receive promisc packets.
Fixes: f01f5559cac8 ("net: hns3: don't allow vf to enable promisc mode")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 5d53467ee2d2..3b02745605d4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2512,6 +2512,12 @@ static int hclgevf_reset_hdev(struct hclgevf_dev *hdev)
return ret;
}
+ if (pdev->revision >= 0x21) {
+ ret = hclgevf_set_promisc_mode(hdev, true);
+ if (ret)
+ return ret;
+ }
+
dev_info(&hdev->pdev->dev, "Reset done\n");
return 0;
@@ -2591,9 +2597,11 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
* firmware makes sure broadcast packets can be accepted.
* For revision 0x21, default to enable broadcast promisc mode.
*/
- ret = hclgevf_set_promisc_mode(hdev, true);
- if (ret)
- goto err_config;
+ if (pdev->revision >= 0x21) {
+ ret = hclgevf_set_promisc_mode(hdev, true);
+ if (ret)
+ goto err_config;
+ }
/* Initialize RSS for this VF */
ret = hclgevf_rss_init_hw(hdev);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 226/249] selftests: bpf: fix inlines in test_lwt_seg6local
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jiri Benc, Yonghong Song, Daniel Borkmann, Sasha Levin,
linux-kselftest, netdev, bpf, clang-built-linux
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Jiri Benc <jbenc@redhat.com>
[ Upstream commit 11aca65ec4db09527d3e9b6b41a0615b7da4386b ]
Selftests are reporting this failure in test_lwt_seg6local.sh:
+ ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.o sec encap_srh dev veth2
Error fetching program/map!
Failed to parse eBPF program: Operation not permitted
The problem is __attribute__((always_inline)) alone is not enough to prevent
clang from inserting those functions in .text. In that case, .text is not
marked as relocateable.
See the output of objdump -h test_lwt_seg6local.o:
Idx Name Size VMA LMA File off Algn
0 .text 00003530 0000000000000000 0000000000000000 00000040 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
This causes the iproute bpf loader to fail in bpf_fetch_prog_sec:
bpf_has_call_data returns true but bpf_fetch_prog_relo fails as there's no
relocateable .text section in the file.
To fix this, convert to 'static __always_inline'.
v2: Use 'static __always_inline' instead of 'static inline
__attribute__((always_inline))'
Fixes: c99a84eac026 ("selftests/bpf: test for seg6local End.BPF action")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../testing/selftests/bpf/progs/test_lwt_seg6local.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
index 0575751bc1bc..e2f6ed0a583d 100644
--- a/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
+++ b/tools/testing/selftests/bpf/progs/test_lwt_seg6local.c
@@ -61,7 +61,7 @@ struct sr6_tlv_t {
unsigned char value[0];
} BPF_PACKET_HEADER;
-__attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
+static __always_inline struct ip6_srh_t *get_srh(struct __sk_buff *skb)
{
void *cursor, *data_end;
struct ip6_srh_t *srh;
@@ -95,7 +95,7 @@ __attribute__((always_inline)) struct ip6_srh_t *get_srh(struct __sk_buff *skb)
return srh;
}
-__attribute__((always_inline))
+static __always_inline
int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
uint32_t old_pad, uint32_t pad_off)
{
@@ -125,7 +125,7 @@ int update_tlv_pad(struct __sk_buff *skb, uint32_t new_pad,
return 0;
}
-__attribute__((always_inline))
+static __always_inline
int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
uint32_t *tlv_off, uint32_t *pad_size,
uint32_t *pad_off)
@@ -184,7 +184,7 @@ int is_valid_tlv_boundary(struct __sk_buff *skb, struct ip6_srh_t *srh,
return 0;
}
-__attribute__((always_inline))
+static __always_inline
int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
struct sr6_tlv_t *itlv, uint8_t tlv_size)
{
@@ -228,7 +228,7 @@ int add_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh, uint32_t tlv_off,
return update_tlv_pad(skb, new_pad, pad_size, pad_off);
}
-__attribute__((always_inline))
+static __always_inline
int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
uint32_t tlv_off)
{
@@ -266,7 +266,7 @@ int delete_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh,
return update_tlv_pad(skb, new_pad, pad_size, pad_off);
}
-__attribute__((always_inline))
+static __always_inline
int has_egr_tlv(struct __sk_buff *skb, struct ip6_srh_t *srh)
{
int tlv_offset = sizeof(struct ip6_t) + sizeof(struct ip6_srh_t) +
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 231/249] tools: bpftool: Fix json dump crash on powerpc
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jiri Olsa, Michael Petlan, Jiri Olsa, Quentin Monnet,
Jakub Kicinski, Daniel Borkmann, Sasha Levin, netdev, bpf
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Jiri Olsa <jolsa@redhat.com>
[ Upstream commit aa52bcbe0e72fac36b1862db08b9c09c4caefae3 ]
Michael reported crash with by bpf program in json mode on powerpc:
# bpftool prog -p dump jited id 14
[{
"name": "0xd00000000a9aa760",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
Segmentation fault (core dumped)
The code is assuming char pointers in format, which is not always
true at least for powerpc. Fixing this by dumping the whole string
into buffer based on its format.
Please note that libopcodes code does not check return values from
fprintf callback, but as per Jakub suggestion returning -1 on allocation
failure so we do the best effort to propagate the error.
Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/bpf/bpftool/jit_disasm.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
index 3ef3093560ba..bfed711258ce 100644
--- a/tools/bpf/bpftool/jit_disasm.c
+++ b/tools/bpf/bpftool/jit_disasm.c
@@ -11,6 +11,8 @@
* Licensed under the GNU General Public License, version 2.0 (GPLv2)
*/
+#define _GNU_SOURCE
+#include <stdio.h>
#include <stdarg.h>
#include <stdint.h>
#include <stdio.h>
@@ -44,11 +46,13 @@ static int fprintf_json(void *out, const char *fmt, ...)
char *s;
va_start(ap, fmt);
+ if (vasprintf(&s, fmt, ap) < 0)
+ return -1;
+ va_end(ap);
+
if (!oper_count) {
int i;
- s = va_arg(ap, char *);
-
/* Strip trailing spaces */
i = strlen(s) - 1;
while (s[i] == ' ')
@@ -61,11 +65,10 @@ static int fprintf_json(void *out, const char *fmt, ...)
} else if (!strcmp(fmt, ",")) {
/* Skip */
} else {
- s = va_arg(ap, char *);
jsonw_string(json_wtr, s);
oper_count++;
}
- va_end(ap);
+ free(s);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 227/249] bonding: validate ip header before check IPPROTO_IGMP
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Cong Wang, syzbot+e5be16aa39ad6e755391, Jay Vosburgh,
Veaceslav Falico, Andy Gospodarek, David S . Miller, Sasha Levin,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Cong Wang <xiyou.wangcong@gmail.com>
[ Upstream commit 9d1bc24b52fb8c5d859f9a47084bf1179470e04c ]
bond_xmit_roundrobin() checks for IGMP packets but it parses
the IP header even before checking skb->protocol.
We should validate the IP header with pskb_may_pull() before
using iph->protocol.
Reported-and-tested-by: syzbot+e5be16aa39ad6e755391@syzkaller.appspotmail.com
Fixes: a2fd940f4cff ("bonding: fix broken multicast with round-robin mode")
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/bonding/bond_main.c | 37 ++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 799fc38c5c34..b0aab3a0a1bf 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3866,8 +3866,8 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff *skb,
struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
- struct iphdr *iph = ip_hdr(skb);
struct slave *slave;
+ int slave_cnt;
u32 slave_id;
/* Start with the curr_active_slave that joined the bond as the
@@ -3876,23 +3876,32 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff *skb,
* send the join/membership reports. The curr_active_slave found
* will send all of this type of traffic.
*/
- if (iph->protocol == IPPROTO_IGMP && skb->protocol == htons(ETH_P_IP)) {
- slave = rcu_dereference(bond->curr_active_slave);
- if (slave)
- bond_dev_queue_xmit(bond, skb, slave->dev);
- else
- bond_xmit_slave_id(bond, skb, 0);
- } else {
- int slave_cnt = READ_ONCE(bond->slave_cnt);
+ if (skb->protocol == htons(ETH_P_IP)) {
+ int noff = skb_network_offset(skb);
+ struct iphdr *iph;
- if (likely(slave_cnt)) {
- slave_id = bond_rr_gen_slave_id(bond);
- bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
- } else {
- bond_tx_drop(bond_dev, skb);
+ if (unlikely(!pskb_may_pull(skb, noff + sizeof(*iph))))
+ goto non_igmp;
+
+ iph = ip_hdr(skb);
+ if (iph->protocol == IPPROTO_IGMP) {
+ slave = rcu_dereference(bond->curr_active_slave);
+ if (slave)
+ bond_dev_queue_xmit(bond, skb, slave->dev);
+ else
+ bond_xmit_slave_id(bond, skb, 0);
+ return NETDEV_TX_OK;
}
}
+non_igmp:
+ slave_cnt = READ_ONCE(bond->slave_cnt);
+ if (likely(slave_cnt)) {
+ slave_id = bond_rr_gen_slave_id(bond);
+ bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
+ } else {
+ bond_tx_drop(bond_dev, skb);
+ }
return NETDEV_TX_OK;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 225/249] bpf, libbpf, smatch: Fix potential NULL pointer dereference
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leo Yan, Yonghong Song, Daniel Borkmann, Sasha Levin, netdev, bpf
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Leo Yan <leo.yan@linaro.org>
[ Upstream commit 33bae185f74d49a0d7b1bfaafb8e959efce0f243 ]
Based on the following report from Smatch, fix the potential NULL
pointer dereference check:
tools/lib/bpf/libbpf.c:3493
bpf_prog_load_xattr() warn: variable dereferenced before check 'attr'
(see line 3483)
3479 int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
3480 struct bpf_object **pobj, int *prog_fd)
3481 {
3482 struct bpf_object_open_attr open_attr = {
3483 .file = attr->file,
3484 .prog_type = attr->prog_type,
^^^^^^
3485 };
At the head of function, it directly access 'attr' without checking
if it's NULL pointer. This patch moves the values assignment after
validating 'attr' and 'attr->file'.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/libbpf.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 151f7ac1882e..3865a5d27251 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -3487,10 +3487,7 @@ int bpf_prog_load(const char *file, enum bpf_prog_type type,
int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
struct bpf_object **pobj, int *prog_fd)
{
- struct bpf_object_open_attr open_attr = {
- .file = attr->file,
- .prog_type = attr->prog_type,
- };
+ struct bpf_object_open_attr open_attr = {};
struct bpf_program *prog, *first_prog = NULL;
enum bpf_attach_type expected_attach_type;
enum bpf_prog_type prog_type;
@@ -3503,6 +3500,9 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
if (!attr->file)
return -EINVAL;
+ open_attr.file = attr->file;
+ open_attr.prog_type = attr->prog_type;
+
obj = bpf_object__open_xattr(&open_attr);
if (IS_ERR_OR_NULL(obj))
return -ENOENT;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 221/249] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Guilherme G. Piccoli, Przemyslaw Hausman, Sudarsana Reddy Kalluru,
David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
[ Upstream commit 3c91f25c2f72ba6001775a5932857c1d2131c531 ]
Currently bnx2x ptp worker tries to read a register with timestamp
information in case of TX packet timestamping and in case it fails,
the routine reschedules itself indefinitely. This was reported as a
kworker always at 100% of CPU usage, which was narrowed down to be
bnx2x ptp_task.
By following the ioctl handler, we could narrow down the problem to
an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
RX filter zeroed; this isn't reproducible for example with ptp4l
(from linuxptp) since this tool requests a supported RX filter.
It seems NIC FW timestamp mechanism cannot work well with
RX_FILTER_NONE - driver's PTP filter init routine skips a register
write to the adapter if there's not a supported filter request.
This patch addresses the problem of bnx2x ptp thread's everlasting
reschedule by retrying the register read 10 times; between the read
attempts the thread sleeps for an increasing amount of time starting
in 1ms to give FW some time to perform the timestamping. If it still
fails after all retries, we bail out in order to prevent an unbound
resource consumption from bnx2x.
The patch also adds an ethtool statistic for accounting the skipped
TX timestamp packets and it reduces the priority of timestamping
error messages to prevent log flooding. The code was tested using
both linuxptp and chrony.
Reported-and-tested-by: Przemyslaw Hausman <przemyslaw.hausman@canonical.com>
Suggested-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 ++-
.../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 4 ++-
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 33 ++++++++++++++-----
.../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++
4 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 008ad0ca89ba..c12c1bab0fe4 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3857,9 +3857,12 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
if (!(bp->flags & TX_TIMESTAMPING_EN)) {
+ bp->eth_stats.ptp_skip_tx_ts++;
BNX2X_ERR("Tx timestamping was not enabled, this packet will not be timestamped\n");
} else if (bp->ptp_tx_skb) {
- BNX2X_ERR("The device supports only a single outstanding packet to timestamp, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Device supports only a single outstanding packet to timestamp, this packet won't be timestamped\n");
} else {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
/* schedule check for Tx timestamp */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 51fc845de31a..4a0ba6801c9e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -182,7 +182,9 @@ static const struct {
{ STATS_OFFSET32(driver_filtered_tx_pkt),
4, false, "driver_filtered_tx_pkt" },
{ STATS_OFFSET32(eee_tx_lpi),
- 4, true, "Tx LPI entry count"}
+ 4, true, "Tx LPI entry count"},
+ { STATS_OFFSET32(ptp_skip_tx_ts),
+ 4, false, "ptp_skipped_tx_tstamp" },
};
#define BNX2X_NUM_STATS ARRAY_SIZE(bnx2x_stats_arr)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 03ac10b1cd1e..2cc14db8f0ec 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -15214,11 +15214,24 @@ static void bnx2x_ptp_task(struct work_struct *work)
u32 val_seq;
u64 timestamp, ns;
struct skb_shared_hwtstamps shhwtstamps;
+ bool bail = true;
+ int i;
+
+ /* FW may take a while to complete timestamping; try a bit and if it's
+ * still not complete, may indicate an error state - bail out then.
+ */
+ for (i = 0; i < 10; i++) {
+ /* Read Tx timestamp registers */
+ val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
+ NIG_REG_P0_TLLH_PTP_BUF_SEQID);
+ if (val_seq & 0x10000) {
+ bail = false;
+ break;
+ }
+ msleep(1 << i);
+ }
- /* Read Tx timestamp registers */
- val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
- NIG_REG_P0_TLLH_PTP_BUF_SEQID);
- if (val_seq & 0x10000) {
+ if (!bail) {
/* There is a valid timestamp value */
timestamp = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_TS_MSB :
NIG_REG_P0_TLLH_PTP_BUF_TS_MSB);
@@ -15233,16 +15246,18 @@ static void bnx2x_ptp_task(struct work_struct *work)
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
shhwtstamps.hwtstamp = ns_to_ktime(ns);
skb_tstamp_tx(bp->ptp_tx_skb, &shhwtstamps);
- dev_kfree_skb_any(bp->ptp_tx_skb);
- bp->ptp_tx_skb = NULL;
DP(BNX2X_MSG_PTP, "Tx timestamp, timestamp cycles = %llu, ns = %llu\n",
timestamp, ns);
} else {
- DP(BNX2X_MSG_PTP, "There is no valid Tx timestamp yet\n");
- /* Reschedule to keep checking for a valid timestamp value */
- schedule_work(&bp->ptp_task);
+ DP(BNX2X_MSG_PTP,
+ "Tx timestamp is not recorded (register read=%u)\n",
+ val_seq);
+ bp->eth_stats.ptp_skip_tx_ts++;
}
+
+ dev_kfree_skb_any(bp->ptp_tx_skb);
+ bp->ptp_tx_skb = NULL;
}
void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
index b2644ed13d06..d55e63692cf3 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
@@ -207,6 +207,9 @@ struct bnx2x_eth_stats {
u32 driver_filtered_tx_pkt;
/* src: Clear-on-Read register; Will not survive PMF Migration */
u32 eee_tx_lpi;
+
+ /* PTP */
+ u32 ptp_skip_tx_ts;
};
struct bnx2x_eth_q_stats {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 224/249] libbpf: fix GCC8 warning for strncpy
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Magnus Karlsson, Yonghong Song, Daniel Borkmann,
Sasha Levin, netdev, bpf
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit cdfc7f888c2a355b01308e97c6df108f1c2b64e8 ]
GCC8 started emitting warning about using strncpy with number of bytes
exactly equal destination size, which is generally unsafe, as can lead
to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
of bytes to ensure name is always zero-terminated.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Cc: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Yonghong Song <yhs@fb.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/xsk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 38667b62f1fe..8a7a05bc657d 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -337,7 +337,8 @@ static int xsk_get_max_queues(struct xsk_socket *xsk)
channels.cmd = ETHTOOL_GCHANNELS;
ifr.ifr_data = (void *)&channels;
- strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ);
+ strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1);
+ ifr.ifr_name[IFNAMSIZ - 1] = '\0';
err = ioctl(fd, SIOCETHTOOL, &ifr);
if (err && errno != EOPNOTSUPP) {
ret = -errno;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 213/249] bnxt_en: Fix statistics context reservation logic for RDMA driver.
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Michael Chan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Michael Chan <michael.chan@broadcom.com>
[ Upstream commit d77b1ad8e87dc5a6cd0d9158b097a4817946ca3b ]
The current logic assumes that the RDMA driver uses one statistics
context adjacent to the ones used by the network driver. This
assumption is not true and the statistics context used by the
RDMA driver is tied to its MSIX base vector. This wrong assumption
can cause RDMA driver failure after changing ethtool rings on the
network side. Fix the statistics reservation logic accordingly.
Fixes: 780baad44f0f ("bnxt_en: Reserve 1 stat_ctx for RDMA driver.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index b9bc829aa9da..9090c79387c1 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5508,7 +5508,16 @@ static int bnxt_cp_rings_in_use(struct bnxt *bp)
static int bnxt_get_func_stat_ctxs(struct bnxt *bp)
{
- return bp->cp_nr_rings + bnxt_get_ulp_stat_ctxs(bp);
+ int ulp_stat = bnxt_get_ulp_stat_ctxs(bp);
+ int cp = bp->cp_nr_rings;
+
+ if (!ulp_stat)
+ return cp;
+
+ if (bnxt_nq_rings_in_use(bp) > cp + bnxt_get_ulp_msix_num(bp))
+ return bnxt_get_ulp_msix_base(bp) + ulp_stat;
+
+ return cp + ulp_stat;
}
static bool bnxt_need_reserve_rings(struct bnxt *bp)
@@ -7477,11 +7486,7 @@ unsigned int bnxt_get_avail_cp_rings_for_en(struct bnxt *bp)
unsigned int bnxt_get_avail_stat_ctxs_for_en(struct bnxt *bp)
{
- unsigned int stat;
-
- stat = bnxt_get_max_func_stat_ctxs(bp) - bnxt_get_ulp_stat_ctxs(bp);
- stat -= bp->cp_nr_rings;
- return stat;
+ return bnxt_get_max_func_stat_ctxs(bp) - bnxt_get_func_stat_ctxs(bp);
}
int bnxt_get_avail_msix(struct bnxt *bp, int num)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 222/249] net: usb: asix: init MAC address buffers
From: Sasha Levin @ 2019-07-15 13:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8a3fc6674bbc3978ed4e, David S . Miller,
Sasha Levin, linux-usb, netdev, clang-built-linux
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit 78226f6eaac80bf30256a33a4926c194ceefdf36 ]
This is for fixing bug KMSAN: uninit-value in ax88772_bind
Tested by
https://groups.google.com/d/msg/syzkaller-bugs/aFQurGotng4/eB_HlNhhCwAJ
Reported-by: syzbot+8a3fc6674bbc3978ed4e@syzkaller.appspotmail.com
syzbot found the following crash on:
HEAD commit: f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=136d720ea00000
kernel config:
https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a
dashboard link:
https://syzkaller.appspot.com/bug?extid=8a3fc6674bbc3978ed4e
compiler: clang version 9.0.0 (/home/glider/llvm/clang
06d00afa61eef8f7f501ebdb4e8612ea43ec2d78)
syz repro:
https://syzkaller.appspot.com/x/repro.syz?x=12788316a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120359aaa00000
==================================================================
BUG: KMSAN: uninit-value in is_valid_ether_addr
include/linux/etherdevice.h:200 [inline]
BUG: KMSAN: uninit-value in asix_set_netdev_dev_addr
drivers/net/usb/asix_devices.c:73 [inline]
BUG: KMSAN: uninit-value in ax88772_bind+0x93d/0x11e0
drivers/net/usb/asix_devices.c:724
CPU: 0 PID: 3348 Comm: kworker/0:2 Not tainted 5.1.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
__msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
is_valid_ether_addr include/linux/etherdevice.h:200 [inline]
asix_set_netdev_dev_addr drivers/net/usb/asix_devices.c:73 [inline]
ax88772_bind+0x93d/0x11e0 drivers/net/usb/asix_devices.c:724
usbnet_probe+0x10f5/0x3940 drivers/net/usb/usbnet.c:1728
usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361
really_probe+0xdae/0x1d80 drivers/base/dd.c:513
driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
__device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
__device_attach+0x454/0x730 drivers/base/dd.c:844
device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
bus_probe_device+0x137/0x390 drivers/base/bus.c:514
device_add+0x288d/0x30e0 drivers/base/core.c:2106
usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027
generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210
usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266
really_probe+0xdae/0x1d80 drivers/base/dd.c:513
driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
__device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
__device_attach+0x454/0x730 drivers/base/dd.c:844
device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
bus_probe_device+0x137/0x390 drivers/base/bus.c:514
device_add+0x288d/0x30e0 drivers/base/core.c:2106
usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432
process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269
process_scheduled_works kernel/workqueue.c:2331 [inline]
worker_thread+0x189c/0x2460 kernel/workqueue.c:2417
kthread+0x4b5/0x4f0 kernel/kthread.c:254
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/asix_devices.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index c9bc96310ed4..ef548beba684 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -226,7 +226,7 @@ static void asix_phy_reset(struct usbnet *dev, unsigned int reset_bits)
static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret = 0;
- u8 buf[ETH_ALEN];
+ u8 buf[ETH_ALEN] = {0};
int i;
unsigned long gpio_bits = dev->driver_info->data;
@@ -677,7 +677,7 @@ static int asix_resume(struct usb_interface *intf)
static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret, i;
- u8 buf[ETH_ALEN], chipcode = 0;
+ u8 buf[ETH_ALEN] = {0}, chipcode = 0;
u32 phyid;
struct asix_common_private *priv;
@@ -1061,7 +1061,7 @@ static const struct net_device_ops ax88178_netdev_ops = {
static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret;
- u8 buf[ETH_ALEN];
+ u8 buf[ETH_ALEN] = {0};
usbnet_get_endpoints(dev,intf);
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox