linux-toradex.git/drivers/net, branch v4.9.131

e1000: ensure to free old tx/rx rings in set_ringparam()

2018-10-04T00:01:52+00:00

[ Upstream commit ee400a3f1bfe7004a3e14b81c38ccc5583c26295 ]

In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value
and the old tx/rx rings are freed only when the device is up. There are resource
leaks on old tx/rx rings when the device is not up. This bug is reported by COD,
a tool for testing kernel module binaries I am building.

This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in
'e1000_set_ringparam()'.

Signed-off-by: Bo Chen 
Reviewed-by: Alexander Duyck 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

e1000: check on netif_running() before calling e1000_up()

2018-10-04T00:01:51+00:00

[ Upstream commit cf1acec008f8d7761aa3fd7c4bca7e17b2d2512d ]

When the device is not up, the call to 'e1000_up()' from the error handling path
of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer
dereference. The null-pointer dereference is triggered in function
'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'.

This bug was reported by COD, a tool for testing kernel module binaries I am
building. This bug was also detected by KFI from Dr. Kai Cong.

This patch fixes the bug by checking on 'netif_running()' before calling
'e1000_up()' in 'e1000_set_ringparam()'.

Signed-off-by: Bo Chen 
Acked-by: Alexander Duyck 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: hns: fix skb->truesize underestimation

2018-10-04T00:01:51+00:00

[ Upstream commit b1ccd4c0ab6ef499f47dd84ed4920502a7147bba ]

skb->truesize is not meant to be tracking amount of used bytes in a skb,
but amount of reserved/consumed bytes in memory.

For instance, if we use a single byte in last page fragment, we have to
account the full size of the fragment.

So skb_add_rx_frag needs to calculate the length of the entire buffer into
turesize.

Fixes: 9cbe9fd5214e ("net: hns: optimize XGE capability by reducing cpu usage")
Signed-off-by: Huazhong tan 
Signed-off-by: Salil Mehta 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: hns: fix length and page_offset overflow when CONFIG_ARM64_64K_PAGES

2018-10-04T00:01:51+00:00

[ Upstream commit 3ed614dce3ca9912d22be215ff0f11104b69fe62 ]

When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
is 65536(64K). But the  type of length and page_offset are u16, they will
overflow. So change them to u32.

Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support")
Signed-off-by: Huazhong Tan 
Signed-off-by: Salil Mehta 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

qed: Wait for MCP halt and resume commands to take place

2018-10-04T00:01:51+00:00

[ Upstream commit 76271809f49056f079e202bf6513d17b0d6dd34d ]

Successive iterations of halting and resuming the management chip (MCP)
might fail, since currently the driver doesn't wait for these operations to
actually take place.
This patch prevents the driver from moving forward before the operations
are reflected in the state register.

Signed-off-by: Tomer Tayar 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

qed: Wait for ready indication before rereading the shmem

2018-10-04T00:01:51+00:00

[ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ]

The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.

Signed-off-by: Tomer Tayar 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

2018-10-04T00:01:47+00:00

[ Upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1 ]

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this separately though in case others are hitting this issue.

Signed-off-by: Tony Lindgren 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()

2018-10-04T00:01:46+00:00

[ Upstream commit ae636fb1554833ee5133ca47bf4b2791b6739c52 ]

This is a static checker fix, not something I have tested.  The issue
is that on the second iteration through the loop, we jump forward by
le32_to_cpu(auth_req->length) bytes.  The problem is that if the length
is more than "buflen" then we end up with a negative "buflen".  A
negative buflen is type promoted to a high positive value and the loop
continues but it's accessing beyond the end of the buffer.

I believe the "auth_req->length" comes from the firmware and if the
firmware is malicious or buggy, you're already toasted so the impact of
this bug is probably not very severe.

Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: phy: xgmiitorgmii: Check phy_driver ready before accessing

2018-10-04T00:01:46+00:00

[ Upstream commit ab4e6ee578e88a659938db8fbf33720bc048d29c ]

Since a phy_device is added to the global mdio_bus list during
phy_device_register(), but a phy_device's phy_driver doesn't get
attached until phy_probe(). It's possible of_phy_find_device() in
xgmiitorgmii will return a valid phy with a NULL phy_driver. Leading to
a NULL pointer access during the memcpy().

Fixes this Oops:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.40 #1
Hardware name: Xilinx Zynq Platform
task: ce4c8d00 task.stack: ce4ca000
PC is at memcpy+0x48/0x330
LR is at xgmiitorgmii_probe+0x90/0xe8
pc : []    lr : []    psr: 20000013
sp : ce4cbb54  ip : 00000000  fp : ce4cbb8c
r10: 00000000  r9 : 00000000  r8 : c0c49178
r7 : 00000000  r6 : cdc14718  r5 : ce762800  r4 : cdc14710
r3 : 00000000  r2 : 00000054  r1 : 00000000  r0 : cdc14718
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 18c5387d  Table: 0000404a  DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xce4ca210)
...
[] (memcpy) from [] (xgmiitorgmii_probe+0x90/0xe8)
[] (xgmiitorgmii_probe) from [] (mdio_probe+0x28/0x34)
[] (mdio_probe) from [] (driver_probe_device+0x254/0x414)
[] (driver_probe_device) from [] (__device_attach_driver+0xac/0x10c)
[] (__device_attach_driver) from [] (bus_for_each_drv+0x84/0xc8)
[] (bus_for_each_drv) from [] (__device_attach+0xd0/0x134)
[] (__device_attach) from [] (device_initial_probe+0x1c/0x20)
[] (device_initial_probe) from [] (bus_probe_device+0x98/0xa0)
[] (bus_probe_device) from [] (device_add+0x43c/0x5d0)
[] (device_add) from [] (mdio_device_register+0x34/0x80)
[] (mdio_device_register) from [] (of_mdiobus_register+0x170/0x30c)
[] (of_mdiobus_register) from [] (macb_probe+0x710/0xc00)
[] (macb_probe) from [] (platform_drv_probe+0x44/0x80)
[] (platform_drv_probe) from [] (driver_probe_device+0x254/0x414)
[] (driver_probe_device) from [] (__driver_attach+0x10c/0x118)
[] (__driver_attach) from [] (bus_for_each_dev+0x8c/0xd0)
[] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30)
[] (driver_attach) from [] (bus_add_driver+0x50/0x260)
[] (bus_add_driver) from [] (driver_register+0x88/0x108)
[] (driver_register) from [] (__platform_driver_register+0x50/0x58)
[] (__platform_driver_register) from [] (macb_driver_init+0x24/0x28)
[] (macb_driver_init) from [] (do_one_initcall+0x60/0x1a4)
[] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1f8)
[] (kernel_init_freeable) from [] (kernel_init+0x18/0x124)
[] (kernel_init) from [] (ret_from_fork+0x14/0x20)
Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8)
---[ end trace 3e4ec21905820a1f ]---

Signed-off-by: Brandon Maier 
Reviewed-by: Andrew Lunn 
Reviewed-by: Florian Fainelli 

Signed-off-by: David S. Miller 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ath10k: protect ath10k_htt_rx_ring_free with rx_ring.lock

2018-10-04T00:01:46+00:00

[ Upstream commit 168f75f11fe68455e0d058a818ebccfc329d8685 ]

While debugging driver crashes related to a buggy firmware
crashing under load, I noticed that ath10k_htt_rx_ring_free
could be called without being under lock.  I'm not sure if this
is the root cause of the crash or not, but it seems prudent to
protect it.

Originally tested on 4.16+ kernel with ath10k-ct 10.4 firmware
running on 9984 NIC.

Signed-off-by: Ben Greear 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman