Andreas Kemnade [Fri, 13 Dec 2019 21:48:02 +0000 (22:48 +0100)]
watchdog: rn5t618_wdt: fix module aliases
[ Upstream commit
a76dfb859cd42df6e3d1910659128ffcd2fb6ba2 ]
Platform device aliases were missing so module autoloading
did not work.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20191213214802.22268-1-andreas@kemnade.info
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Engraf [Wed, 27 Nov 2019 08:46:17 +0000 (09:46 +0100)]
watchdog: max77620_wdt: fix potential build errors
[ Upstream commit
da9e3f4e30a53cd420cf1e6961c3b4110f0f21f0 ]
max77620_wdt uses watchdog core functions. Enable CONFIG_WATCHDOG_CORE
to fix potential build errors.
Signed-off-by: David Engraf <david.engraf@sysgo.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20191127084617.16937-1-david.engraf@sysgo.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Sun, 22 Dec 2019 18:17:02 +0000 (10:17 -0800)]
phy: cpcap-usb: Prevent USB line glitches from waking up modem
[ Upstream commit
63078b6ba09e842f09df052c5728857389fddcd2 ]
The micro-USB connector on Motorola Mapphone devices can be muxed between
the SoC and the mdm6600 modem. But even when used for the SoC, configuring
the PHY with ID pin grounded will wake up the modem from idle state. Looks
like the issue is probably caused by line glitches.
We can prevent the glitches by using a previously unknown mode of the
GPIO mux to prevent the USB lines from being connected to the moden while
configuring the USB PHY, and enable the USB lines after configuring the
PHY.
Note that this only prevents waking up mdm6600 as regular USB A-host mode,
and does not help when connected to a lapdock. The lapdock specific issue
still needs to be debugged separately.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Tue, 19 Nov 2019 14:57:11 +0000 (15:57 +0100)]
HID: ite: Add USB id match for Acer SW5-012 keyboard dock
[ Upstream commit
8f18eca9ebc57d6b150237033f6439242907e0ba ]
The Acer SW5-012 2-in-1 keyboard dock uses a Synaptics S91028 touchpad
which is connected to an ITE 8595 USB keyboard controller chip.
This keyboard has the same quirk for its rfkill / airplane mode hotkey as
other keyboards with the ITE 8595 chip, it only sends a single release
event when pressed and released, it never sends a press event.
This commit adds this keyboards USB id to the hid-ite id-table, fixing
the rfkill key not working on this keyboard.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Wed, 27 Nov 2019 01:54:09 +0000 (17:54 -0800)]
arc: eznps: fix allmodconfig kconfig warning
[ Upstream commit
1928b36cfa4df1aeedf5f2644d0c33f3a1fcfd7b ]
Fix kconfig warning for arch/arc/plat-eznps/Kconfig allmodconfig:
WARNING: unmet direct dependencies detected for CLKSRC_NPS
Depends on [n]: GENERIC_CLOCKEVENTS [=y] && !PHYS_ADDR_T_64BIT [=y]
Selected by [y]:
- ARC_PLAT_EZNPS [=y]
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Ofer Levi <oferle@mellanox.com>
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:26 +0000 (12:44 +0100)]
zd1211rw: fix storage endpoint lookup
commit
2d68bb2687abb747558b933e80845ff31570a49c upstream.
Make sure to use the current alternate setting when verifying the
storage interface descriptors to avoid submitting an URB to an invalid
endpoint.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device")
Cc: stable <stable@vger.kernel.org> # 2.6.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:24 +0000 (12:44 +0100)]
rtl8xxxu: fix interface sanity check
commit
39a4281c312f2d226c710bc656ce380c621a2b16 upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
Cc: stable <stable@vger.kernel.org> # 4.4
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:22 +0000 (12:44 +0100)]
brcmfmac: fix interface sanity check
commit
3428fbcd6e6c0850b1a8b2a12082b7b2aabb3da3 upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
71bb244ba2fd ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets")
Cc: stable <stable@vger.kernel.org> # 3.4
Cc: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:20 +0000 (12:44 +0100)]
ath9k: fix storage endpoint lookup
commit
0ef332951e856efa89507cdd13ba8f4fb8d4db12 upstream.
Make sure to use the current alternate setting when verifying the
storage interface descriptors to avoid submitting an URB to an invalid
endpoint.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
36bcce430657 ("ath9k_htc: Handle storage devices")
Cc: stable <stable@vger.kernel.org> # 2.6.39
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Tue, 31 Dec 2019 03:19:31 +0000 (21:19 -0600)]
crypto: chelsio - fix writing tfm flags to wrong place
commit
bd56cea012fc2d6381e8cd3209510ce09f9de8c9 upstream.
The chelsio crypto driver is casting 'struct crypto_aead' directly to
'struct crypto_tfm', which is incorrect because the crypto_tfm isn't the
first field of 'struct crypto_aead'. Consequently, the calls to
crypto_tfm_set_flags() are modifying some other field in the struct.
Also, the driver is setting CRYPTO_TFM_RES_BAD_KEY_LEN in
->setauthsize(), not just in ->setkey(). This is incorrect since this
flag is for bad key lengths, not for bad authentication tag lengths.
Fix these bugs by removing the broken crypto_tfm_set_flags() calls from
->setauthsize() and by fixing them in ->setkey().
Fixes:
324429d74127 ("chcr: Support for Chelsio's Crypto Hardware")
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Atul Gupta <atul.gupta@chelsio.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Wunner [Thu, 16 Jan 2020 12:14:01 +0000 (13:14 +0100)]
serial: 8250_bcm2835aux: Fix line mismatch on driver unbind
commit
dc76697d7e933d5e299116f219c890568785ea15 upstream.
Unbinding the bcm2835aux UART driver raises the following error if the
maximum number of 8250 UARTs is set to 1 (via the 8250.nr_uarts module
parameter or CONFIG_SERIAL_8250_RUNTIME_UARTS):
(NULL device *): Removing wrong port:
a6f80333 !=
fa20408b
That's because bcm2835aux_serial_probe() retrieves UART line number 1
from the devicetree and stores it in data->uart.port.line, while
serial8250_register_8250_port() instead uses UART line number 0,
which is stored in data->line.
On driver unbind, bcm2835aux_serial_remove() uses data->uart.port.line,
which contains the wrong number. Fix it.
The issue does not occur if the maximum number of 8250 UARTs is >= 2.
Fixes:
bdc5f3009580 ("serial: bcm2835: add driver for bcm2835-aux-uart")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.6+
Cc: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/912ccf553c5258135c6d7e8f404a101ef320f0f4.1579175223.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Wed, 8 Jan 2020 21:41:36 +0000 (21:41 +0000)]
staging: vt6656: Fix false Tx excessive retries reporting.
commit
9dd631fa99dc0a0dfbd191173bf355ba30ea786a upstream.
The driver reporting IEEE80211_TX_STAT_ACK is not being handled
correctly. The driver should only report on TSR_TMO flag is not
set indicating no transmission errors and when not IEEE80211_TX_CTL_NO_ACK
is being requested.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/340f1f7f-c310-dca5-476f-abc059b9cd97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Wed, 8 Jan 2020 21:41:20 +0000 (21:41 +0000)]
staging: vt6656: use NULLFUCTION stack on mac80211
commit
d579c43c82f093e63639151625b2139166c730fd upstream.
It appears that the drivers does not go into power save correctly the
NULL data packets are not being transmitted because it not enabled
in mac80211.
The driver needs to capture ieee80211_is_nullfunc headers and
copy the duration_id to it's own duration data header.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/610971ae-555b-a6c3-61b3-444a0c1e35b4@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Wed, 8 Jan 2020 21:40:58 +0000 (21:40 +0000)]
staging: vt6656: correct packet types for CTS protect, mode.
commit
d971fdd3412f8342747778fb59b8803720ed82b1 upstream.
It appears that the driver still transmits in CTS protect mode even
though it is not enabled in mac80211.
That is both packet types PK_TYPE_11GA and PK_TYPE_11GB both use CTS protect.
The only difference between them GA does not use B rates.
Find if only B rate in GB or GA in protect mode otherwise transmit packets
as PK_TYPE_11A.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/9c1323ff-dbb3-0eaa-43e1-9453f7390dc0@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Tue, 14 Jan 2020 18:16:04 +0000 (18:16 +0000)]
staging: wlan-ng: ensure error return is actually returned
commit
4cc41cbce536876678b35e03c4a8a7bb72c78fa9 upstream.
Currently when the call to prism2sta_ifst fails a netdev_err error
is reported, error return variable result is set to -1 but the
function always returns 0 for success. Fix this by returning
the error value in variable result rather than 0.
Addresses-Coverity: ("Unused value")
Fixes:
00b3ed168508 ("Staging: add wlan-ng prism2 usb driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200114181604.390235-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Shvetsov [Thu, 16 Jan 2020 17:22:39 +0000 (18:22 +0100)]
staging: most: net: fix buffer overflow
commit
4d1356ac12f4d5180d0df345d85ff0ee42b89c72 upstream.
If the length of the socket buffer is 0xFFFFFFFF (max size for an
unsigned int), then payload_len becomes 0xFFFFFFF1 after subtracting 14
(ETH_HLEN). Then, mdp_len is set to payload_len + 16 (MDP_HDR_LEN)
which overflows and results in a value of 2. These values for
payload_len and mdp_len will pass current buffer size checks.
This patch checks if derived from skb->len sum may overflow.
The check is based on the following idea:
For any `unsigned V1, V2` and derived `unsigned SUM = V1 + V2`,
`V1 + V2` overflows iif `SUM < V1`.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrey Shvetsov <andrey.shvetsov@k2l.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200116172238.6046-1-andrey.shvetsov@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bin Liu [Wed, 11 Dec 2019 16:10:03 +0000 (10:10 -0600)]
usb: dwc3: turn off VBUS when leaving host mode
commit
09ed259fac621634d51cd986aa8d65f035662658 upstream.
VBUS should be turned off when leaving the host mode.
Set GCTL_PRTCAP to device mode in teardown to de-assert DRVVBUS pin to
turn off VBUS power.
Fixes:
5f94adfeed97 ("usb: dwc3: core: refactor mode initialization to its own function")
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 22 Jan 2020 10:15:28 +0000 (11:15 +0100)]
USB: serial: ir-usb: fix IrLAP framing
commit
38c0d5bdf4973f9f5a888166e9d3e9ed0d32057a upstream.
Commit
f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
switched to using the generic write implementation which may combine
multiple write requests into larger transfers. This can break the IrLAP
protocol where end-of-frame is determined using the USB short packet
mechanism, for example, if multiple frames are sent in rapid succession.
Fixes:
f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
Cc: stable <stable@vger.kernel.org> # 2.6.35
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 22 Jan 2020 10:15:27 +0000 (11:15 +0100)]
USB: serial: ir-usb: fix link-speed handling
commit
17a0184ca17e288decdca8b2841531e34d49285f upstream.
Commit
e0d795e4f36c ("usb: irda: cleanup on ir-usb module") added a USB
IrDA header with common defines, but mistakingly switched to using the
class-descriptor baud-rate bitmask values for the outbound header.
This broke link-speed handling for rates above 9600 baud, but a device
would also be able to operate at the default 9600 baud until a
link-speed request was issued (e.g. using the TCGETS ioctl).
Fixes:
e0d795e4f36c ("usb: irda: cleanup on ir-usb module")
Cc: stable <stable@vger.kernel.org> # 2.6.27
Cc: Felipe Balbi <balbi@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 22 Jan 2020 10:15:26 +0000 (11:15 +0100)]
USB: serial: ir-usb: add missing endpoint sanity check
commit
2988a8ae7476fe9535ab620320790d1714bdad1d upstream.
Add missing endpoint sanity check to avoid dereferencing a NULL-pointer
on open() in case a device lacks a bulk-out endpoint.
Note that prior to commit
f4a4cbb2047e ("USB: ir-usb: reimplement using
generic framework") the oops would instead happen on open() if the
device lacked a bulk-in endpoint and on write() if it lacked a bulk-out
endpoint.
Fixes:
f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:25 +0000 (12:44 +0100)]
rsi_91x_usb: fix interface sanity check
commit
3139b180906af43bc09bd3373fc2338a8271d9d9 upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
dad0d04fa7ba ("rsi: Add RS9113 wireless driver")
Cc: stable <stable@vger.kernel.org> # 3.15
Cc: Fariya Fatima <fariyaf@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Dec 2019 11:44:23 +0000 (12:44 +0100)]
orinoco_usb: fix interface sanity check
commit
b73e05aa543cf8db4f4927e36952360d71291d41 upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
9afac70a7305 ("orinoco: add orinoco_usb driver")
Cc: stable <stable@vger.kernel.org> # 2.6.35
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 29 Jan 2020 14:02:39 +0000 (15:02 +0100)]
Linux 4.14.169
Martin Schiller [Thu, 9 Jan 2020 06:31:14 +0000 (07:31 +0100)]
net/x25: fix nonblocking connect
commit
e21dba7a4df4d93da237da65a096084b4f2e87b4 upstream.
This patch fixes 2 issues in x25_connect():
1. It makes absolutely no sense to reset the neighbour and the
connection state after a (successful) nonblocking call of x25_connect.
This prevents any connection from being established, since the response
(call accept) cannot be processed.
2. Any further calls to x25_connect() while a call is pending should
simply return, instead of creating new Call Request (on different
logical channels).
This patch should also fix the "KASAN: null-ptr-deref Write in
x25_connect" and "BUG: unable to handle kernel NULL pointer dereference
in x25_connect" bugs reported by syzbot.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com
Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kadlecsik József [Sun, 19 Jan 2020 21:06:49 +0000 (22:06 +0100)]
netfilter: ipset: use bitmap infrastructure completely
commit
32c72165dbd0e246e69d16a3ad348a4851afd415 upstream.
The bitmap allocation did not use full unsigned long sizes
when calculating the required size and that was triggered by KASAN
as slab-out-of-bounds read in several places. The patch fixes all
of them.
Reported-by: syzbot+fabca5cbf5e54f3fe2de@syzkaller.appspotmail.com
Reported-by: syzbot+827ced406c9a1d9570ed@syzkaller.appspotmail.com
Reported-by: syzbot+190d63957b22ef673ea5@syzkaller.appspotmail.com
Reported-by: syzbot+dfccdb2bdb4a12ad425e@syzkaller.appspotmail.com
Reported-by: syzbot+df0d0f5895ef1f41a65b@syzkaller.appspotmail.com
Reported-by: syzbot+b08bd19bb37513357fd4@syzkaller.appspotmail.com
Reported-by: syzbot+53cdd0ec0bbabd53370a@syzkaller.appspotmail.com
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Shevchenko [Wed, 1 Aug 2018 22:42:56 +0000 (15:42 -0700)]
bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
commit
c42b65e363ce97a828f81b59033c3558f8fa7f70 upstream.
A lot of code become ugly because of open coding allocations for bitmaps.
Introduce three helpers to allow users be more clear of intention
and keep their code neat.
Note, due to multiple circular dependencies we may not provide
the helpers as inliners. For now we keep them exported and, perhaps,
at some point in the future we will sort out header inclusion and
inheritance.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Shevchenko [Tue, 28 Jan 2020 11:49:12 +0000 (12:49 +0100)]
md: Avoid namespace collision with bitmap API
commit
e64e4018d572710c44f42c923d4ac059f0a23320 upstream.
bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods.
On the other hand MD bitmap API is special case.
Adding 'md' prefix to it to avoid name space collision.
No functional changes intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Shaohua Li <shli@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[only take the bitmap_free change for stable - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bo Wu [Wed, 20 Nov 2019 13:26:17 +0000 (13:26 +0000)]
scsi: iscsi: Avoid potential deadlock in iscsi_if_rx func
commit
bba340c79bfe3644829db5c852fdfa9e33837d6d upstream.
In iscsi_if_rx func, after receiving one request through
iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
reply to the request in a do-while loop. If the iscsi_if_send_reply
function keeps returning -EAGAIN, a deadlock will occur.
For example, a client only send msg without calling recvmsg func, then
it will result in the watchdog soft lockup. The details are given as
follows:
sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI);
retval = bind(sock_fd, (struct sock addr*) & src_addr, sizeof(src_addr);
while (1) {
state_msg = sendmsg(sock_fd, &msg, 0);
//Note: recvmsg(sock_fd, &msg, 0) is not processed here.
}
close(sock_fd);
watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305] Sample time:
4000897528 ns(HZ: 250) Sample stat:
curr: user:
675503481560, nice:
321724050, sys:
448689506750, idle:
4654054240530, iowait:
40885550700, irq:
14161174020, softirq:
8104324140, st: 0
deta: user: 0, nice: 0, sys:
3998210100, idle: 0, iowait: 0, irq:
1547170, softirq: 242870, st: 0 Sample softirq:
TIMER: 992
SCHED: 8
Sample irqstat:
irq 2: delta 1003, curr:
3103802, arch_timer
CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G OE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate:
40400005 (nZcv daif +PAN -UAO)
pc : __alloc_skb+0x104/0x1b0
lr : __alloc_skb+0x9c/0x1b0
sp :
ffff000033603a30
x29:
ffff000033603a30 x28:
00000000000002dd
x27:
ffff800b34ced810 x26:
ffff800ba7569f00
x25:
00000000ffffffff x24:
0000000000000000
x23:
ffff800f7c43f600 x22:
0000000000480020
x21:
ffff0000091d9000 x20:
ffff800b34eff200
x19:
ffff800ba7569f00 x18:
0000000000000000
x17:
0000000000000000 x16:
0000000000000000
x15:
0000000000000000 x14:
0001000101000100
x13:
0000000101010000 x12:
0101000001010100
x11:
0001010101010001 x10:
00000000000002dd
x9 :
ffff000033603d58 x8 :
ffff800b34eff400
x7 :
ffff800ba7569200 x6 :
ffff800b34eff400
x5 :
0000000000000000 x4 :
00000000ffffffff
x3 :
0000000000000000 x2 :
0000000000000001
x1 :
ffff800b34eff2c0 x0 :
0000000000000300 Call trace:
__alloc_skb+0x104/0x1b0
iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi]
netlink_unicast+0x1e0/0x258
netlink_sendmsg+0x310/0x378
sock_sendmsg+0x4c/0x70
sock_write_iter+0x90/0xf0
__vfs_write+0x11c/0x190
vfs_write+0xac/0x1c0
ksys_write+0x6c/0xd8
__arm64_sys_write+0x24/0x30
el0_svc_common+0x78/0x130
el0_svc_handler+0x38/0x78
el0_svc+0x8/0xc
Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6915E3D4D2@dggeml505-mbx.china.huawei.com
Signed-off-by: Bo Wu <wubo40@huawei.com>
Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Sun, 10 Nov 2019 06:27:04 +0000 (07:27 +0100)]
media: v4l2-ioctl.c: zero reserved fields for S/TRY_FMT
commit
ee8951e56c0f960b9621636603a822811cef3158 upstream.
v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format
have a reserved array at the end that should be zeroed by drivers
as per the V4L2 spec. Older drivers often do not do this, so just
handle this in the core.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wen Huang [Thu, 28 Nov 2019 10:51:04 +0000 (18:51 +0800)]
libertas: Fix two buffer overflows at parsing bss descriptor
commit
e5e884b42639c74b5b57dc277909915c0aefc8bb upstream.
add_ie_rates() copys rates without checking the length
in bss descriptor from remote AP.when victim connects to
remote attacker, this may trigger buffer overflow.
lbs_ibss_join_existing() copys rates without checking the length
in bss descriptor from remote IBSS node.when victim connects to
remote attacker, this may trigger buffer overflow.
Fix them by putting the length check before performing copy.
This fix addresses CVE-2019-14896 and CVE-2019-14897.
This also fix build warning of mixed declarations and code.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Wen Huang <huangwenabc@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Thu, 20 Jun 2019 22:12:35 +0000 (16:12 -0600)]
coresight: tmc-etf: Do not call smp_processor_id from preemptible
commit
024c1fd9dbcc1d8a847f1311f999d35783921b7f upstream.
During a perf session we try to allocate buffers on the "node" associated
with the CPU the event is bound to. If it is not bound to a CPU, we
use the current CPU node, using smp_processor_id(). However this is unsafe
in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [
00000000] code: perf/2544
caller is tmc_alloc_etf_buffer+0x5c/0x60
CPU: 2 PID: 2544 Comm: perf Not tainted
5.1.0-rc6-147786-g116841e #344
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019
Call trace:
dump_backtrace+0x0/0x150
show_stack+0x14/0x20
dump_stack+0x9c/0xc4
debug_smp_processor_id+0x10c/0x110
tmc_alloc_etf_buffer+0x5c/0x60
etm_setup_aux+0x1c4/0x230
rb_alloc_aux+0x1b8/0x2b8
perf_mmap+0x35c/0x478
mmap_region+0x34c/0x4f0
do_mmap+0x2d8/0x418
vm_mmap_pgoff+0xd0/0xf8
ksys_mmap_pgoff+0x88/0xf8
__arm64_sys_mmap+0x28/0x38
el0_svc_handler+0xd8/0x138
el0_svc+0x8/0xc
Use NUMA_NO_NODE hint instead of using the current node for events
not bound to CPUs.
Fixes:
2e499bbc1a929ac ("coresight: tmc: implementing TMC-ETF AUX space API")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable <stable@vger.kernel.org> # 4.7+
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20190620221237.3536-4-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Thu, 20 Jun 2019 22:12:36 +0000 (16:12 -0600)]
coresight: etb10: Do not call smp_processor_id from preemptible
commit
730766bae3280a25d40ea76a53dc6342e84e6513 upstream.
During a perf session we try to allocate buffers on the "node" associated
with the CPU the event is bound to. If it is not bound to a CPU, we
use the current CPU node, using smp_processor_id(). However this is unsafe
in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [
00000000] code: perf/2544
Use NUMA_NO_NODE hint instead of using the current node for events
not bound to CPUs.
Fixes:
2997aa4063d97fdb39 ("coresight: etb10: implementing AUX API")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable <stable@vger.kernel.org> # 4.6+
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20190620221237.3536-5-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masato Suzuki [Mon, 27 Jan 2020 05:07:46 +0000 (14:07 +0900)]
sd: Fix REQ_OP_ZONE_REPORT completion handling
ZBC/ZAC report zones command may return less bytes than requested if the
number of matching zones for the report request is small. However, unlike
read or write commands, the remainder of incomplete report zones commands
cannot be automatically requested by the block layer: the start sector of
the next report cannot be known, and the report reply may not be 512B
aligned for SAS drives (a report zone reply size is always a multiple of
64B). The regular request completion code executing bio_advance() and
restart of the command remainder part currently causes invalid zone
descriptor data to be reported to the caller if the report zone size is
smaller than 512B (a case that can happen easily for a report of the last
zones of a SAS drive for example).
Since blkdev_report_zones() handles report zone command processing in a
loop until completion (no more zones are being reported), we can safely
avoid that the block layer performs an incorrect bio_advance() call and
restart of the remainder of incomplete report zone BIOs. To do so, always
indicate a full completion of REQ_OP_ZONE_REPORT by setting good_bytes to
the request buffer size and by setting the command resid to 0. This does
not affect the post processing of the report zone reply done by
sd_zbc_complete() since the reply header indicates the number of zones
reported.
Fixes:
89d947561077 ("sd: Implement support for ZBC devices")
Cc: <stable@vger.kernel.org> # 4.19
Cc: <stable@vger.kernel.org> # 4.14
Signed-off-by: Masato Suzuki <masato.suzuki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 26 Jan 2020 14:29:34 +0000 (09:29 -0500)]
do_last(): fetch directory ->i_mode and ->i_uid before it's too late
commit
d0cb50185ae942b03c4327be322055d622dc79f6 upstream.
may_create_in_sticky() call is done when we already have dropped the
reference to dir.
Fixes:
30aba6656f61e (namei: allow restricted O_CREAT of FIFOs and regular files)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Changbin Du [Sun, 12 Jan 2020 03:42:31 +0000 (11:42 +0800)]
tracing: xen: Ordered comparison of function pointers
commit
d0695e2351102affd8efae83989056bc4b275917 upstream.
Just as commit
0566e40ce7 ("tracing: initcall: Ordered comparison of
function pointers"), this patch fixes another remaining one in xen.h
found by clang-9.
In file included from arch/x86/xen/trace.c:21:
In file included from ./include/trace/events/xen.h:475:
In file included from ./include/trace/define_trace.h:102:
In file included from ./include/trace/trace_events.h:473:
./include/trace/events/xen.h:69:7: warning: ordered comparison of function \
pointers ('xen_mc_callback_fn_t' (aka 'void (*)(void *)') and 'xen_mc_callback_fn_t') [-Wordered-compare-function-pointers]
__field(xen_mc_callback_fn_t, fn)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:421:29: note: expanded from macro '__field'
^
./include/trace/trace_events.h:407:6: note: expanded from macro '__field_ext'
is_signed_type(type), filter_type); \
^
./include/linux/trace_events.h:554:44: note: expanded from macro 'is_signed_type'
^
Fixes:
c796f213a6934 ("xen/trace: add multicall tracing")
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Thu, 16 Jan 2020 04:47:37 +0000 (20:47 -0800)]
scsi: RDMA/isert: Fix a recently introduced regression related to logout
commit
04060db41178c7c244f2c7dcd913e7fd331de915 upstream.
iscsit_close_connection() calls isert_wait_conn(). Due to commit
e9d3009cb936 both functions call target_wait_for_sess_cmds() although that
last function should be called only once. Fix this by removing the
target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling
isert_wait_conn() after target_wait_for_sess_cmds().
Fixes:
e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session").
Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.org
Reported-by: Rahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gilles Buloz [Wed, 27 Nov 2019 17:09:34 +0000 (18:09 +0100)]
hwmon: (nct7802) Fix voltage limits to wrong registers
commit
7713e62c8623c54dac88d1fa724aa487a38c3efb upstream.
in0 thresholds are written to the in2 thresholds registers
in2 thresholds to in3 thresholds
in3 thresholds to in4 thresholds
in4 thresholds to in0 thresholds
Signed-off-by: Gilles Buloz <gilles.buloz@kontron.com>
Link: https://lore.kernel.org/r/5de0f509.rc0oEvPOMjbfPW1w%gilles.buloz@kontron.com
Fixes:
3434f3783580 ("hwmon: Driver for Nuvoton NCT7802Y")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuhong Yuan [Fri, 10 Jan 2020 18:30:04 +0000 (10:30 -0800)]
Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register
commit
97e24b095348a15ec08c476423c3b3b939186ad7 upstream.
The driver misses a check for devm_thermal_zone_of_sensor_register().
Add a check to fix it.
Fixes:
e28d0c9cd381 ("input: convert sun4i-ts to use devm_thermal_zone_of_sensor_register")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 19:55:47 +0000 (11:55 -0800)]
Input: pegasus_notetaker - fix endpoint sanity check
commit
bcfcb7f9b480dd0be8f0df2df17340ca92a03b98 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could be used by a
malicious device (or USB descriptor fuzzer) to trigger a NULL-pointer
dereference.
Fixes:
1afca2b66aac ("Input: add Pegasus Notetaker tablet driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Martin Kepplinger <martink@posteo.de>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-2-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 19:59:32 +0000 (11:59 -0800)]
Input: aiptek - fix endpoint sanity check
commit
3111491fca4f01764e0c158c5e0f7ced808eef51 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 20:00:18 +0000 (12:00 -0800)]
Input: gtco - fix endpoint sanity check
commit
a8eeb74df5a6bdb214b2b581b14782c5f5a0cf83 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
162f98dea487 ("Input: gtco - fix crash on detecting device without endpoints")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 20:01:27 +0000 (12:01 -0800)]
Input: sur40 - fix interface sanity checks
commit
6b32391ed675827f8425a414abbc6fbd54ea54fe upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-8-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephan Gerhold [Fri, 17 Jan 2020 21:40:36 +0000 (13:40 -0800)]
Input: pm8xxx-vib - fix handling of separate enable register
commit
996d5d5f89a558a3608a46e73ccd1b99f1b1d058 upstream.
Setting the vibrator enable_mask is not implemented correctly:
For regmap_update_bits(map, reg, mask, val) we give in either
regs->enable_mask or 0 (= no-op) as mask and "val" as value.
But "val" actually refers to the vibrator voltage control register,
which has nothing to do with the enable_mask.
So we usually end up doing nothing when we really wanted
to enable the vibrator.
We want to set or clear the enable_mask (to enable/disable the vibrator).
Therefore, change the call to always modify the enable_mask
and set the bits only if we want to enable the vibrator.
Fixes:
d4c7c5c96c92 ("Input: pm8xxx-vib - handle separate enable register")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeremy Linton [Fri, 25 Jan 2019 18:07:00 +0000 (12:07 -0600)]
Documentation: Document arm64 kpti control
commit
de19055564c8f8f9d366f8db3395836da0b2176c upstream.
For a while Arm64 has been capable of force enabling
or disabling the kpti mitigations. Lets make sure the
documentation reflects that.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Wed, 15 Jan 2020 09:54:35 +0000 (10:54 +0100)]
mmc: sdhci: fix minimum clock rate for v3 controller
commit
2a187d03352086e300daa2044051db00044cd171 upstream.
For SDHCIv3+ with programmable clock mode, minimal clock frequency is
still base clock / max(divider). Minimal programmable clock frequency is
always greater than minimal divided clock frequency. Without this patch,
SDHCI uses out-of-spec initial frequency when multiplier is big enough:
mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz
[for 480 MHz source clock divided by 1024]
The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode.
Fixes:
c3ed3877625f ("mmc: sdhci: add support for programmable clock mode")
Cc: <stable@vger.kernel.org> # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present
Cc: <stable@vger.kernel.org>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Tue, 7 Jan 2020 09:47:34 +0000 (10:47 +0100)]
mmc: tegra: fix SDR50 tuning override
commit
f571389c0b015e76f91c697c4c1700aba860d34f upstream.
Commit
7ad2ed1dfcbe inadvertently mixed up a quirk flag's name and
broke SDR50 tuning override. Use correct NVQUIRK_ name.
Fixes:
7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
Cc: <stable@vger.kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/9aff1d859935e59edd81e4939e40d6c55e0b55f6.1578390388.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Sverdlin [Wed, 8 Jan 2020 14:57:47 +0000 (15:57 +0100)]
ARM: 8950/1: ftrace/recordmcount: filter relocation types
commit
927d780ee371d7e121cea4fc7812f6ef2cea461c upstream.
Scenario 1, ARMv7
=================
If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:
00000230 <prealloc_fixed_plts>:
230: b5f8 push {r3, r4, r5, r6, r7, lr}
232: b500 push {lr}
234: f7ff fffe bl 0 <__gnu_mcount_nc>
234: R_ARM_THM_CALL __gnu_mcount_nc
238: f240 0600 movw r6, #0
238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc
23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180
FTRACE currently is not able to deal with it:
WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230()
...
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1
...
[<
c0314e3d>] (unwind_backtrace) from [<
c03115e9>] (show_stack+0x11/0x14)
[<
c03115e9>] (show_stack) from [<
c051a7f1>] (dump_stack+0x81/0xa8)
[<
c051a7f1>] (dump_stack) from [<
c0321c5d>] (warn_slowpath_common+0x69/0x90)
[<
c0321c5d>] (warn_slowpath_common) from [<
c0321cf3>] (warn_slowpath_null+0x17/0x1c)
[<
c0321cf3>] (warn_slowpath_null) from [<
c038ee9d>] (ftrace_bug+0x1ad/0x230)
[<
c038ee9d>] (ftrace_bug) from [<
c038f1f9>] (ftrace_process_locs+0x27d/0x444)
[<
c038f1f9>] (ftrace_process_locs) from [<
c08915bd>] (ftrace_init+0x91/0xe8)
[<
c08915bd>] (ftrace_init) from [<
c0885a67>] (start_kernel+0x34b/0x358)
[<
c0885a67>] (start_kernel) from [<
00308095>] (0x308095)
---[ end trace
cb88537fdc8fa200 ]---
ftrace failed to modify [<
c031266c>] prealloc_fixed_plts+0x8/0x60
actual: 44:f2:e1:36
ftrace record flags: 0
(0) expected tramp:
c03143e9
Scenario 2, ARMv4T
==================
ftrace: allocating 14435 entries in 43 pages
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1
Hardware name: Cirrus Logic
EDB9302 Evaluation Board
[<
c0010a24>] (unwind_backtrace) from [<
c000ecb0>] (show_stack+0x20/0x2c)
[<
c000ecb0>] (show_stack) from [<
c03c72e8>] (dump_stack+0x20/0x30)
[<
c03c72e8>] (dump_stack) from [<
c0021c18>] (__warn+0xdc/0x104)
[<
c0021c18>] (__warn) from [<
c0021d7c>] (warn_slowpath_null+0x4c/0x5c)
[<
c0021d7c>] (warn_slowpath_null) from [<
c0095360>] (ftrace_bug+0x204/0x310)
[<
c0095360>] (ftrace_bug) from [<
c04dabac>] (ftrace_init+0x3b4/0x4d4)
[<
c04dabac>] (ftrace_init) from [<
c04cef4c>] (start_kernel+0x20c/0x410)
[<
c04cef4c>] (start_kernel) from [<
00000000>] ( (null))
---[ end trace
0506a2f5dae6b341 ]---
ftrace failed to modify
[<
c000c350>] perf_trace_sys_exit+0x5c/0xe8
actual: 1e:ff:2f:e1
Initializing ftrace call sites
ftrace record flags: 0
(0)
expected tramp:
c000fb24
The analysis for this problem has been already performed previously,
refer to the link below.
Fix the above problems by allowing only selected reloc types in
__mcount_loc. The list itself comes from the legacy recordmcount.pl
script.
Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/
Cc: stable@vger.kernel.org
Fixes:
ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Fri, 17 Jan 2020 04:12:27 +0000 (20:12 -0800)]
Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers"
commit
8ff771f8c8d55d95f102cf88a970e541a8bd6bcf upstream.
This reverts commit
a284e11c371e446371675668d8c8120a27227339.
This causes problems (drifting cursor) with at least the F11 function that
reads more than 32 bytes.
The real issue is in the F54 driver, and so this should be fixed there, and
not in rmi_smbus.c.
So first revert this bad commit, then fix the real problem in F54 in another
patch.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: Timo Kaufmann <timokau@zoho.com>
Fixes:
a284e11c371e ("Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200115124819.3191024-2-hverkuil-cisco@xs4all.nl
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 13 Jan 2020 18:38:57 +0000 (10:38 -0800)]
Input: keyspan-remote - fix control-message timeouts
commit
ba9a103f40fc4a3ec7558ec9b0b97d4f92034249 upstream.
The driver was issuing synchronous uninterruptible control requests
without using a timeout. This could lead to the driver hanging on probe
due to a malfunctioning (or malicious) device until the device is
physically disconnected. While sleeping in probe the driver prevents
other devices connected to the same hub from being added to (or removed
from) the bus.
The USB upper limit of five seconds per request should be more than
enough.
Fixes:
99f83c9c9ac9 ("[PATCH] USB: add driver for Keyspan Digital Remote")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org> # 2.6.13
Link: https://lore.kernel.org/r/20200113171715.30621-1-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Thu, 16 Jan 2020 18:44:17 +0000 (10:44 -0800)]
hwmon: (core) Do not use device managed functions for memory allocations
commit
3bf8bdcf3bada771eb12b57f2a30caee69e8ab8d upstream.
The hwmon core uses device managed functions, tied to the hwmon parent
device, for various internal memory allocations. This is problematic
since hwmon device lifetime does not necessarily match its parent's
device lifetime. If there is a mismatch, memory leaks will accumulate
until the parent device is released.
Fix the problem by managing all memory allocations internally. The only
exception is memory allocation for thermal device registration, which
can be tied to the hwmon device, along with thermal device registration
itself.
Fixes:
d560168b5d0f ("hwmon: (core) New hwmon registration API")
Cc: stable@vger.kernel.org # v4.14.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.14.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9.x: 3a412d5e4a1c: hwmon: (core) Simplify sysfs attribute name allocation
Cc: stable@vger.kernel.org # v4.9.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.9.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9+
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Osipenko [Wed, 24 Oct 2018 19:37:13 +0000 (22:37 +0300)]
hwmon: (core) Fix double-free in __hwmon_device_register()
commit
74e3512731bd5c9673176425a76a7cc5efa8ddb6 upstream.
Fix double-free that happens when thermal zone setup fails, see KASAN log
below.
==================================================================
BUG: KASAN: double-free or invalid-free in __hwmon_device_register+0x5dc/0xa7c
CPU: 0 PID: 132 Comm: kworker/0:2 Tainted: G B
4.19.0-rc8-next-20181016-00042-gb52cd80401e9-dirty #41
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
[<
c0110540>] (dump_backtrace) from [<
c0110944>] (show_stack+0x20/0x24)
[<
c0110924>] (show_stack) from [<
c105cb08>] (dump_stack+0x9c/0xb0)
[<
c105ca6c>] (dump_stack) from [<
c02fdaec>] (print_address_description+0x68/0x250)
[<
c02fda84>] (print_address_description) from [<
c02fd4ac>] (kasan_report_invalid_free+0x68/0x88)
[<
c02fd444>] (kasan_report_invalid_free) from [<
c02fc85c>] (__kasan_slab_free+0x1f4/0x200)
[<
c02fc668>] (__kasan_slab_free) from [<
c02fd0c0>] (kasan_slab_free+0x14/0x18)
[<
c02fd0ac>] (kasan_slab_free) from [<
c02f9c6c>] (kfree+0x90/0x294)
[<
c02f9bdc>] (kfree) from [<
c0b41bbc>] (__hwmon_device_register+0x5dc/0xa7c)
[<
c0b415e0>] (__hwmon_device_register) from [<
c0b421e8>] (hwmon_device_register_with_info+0xa0/0xa8)
[<
c0b42148>] (hwmon_device_register_with_info) from [<
c0b42324>] (devm_hwmon_device_register_with_info+0x74/0xb4)
[<
c0b422b0>] (devm_hwmon_device_register_with_info) from [<
c0b4481c>] (lm90_probe+0x414/0x578)
[<
c0b44408>] (lm90_probe) from [<
c0aeeff4>] (i2c_device_probe+0x35c/0x384)
[<
c0aeec98>] (i2c_device_probe) from [<
c08776cc>] (really_probe+0x290/0x3e4)
[<
c087743c>] (really_probe) from [<
c0877a2c>] (driver_probe_device+0x80/0x1c4)
[<
c08779ac>] (driver_probe_device) from [<
c0877da8>] (__device_attach_driver+0x104/0x11c)
[<
c0877ca4>] (__device_attach_driver) from [<
c0874dd8>] (bus_for_each_drv+0xa4/0xc8)
[<
c0874d34>] (bus_for_each_drv) from [<
c08773b0>] (__device_attach+0xf0/0x15c)
[<
c08772c0>] (__device_attach) from [<
c0877e24>] (device_initial_probe+0x1c/0x20)
[<
c0877e08>] (device_initial_probe) from [<
c08762f4>] (bus_probe_device+0xdc/0xec)
[<
c0876218>] (bus_probe_device) from [<
c0876a08>] (deferred_probe_work_func+0xa8/0xd4)
[<
c0876960>] (deferred_probe_work_func) from [<
c01527c4>] (process_one_work+0x3dc/0x96c)
[<
c01523e8>] (process_one_work) from [<
c01541e0>] (worker_thread+0x4ec/0x8bc)
[<
c0153cf4>] (worker_thread) from [<
c015b238>] (kthread+0x230/0x240)
[<
c015b008>] (kthread) from [<
c01010bc>] (ret_from_fork+0x14/0x38)
Exception stack(0xcf743fb0 to 0xcf743ff8)
3fa0:
00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000
Allocated by task 132:
kasan_kmalloc.part.1+0x58/0xf4
kasan_kmalloc+0x90/0xa4
kmem_cache_alloc_trace+0x90/0x2a0
__hwmon_device_register+0xbc/0xa7c
hwmon_device_register_with_info+0xa0/0xa8
devm_hwmon_device_register_with_info+0x74/0xb4
lm90_probe+0x414/0x578
i2c_device_probe+0x35c/0x384
really_probe+0x290/0x3e4
driver_probe_device+0x80/0x1c4
__device_attach_driver+0x104/0x11c
bus_for_each_drv+0xa4/0xc8
__device_attach+0xf0/0x15c
device_initial_probe+0x1c/0x20
bus_probe_device+0xdc/0xec
deferred_probe_work_func+0xa8/0xd4
process_one_work+0x3dc/0x96c
worker_thread+0x4ec/0x8bc
kthread+0x230/0x240
ret_from_fork+0x14/0x38
(null)
Freed by task 132:
__kasan_slab_free+0x12c/0x200
kasan_slab_free+0x14/0x18
kfree+0x90/0x294
hwmon_dev_release+0x1c/0x20
device_release+0x4c/0xe8
kobject_put+0xac/0x11c
device_unregister+0x2c/0x30
__hwmon_device_register+0xa58/0xa7c
hwmon_device_register_with_info+0xa0/0xa8
devm_hwmon_device_register_with_info+0x74/0xb4
lm90_probe+0x414/0x578
i2c_device_probe+0x35c/0x384
really_probe+0x290/0x3e4
driver_probe_device+0x80/0x1c4
__device_attach_driver+0x104/0x11c
bus_for_each_drv+0xa4/0xc8
__device_attach+0xf0/0x15c
device_initial_probe+0x1c/0x20
bus_probe_device+0xdc/0xec
deferred_probe_work_func+0xa8/0xd4
process_one_work+0x3dc/0x96c
worker_thread+0x4ec/0x8bc
kthread+0x230/0x240
ret_from_fork+0x14/0x38
(null)
Cc: <stable@vger.kernel.org> # v4.15+
Fixes:
47c332deb8e8 ("hwmon: Deal with errors from the thermal subsystem")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Tue, 5 Dec 2017 08:36:14 +0000 (09:36 +0100)]
hwmon: Deal with errors from the thermal subsystem
commit
47c332deb8e89f6c59b0bb2615945c6e7fad1a60 upstream.
If the thermal subsystem returne -EPROBE_DEFER or any other error
when hwmon calls devm_thermal_zone_of_sensor_register(), this is
silently ignored.
I ran into this with an incorrectly defined thermal zone, making
it non-existing and thus this call failed with -EPROBE_DEFER
assuming it would appear later. The sensor was still added
which is incorrect: sensors must strictly be added after the
thermal zones, so deferred probe must be respected.
Fixes:
d560168b5d0f ("hwmon: (core) New hwmon registration API")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luuk Paulussen [Thu, 5 Dec 2019 23:16:59 +0000 (12:16 +1300)]
hwmon: (adt7475) Make volt2reg return same reg as reg2volt input
commit
cf3ca1877574a306c0207cbf7fdf25419d9229df upstream.
reg2volt returns the voltage that matches a given register value.
Converting this back the other way with volt2reg didn't return the same
register value because it used truncation instead of rounding.
This meant that values read from sysfs could not be written back to sysfs
to set back the same register value.
With this change, volt2reg will return the same value for every voltage
previously returned by reg2volt (for the set of possible input values)
Signed-off-by: Luuk Paulussen <luuk.paulussen@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20191205231659.1301-1-luuk.paulussen@alliedtelesis.co.nz
cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 22 Jan 2020 06:47:29 +0000 (22:47 -0800)]
net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
[ Upstream commit
d836f5c69d87473ff65c06a6123e5b2cf5e56f5b ]
rtnl_create_link() needs to apply dev->min_mtu and dev->max_mtu
checks that we apply in do_setlink()
Otherwise malicious users can crash the kernel, for example after
an integer overflow :
BUG: KASAN: use-after-free in memset include/linux/string.h:365 [inline]
BUG: KASAN: use-after-free in __alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238
Write of size 32 at addr
ffff88819f20b9c0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192
memset+0x24/0x40 mm/kasan/common.c:108
memset include/linux/string.h:365 [inline]
__alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238
alloc_skb include/linux/skbuff.h:1049 [inline]
alloc_skb_with_frags+0x93/0x590 net/core/skbuff.c:5664
sock_alloc_send_pskb+0x7ad/0x920 net/core/sock.c:2242
sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2259
mld_newpack+0x1d7/0x7f0 net/ipv6/mcast.c:1609
add_grhead.isra.0+0x299/0x370 net/ipv6/mcast.c:1713
add_grec+0x7db/0x10b0 net/ipv6/mcast.c:1844
mld_send_cr net/ipv6/mcast.c:1970 [inline]
mld_ifc_timer_expire+0x3d3/0x950 net/ipv6/mcast.c:2477
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x6c3/0x1790 kernel/time/timer.c:1786
__do_softirq+0x262/0x98c kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x19b/0x1e0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
</IRQ>
RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
Code: 98 6b ea f9 eb 8a cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 44 1c 60 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 34 1c 60 00 fb f4 <c3> cc 55 48 89 e5 41 57 41 56 41 55 41 54 53 e8 4e 5d 9a f9 e8 79
RSP: 0018:
ffffffff89807ce8 EFLAGS:
00000286 ORIG_RAX:
ffffffffffffff13
RAX:
1ffffffff13266ae RBX:
ffffffff8987a1c0 RCX:
0000000000000000
RDX:
dffffc0000000000 RSI:
0000000000000006 RDI:
ffffffff8987aa54
RBP:
ffffffff89807d18 R08:
ffffffff8987a1c0 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
dffffc0000000000
R13:
ffffffff8a799980 R14:
0000000000000000 R15:
0000000000000000
arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:690
default_idle_call+0x84/0xb0 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x3c8/0x6e0 kernel/sched/idle.c:269
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:361
rest_init+0x23b/0x371 init/main.c:451
arch_call_rest_init+0xe/0x1b
start_kernel+0x904/0x943 init/main.c:784
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490
x86_64_start_kernel+0x77/0x7b arch/x86/kernel/head64.c:471
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:242
The buggy address belongs to the page:
page:
ffffea00067c82c0 refcount:0 mapcount:0 mapping:
0000000000000000 index:0x0
raw:
057ffe0000000000 ffffea00067c82c8 ffffea00067c82c8 0000000000000000
raw:
0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88819f20b880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88819f20b900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
ffff88819f20b980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88819f20ba00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88819f20ba80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Fixes:
61e84623ace3 ("net: centralize net_device min/max MTU checking")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wen Yang [Mon, 20 Jan 2020 10:04:56 +0000 (18:04 +0800)]
tcp_bbr: improve arithmetic division in bbr_update_bw()
[ Upstream commit
5b2f1f3070b6447b76174ea8bfb7390dc6253ebd ]
do_div() does a 64-by-32 division. Use div64_long() instead of it
if the divisor is long, to avoid truncation to 32-bit.
And as a nice side effect also cleans up the function a bit.
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hughes [Mon, 20 Jan 2020 11:12:40 +0000 (11:12 +0000)]
net: usb: lan78xx: Add .ndo_features_check
[ Upstream commit
ce896476c65d72b4b99fa09c2f33436b4198f034 ]
As reported by Eric Dumazet, there are still some outstanding
cases where the driver does not handle TSO correctly when skb's
are over a certain size. Most cases have been fixed, this patch
should ensure that forwarded SKB's that are greater than
MAX_SINGLE_PACKET_SIZE - TX_OVERHEAD are software segmented
and handled correctly.
Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Hogander [Mon, 20 Jan 2020 07:51:03 +0000 (09:51 +0200)]
net-sysfs: Fix reference count leak
[ Upstream commit
cb626bf566eb4433318d35681286c494f04fedcc ]
Netdev_register_kobject is calling device_initialize. In case of error
reference taken by device_initialize is not given up.
Drivers are supposed to call free_netdev in case of error. In non-error
case the last reference is given up there and device release sequence
is triggered. In error case this reference is kept and the release
sequence is never started.
Fix this by setting reg_state as NETREG_UNREGISTERED if registering
fails.
This is the rootcause for couple of memory leaks reported by Syzkaller:
BUG: memory leak unreferenced object 0xffff8880675ca008 (size 256):
comm "netdev_register", pid 281, jiffies
4294696663 (age 6.808s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
0000000058ca4711>] kmem_cache_alloc_trace+0x167/0x280
[<
000000002340019b>] device_add+0x882/0x1750
[<
000000001d588c3a>] netdev_register_kobject+0x128/0x380
[<
0000000011ef5535>] register_netdevice+0xa1b/0xf00
[<
000000007fcf1c99>] __tun_chr_ioctl+0x20d5/0x3dd0
[<
000000006a5b7b2b>] tun_chr_ioctl+0x2f/0x40
[<
00000000f30f834a>] do_vfs_ioctl+0x1c7/0x1510
[<
00000000fba062ea>] ksys_ioctl+0x99/0xb0
[<
00000000b1c1b8d2>] __x64_sys_ioctl+0x78/0xb0
[<
00000000984cabb9>] do_syscall_64+0x16f/0x580
[<
000000000bde033d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<
00000000e6ca2d9f>] 0xffffffffffffffff
BUG: memory leak
unreferenced object 0xffff8880668ba588 (size 8):
comm "kobject_set_nam", pid 286, jiffies
4294725297 (age 9.871s)
hex dump (first 8 bytes):
6e 72 30 00 cc be df 2b nr0....+
backtrace:
[<
00000000a322332a>] __kmalloc_track_caller+0x16e/0x290
[<
00000000236fd26b>] kstrdup+0x3e/0x70
[<
00000000dd4a2815>] kstrdup_const+0x3e/0x50
[<
0000000049a377fc>] kvasprintf_const+0x10e/0x160
[<
00000000627fc711>] kobject_set_name_vargs+0x5b/0x140
[<
0000000019eeab06>] dev_set_name+0xc0/0xf0
[<
0000000069cb12bc>] netdev_register_kobject+0xc8/0x320
[<
00000000f2e83732>] register_netdevice+0xa1b/0xf00
[<
000000009e1f57cc>] __tun_chr_ioctl+0x20d5/0x3dd0
[<
000000009c560784>] tun_chr_ioctl+0x2f/0x40
[<
000000000d759e02>] do_vfs_ioctl+0x1c7/0x1510
[<
00000000351d7c31>] ksys_ioctl+0x99/0xb0
[<
000000008390040a>] __x64_sys_ioctl+0x78/0xb0
[<
0000000052d196b7>] do_syscall_64+0x16f/0x580
[<
0000000019af9236>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<
00000000bc384531>] 0xffffffffffffffff
v3 -> v4:
Set reg_state to NETREG_UNREGISTERED if registering fails
v2 -> v3:
* Replaced BUG_ON with WARN_ON in free_netdev and netdev_release
v1 -> v2:
* Relying on driver calling free_netdev rather than calling
put_device directly in error path
Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com
Cc: David Miller <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Hogander [Tue, 17 Dec 2019 11:46:34 +0000 (13:46 +0200)]
net-sysfs: Call dev_hold always in rx_queue_add_kobject
commit
ddd9b5e3e765d8ed5a35786a6cb00111713fe161 upstream.
Dev_hold has to be called always in rx_queue_add_kobject.
Otherwise usage count drops below 0 in case of failure in
kobject_init_and_add.
Fixes:
b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Reported-by: syzbot <syzbot+30209ea299c09d8785c9@syzkaller.appspotmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Miller <davem@davemloft.net>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Hogander [Thu, 5 Dec 2019 13:57:07 +0000 (15:57 +0200)]
net-sysfs: Call dev_hold always in netdev_queue_add_kobject
commit
e0b60903b434a7ee21ba8d8659f207ed84101e89 upstream.
Dev_hold has to be called always in netdev_queue_add_kobject.
Otherwise usage count drops below 0 in case of failure in
kobject_init_and_add.
Fixes:
b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Reported-by: Hulk Robot <hulkci@huawei.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Miller <davem@davemloft.net>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 21 Nov 2019 03:19:07 +0000 (19:19 -0800)]
net-sysfs: fix netdev_queue_add_kobject() breakage
commit
48a322b6f9965b2f1e4ce81af972f0e287b07ed0 upstream.
kobject_put() should only be called in error path.
Fixes:
b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Hogander [Wed, 20 Nov 2019 07:08:16 +0000 (09:08 +0200)]
net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject
commit
b8eb718348b8fb30b5a7d0a8fce26fb3f4ac741b upstream.
kobject_init_and_add takes reference even when it fails. This has
to be given up by the caller in error handling. Otherwise memory
allocated by kobject_init_and_add is never freed. Originally found
by Syzkaller:
BUG: memory leak
unreferenced object 0xffff8880679f8b08 (size 8):
comm "netdev_register", pid 269, jiffies
4294693094 (age 12.132s)
hex dump (first 8 bytes):
72 78 2d 30 00 36 20 d4 rx-0.6 .
backtrace:
[<
000000008c93818e>] __kmalloc_track_caller+0x16e/0x290
[<
000000001f2e4e49>] kvasprintf+0xb1/0x140
[<
000000007f313394>] kvasprintf_const+0x56/0x160
[<
00000000aeca11c8>] kobject_set_name_vargs+0x5b/0x140
[<
0000000073a0367c>] kobject_init_and_add+0xd8/0x170
[<
0000000088838e4b>] net_rx_queue_update_kobjects+0x152/0x560
[<
000000006be5f104>] netdev_register_kobject+0x210/0x380
[<
00000000e31dab9d>] register_netdevice+0xa1b/0xf00
[<
00000000f68b2465>] __tun_chr_ioctl+0x20d5/0x3dd0
[<
000000004c50599f>] tun_chr_ioctl+0x2f/0x40
[<
00000000bbd4c317>] do_vfs_ioctl+0x1c7/0x1510
[<
00000000d4c59e8f>] ksys_ioctl+0x99/0xb0
[<
00000000946aea81>] __x64_sys_ioctl+0x78/0xb0
[<
0000000038d946e5>] do_syscall_64+0x16f/0x580
[<
00000000e0aa5d8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<
00000000285b3d1a>] 0xffffffffffffffff
Cc: David Miller <davem@davemloft.net>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Wang [Wed, 22 Jan 2020 23:42:02 +0000 (15:42 -0800)]
net_sched: fix datalen for ematch
[ Upstream commit
61678d28d4a45ef376f5d02a839cc37509ae9281 ]
syzbot reported an out-of-bound access in em_nbyte. As initially
analyzed by Eric, this is because em_nbyte sets its own em->datalen
in em_nbyte_change() other than the one specified by user, but this
value gets overwritten later by its caller tcf_em_validate().
We should leave em->datalen untouched to respect their choices.
I audit all the in-tree ematch users, all of those implement
->change() set em->datalen, so we can just avoid setting it twice
in this case.
Reported-and-tested-by: syzbot+5af9a90dad568aa9f611@syzkaller.appspotmail.com
Reported-by: syzbot+2f07903a5b05e7f36410@syzkaller.appspotmail.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Dauchy [Tue, 21 Jan 2020 14:26:24 +0000 (15:26 +0100)]
net, ip_tunnel: fix namespaces move
[ Upstream commit
d0f418516022c32ecceaf4275423e5bd3f8743a9 ]
in the same manner as commit
690afc165bb3 ("net: ip6_gre: fix moving
ip6gre between namespaces"), fix namespace moving as it was broken since
commit
2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.").
Indeed, the ip6_gre commit removed the local flag for collect_md
condition, so there is no reason to keep it for ip_gre/ip_tunnel.
this patch will fix both ip_tunnel and ip_gre modules.
Fixes:
2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Dauchy [Tue, 21 Jan 2020 20:49:54 +0000 (21:49 +0100)]
net, ip6_tunnel: fix namespaces move
[ Upstream commit
5311a69aaca30fa849c3cc46fb25f75727fb72d0 ]
in the same manner as commit
d0f418516022 ("net, ip_tunnel: fix
namespaces move"), fix namespace moving as it was broken since commit
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel"), but for
ipv6 this time; there is no reason to keep it for ip6_tunnel.
Fixes:
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Fri, 24 Jan 2020 09:41:44 +0000 (20:41 +1100)]
net: cxgb3_main: Add CAP_NET_ADMIN check to CHELSIO_GET_MEM
[ Upstream commit
3546d8f1bbe992488ed91592cf6bf76e7114791a =
The cxgb3 driver for "Chelsio T3-based gigabit and 10Gb Ethernet
adapters" implements a custom ioctl as SIOCCHIOCTL/SIOCDEVPRIVATE in
cxgb_extension_ioctl().
One of the subcommands of the ioctl is CHELSIO_GET_MEM, which appears
to read memory directly out of the adapter and return it to userspace.
It's not entirely clear what the contents of the adapter memory
contains, but the assumption is that it shouldn't be accessible to all
users.
So add a CAP_NET_ADMIN check to the CHELSIO_GET_MEM case. Put it after
the is_offload() check, which matches two of the other subcommands in
the same function which also check for is_offload() and CAP_NET_ADMIN.
Found by Ilja by code inspection, not tested as I don't have the
required hardware.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuki Taguchi [Mon, 20 Jan 2020 04:48:37 +0000 (13:48 +0900)]
ipv6: sr: remove SKB_GSO_IPXIP6 on End.D* actions
[ Upstream commit
62ebaeaedee7591c257543d040677a60e35c7aec ]
After LRO/GRO is applied, SRv6 encapsulated packets have
SKB_GSO_IPXIP6 feature flag, and this flag must be removed right after
decapulation procedure.
Currently, SKB_GSO_IPXIP6 flag is not removed on End.D* actions, which
creates inconsistent packet state, that is, a normal TCP/IP packets
have the SKB_GSO_IPXIP6 flag. This behavior can cause unexpected
fallback to GSO on routing to netdevices that do not support
SKB_GSO_IPXIP6. For example, on inter-VRF forwarding, decapsulated
packets separated into small packets by GSO because VRF devices do not
support TSO for packets with SKB_GSO_IPXIP6 flag, and this degrades
forwarding performance.
This patch removes encapsulation related GSO flags from the skb right
after the End.D* action is applied.
Fixes:
d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local")
Signed-off-by: Yuki Taguchi <tagyounit@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 22 Jan 2020 07:17:14 +0000 (23:17 -0800)]
gtp: make sure only SOCK_DGRAM UDP sockets are accepted
[ Upstream commit
940ba14986657a50c15f694efca1beba31fa568f ]
A malicious user could use RAW sockets and fool
GTP using them as standard SOCK_DGRAM UDP sockets.
BUG: KMSAN: uninit-value in udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
BUG: KMSAN: uninit-value in setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
CPU: 0 PID: 11262 Comm: syz-executor613 Not tainted 5.5.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
gtp_encap_enable_socket+0x37f/0x5a0 drivers/net/gtp.c:827
gtp_encap_enable drivers/net/gtp.c:844 [inline]
gtp_newlink+0xfb/0x1e50 drivers/net/gtp.c:666
__rtnl_newlink net/core/rtnetlink.c:3305 [inline]
rtnl_newlink+0x2973/0x3920 net/core/rtnetlink.c:3363
rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424
netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:639 [inline]
sock_sendmsg net/socket.c:659 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
___sys_sendmsg net/socket.c:2384 [inline]
__sys_sendmsg+0x451/0x5f0 net/socket.c:2417
__do_sys_sendmsg net/socket.c:2426 [inline]
__se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441359
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fff1cd0ac28 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
0000000000441359
RDX:
0000000000000000 RSI:
0000000020000100 RDI:
0000000000000003
RBP:
00000000006cb018 R08:
00000000004002c8 R09:
00000000004002c8
R10:
00000000004002c8 R11:
0000000000000246 R12:
00000000004020d0
R13:
0000000000402160 R14:
0000000000000000 R15:
0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags+0x3c/0x90 mm/kmsan/kmsan.c:144
kmsan_internal_alloc_meta_for_pages mm/kmsan/kmsan_shadow.c:307 [inline]
kmsan_alloc_page+0x12a/0x310 mm/kmsan/kmsan_shadow.c:336
__alloc_pages_nodemask+0x57f2/0x5f60 mm/page_alloc.c:4800
alloc_pages_current+0x67d/0x990 mm/mempolicy.c:2207
alloc_pages include/linux/gfp.h:534 [inline]
alloc_slab_page+0x111/0x12f0 mm/slub.c:1511
allocate_slab mm/slub.c:1656 [inline]
new_slab+0x2bc/0x1130 mm/slub.c:1722
new_slab_objects mm/slub.c:2473 [inline]
___slab_alloc+0x1533/0x1f30 mm/slub.c:2624
__slab_alloc mm/slub.c:2664 [inline]
slab_alloc_node mm/slub.c:2738 [inline]
slab_alloc mm/slub.c:2783 [inline]
kmem_cache_alloc+0xb23/0xd70 mm/slub.c:2788
sk_prot_alloc+0xf2/0x620 net/core/sock.c:1597
sk_alloc+0xf0/0xbe0 net/core/sock.c:1657
inet_create+0x7c7/0x1370 net/ipv4/af_inet.c:321
__sock_create+0x8eb/0xf00 net/socket.c:1420
sock_create net/socket.c:1471 [inline]
__sys_socket+0x1a1/0x600 net/socket.c:1513
__do_sys_socket net/socket.c:1522 [inline]
__se_sys_socket+0x8d/0xb0 net/socket.c:1520
__x64_sys_socket+0x4a/0x70 net/socket.c:1520
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pablo Neira <pablo@netfilter.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wenwen Wang [Sat, 25 Jan 2020 14:33:29 +0000 (14:33 +0000)]
firestream: fix memory leaks
[ Upstream commit
fa865ba183d61c1ec8cbcab8573159c3b72b89a4 ]
In fs_open(), 'vcc' is allocated through kmalloc() and assigned to
'atm_vcc->dev_data.' In the following execution, if an error occurs, e.g.,
there is no more free channel, an error code EBUSY or ENOMEM will be
returned. However, 'vcc' is not deallocated, leading to memory leaks. Note
that, in normal cases where fs_open() returns 0, 'vcc' will be deallocated
in fs_close(). But, if fs_open() fails, there is no guarantee that
fs_close() will be invoked.
To fix this issue, deallocate 'vcc' before the error code is returned.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Palethorpe [Tue, 21 Jan 2020 13:42:58 +0000 (14:42 +0100)]
can, slip: Protect tty->disc_data in write_wakeup and close with RCU
[ Upstream commit
0ace17d56824165c7f4c68785d6b58971db954dd ]
write_wakeup can happen in parallel with close/hangup where tty->disc_data
is set to NULL and the netdevice is freed thus also freeing
disc_data. write_wakeup accesses disc_data so we must prevent close from
freeing the netdev while write_wakeup has a non-NULL view of
tty->disc_data.
We also need to make sure that accesses to disc_data are atomic. Which can
all be done with RCU.
This problem was found by Syzkaller on SLCAN, but the same issue is
reproducible with the SLIP line discipline using an LTP test based on the
Syzkaller reproducer.
A fix which didn't use RCU was posted by Hillf Danton.
Fixes:
661f7fda21b1 ("slip: Fix deadlock in write_wakeup")
Fixes:
a8e83b17536a ("slcan: Port write_wakeup deadlock fix from slip")
Reported-by: syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com
Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tyler Hall <tylerwhall@gmail.com>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 27 Jan 2020 13:46:54 +0000 (14:46 +0100)]
Linux 4.14.168
Finn Thain [Sat, 1 Dec 2018 00:53:10 +0000 (11:53 +1100)]
m68k: Call timer_interrupt() with interrupts disabled
[ Upstream commit
1efdd4bd254311498123a15fa0acd565f454da97 ]
Some platforms execute their timer handler with the interrupt priority
level set below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.
Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual exclusion around the timer interrupt flag access
which is needed later in this series for the clocksource conversion.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1811131407120.2697@nanos.tec.linutronix.de
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabrice Gasnier [Thu, 21 Nov 2019 08:10:49 +0000 (09:10 +0100)]
serial: stm32: fix clearing interrupt error flags
[ Upstream commit
1250ed7114a977cdc2a67a0c09d6cdda63970eb9 ]
The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
simple write to clear TC (transfer complete) flag.
Fixes:
4f01d833fdcd ("serial: stm32: fix rx error handling")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Gurtovoy [Tue, 26 Feb 2019 10:22:11 +0000 (12:22 +0200)]
IB/iser: Fix dma_nents type definition
[ Upstream commit
c1545f1a200f4adc4ef8dd534bf33e2f1aa22c2f ]
The retured value from ib_dma_map_sg saved in dma_nents variable. To avoid
future mismatch between types, define dma_nents as an integer instead of
unsigned.
Fixes:
57b26497fabe ("IB/iser: Pass the correct number of entries for dma mapped SGL")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Israel Rukshin <israelr@mellanox.com>
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andre Przywara [Tue, 19 Nov 2019 12:03:31 +0000 (12:03 +0000)]
arm64: dts: juno: Fix UART frequency
[ Upstream commit
39a1a8941b27c37f79508426e27a2ec29829d66c ]
Older versions of the Juno *SoC* TRM [1] recommended that the UART clock
source should be 7.2738 MHz, whereas the *system* TRM [2] stated a more
correct value of 7.3728 MHz. Somehow the wrong value managed to end up in
our DT.
Doing a prime factorisation, a modulo divide by 115200 and trying
to buy a 7.2738 MHz crystal at your favourite electronics dealer suggest
that the old value was actually a typo. The actual UART clock is driven
by a PLL, configured via a parameter in some board.txt file in the
firmware, which reads 7.37 MHz (sic!).
Fix this to correct the baud rate divisor calculation on the Juno board.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515b.b/DDI0515B_b_juno_arm_development_platform_soc_trm.pdf
[2] http://infocenter.arm.com/help/topic/com.arm.doc.100113_0000_07_en/arm_versatile_express_juno_development_platform_(v2m_juno)_technical_reference_manual_100113_0000_07_en.pdf
Fixes:
71f867ec130e ("arm64: Add Juno board device tree.")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sam Bobroff [Sun, 17 Nov 2019 23:53:53 +0000 (10:53 +1100)]
drm/radeon: fix bad DMA from INTERRUPT_CNTL2
[ Upstream commit
62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]
The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address. This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).
Instead, use the DMA address of the dummy page because it will always
be safe.
Fixes:
d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
Fixes:
25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes:
a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Mon, 18 Nov 2019 07:38:02 +0000 (15:38 +0800)]
dmaengine: ti: edma: fix missed failure handling
[ Upstream commit
340049d453682a9fe8d91fe794dd091730f4bb25 ]
When devm_kcalloc fails, it forgets to call edma_free_slot.
Replace direct return with failure handler to fix it.
Fixes:
1be5336bc7ba ("dmaengine: edma: New device tree binding")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191118073802.28424-1-hslester96@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Navid Emamdoost [Wed, 2 Oct 2019 21:52:37 +0000 (16:52 -0500)]
affs: fix a memory leak in affs_remount
[ Upstream commit
450c3d4166837c496ebce03650c08800991f2150 ]
In affs_remount if data is provided it is duplicated into new_opts. The
allocated memory for new_opts is only released if parse_options fails.
There's a bit of history behind new_options, originally there was
save/replace options on the VFS layer so the 'data' passed must not
change (thus strdup), this got cleaned up in later patches. But not
completely.
There's no reason to do the strdup in cases where the filesystem does
not need to reuse the 'data' again, because strsep would modify it
directly.
Fixes:
c8f33d0bec99 ("affs: kstrdup() memory handling")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
H. Nikolaus Schaller [Thu, 7 Nov 2019 10:30:43 +0000 (11:30 +0100)]
mmc: core: fix wl1251 sdio quirks
[ Upstream commit
16568b4a4f0c34bd35cfadac63303c7af7812764 ]
wl1251 and wl1271 have different vendor id and device id.
So we need to handle both with sdio quirks.
Fixes:
884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
H. Nikolaus Schaller [Thu, 7 Nov 2019 10:30:42 +0000 (11:30 +0100)]
mmc: sdio: fix wl1251 vendor id
[ Upstream commit
e5db673e7fe2f971ec82039a28dc0811c2100e87 ]
v4.11-rc1 did introduce a patch series that rearranged the
sdio quirks into a header file. Unfortunately this did forget
to handle SDIO_VENDOR_ID_TI differently between wl1251 and
wl1271 with the result that although the wl1251 was found on
the sdio bus, the firmware did not load any more and there was
no interface registration.
This patch defines separate constants to be used by sdio quirks
and drivers.
Fixes:
884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Fri, 8 Nov 2019 13:07:46 +0000 (05:07 -0800)]
packet: fix data-race in fanout_flow_is_huge()
[ Upstream commit
b756ad928d98e5ef0b74af7546a6a31a8dadde00 ]
KCSAN reported the following data-race [1]
Adding a couple of READ_ONCE()/WRITE_ONCE() should silence it.
Since the report hinted about multiple cpus using the history
concurrently, I added a test avoiding writing on it if the
victim slot already contains the desired value.
[1]
BUG: KCSAN: data-race in fanout_demux_rollover / fanout_demux_rollover
read to 0xffff8880b01786cc of 4 bytes by task 18921 on cpu 1:
fanout_flow_is_huge net/packet/af_packet.c:1303 [inline]
fanout_demux_rollover+0x33e/0x3f0 net/packet/af_packet.c:1353
packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453
deliver_skb net/core/dev.c:1888 [inline]
dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958
xmit_one net/core/dev.c:3195 [inline]
dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215
__dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792
dev_queue_xmit+0x21/0x30 net/core/dev.c:3825
neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
__ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
__ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0x9f/0xc0 net/socket.c:657
___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
__sys_sendmmsg+0x123/0x350 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
write to 0xffff8880b01786cc of 4 bytes by task 18922 on cpu 0:
fanout_flow_is_huge net/packet/af_packet.c:1306 [inline]
fanout_demux_rollover+0x3a4/0x3f0 net/packet/af_packet.c:1353
packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453
deliver_skb net/core/dev.c:1888 [inline]
dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958
xmit_one net/core/dev.c:3195 [inline]
dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215
__dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792
dev_queue_xmit+0x21/0x30 net/core/dev.c:3825
neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
__ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
__ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0x9f/0xc0 net/socket.c:657
___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
__sys_sendmmsg+0x123/0x350 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 18922 Comm: syz-executor.3 Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Fixes:
3b3a5b0aab5b ("packet: rollover huge flows before small flows")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Tue, 5 Nov 2019 22:11:49 +0000 (14:11 -0800)]
net: neigh: use long type to store jiffies delta
[ Upstream commit
9d027e3a83f39b819e908e4e09084277a2e45e95 ]
A difference of two unsigned long needs long storage.
Fixes:
c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Hemminger [Fri, 1 Nov 2019 23:42:37 +0000 (16:42 -0700)]
hv_netvsc: flag software created hash value
[ Upstream commit
df9f540ca74297a84bafacfa197e9347b20beea5 ]
When the driver needs to create a hash value because it
was not done at higher level, then the hash should be marked
as a software not hardware hash.
Fixes:
f72860afa2e3 ("hv_netvsc: Exclude non-TCP port numbers from vRSS hashing")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Mon, 4 Nov 2019 13:33:50 +0000 (21:33 +0800)]
MIPS: Loongson: Fix return value of loongson_hwmon_init
[ Upstream commit
dece3c2a320b0a6d891da6ff774ab763969b6860 ]
When call function hwmon_device_register failed, use the actual
return value instead of always -ENOMEM.
Fixes:
64f09aa967e1 ("MIPS: Loongson-3: Add CPU Hwmon platform driver")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Dionne [Thu, 21 Nov 2019 15:37:26 +0000 (15:37 +0000)]
afs: Fix large file support
[ Upstream commit
b485275f1aca8a9da37fd35e4fad673935e827da ]
By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
file size to 2GB, enforced by the vfs.
Commit
b9b1f8d5930a ("AFS: write support fixes") added support for the
64-bit fetch and store server operations, but did not change this value.
As a result, attempts to write past the 2G mark result in EFBIG errors:
$ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
dd: error writing 'foo': File too large
Set s_maxbytes to MAX_LFS_FILESIZE.
Fixes:
b9b1f8d5930a ("AFS: write support fixes")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Wahren [Wed, 20 Nov 2019 17:29:13 +0000 (18:29 +0100)]
net: qca_spi: Move reset_count to struct qcaspi
[ Upstream commit
bc19c32904e36548335b35fdce6ce734e20afc0a ]
The reset counter is specific for every QCA700x chip. So move this
into the private driver struct. Otherwise we get unpredictable reset
behavior in setups with multiple QCA700x chips.
Fixes:
291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
Signed-off-by: Stefan Wahren <stefan.wahren@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 18 Oct 2019 16:16:58 +0000 (09:16 -0700)]
net: netem: correct the parent's backlog when corrupted packet was dropped
[ Upstream commit
e0ad032e144731a5928f2d75e91c2064ba1a764c ]
If packet corruption failed we jump to finish_segs and return
NET_XMIT_SUCCESS. Seeing success will make the parent qdisc
increment its backlog, that's incorrect - we need to return
NET_XMIT_DROP.
Fixes:
6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 18 Oct 2019 16:16:57 +0000 (09:16 -0700)]
net: netem: fix error path for corrupted GSO frames
[ Upstream commit
a7fa12d15855904aff1716e1fc723c03ba38c5cc ]
To corrupt a GSO frame we first perform segmentation. We then
proceed using the first segment instead of the full GSO skb and
requeue the rest of the segments as separate packets.
If there are any issues with processing the first segment we
still want to process the rest, therefore we jump to the
finish_segs label.
Commit
177b8007463c ("net: netem: fix backlog accounting for
corrupted GSO frames") started using the pointer to the first
segment in the "rest of segments processing", but as mentioned
above the first segment may had already been freed at this point.
Backlog corrections for parent qdiscs have to be adjusted.
Fixes:
177b8007463c ("net: netem: fix backlog accounting for corrupted GSO frames")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robin Gong [Tue, 24 Sep 2019 09:49:18 +0000 (09:49 +0000)]
dmaengine: imx-sdma: fix size check for sdma script_number
[ Upstream commit
bd73dfabdda280fc5f05bdec79b6721b4b2f035f ]
Illegal memory will be touch if SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(41) exceed the size of structure sdma_script_start_addrs(40),
thus cause memory corrupt such as slob block header so that kernel
trap into while() loop forever in slob_free(). Please refer to below
code piece in imx-sdma.c:
for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i]; /* memory corrupt here */
That issue was brought by commit
a572460be9cf ("dmaengine: imx-sdma: Add
support for version 3 firmware") because SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(38->41 3 scripts added) not align with script number added in
sdma_script_start_addrs(2 scripts).
Fixes:
a572460be9cf ("dmaengine: imx-sdma: Add support for version 3 firmware")
Cc: stable@vger.kernel
Link: https://www.spinics.net/lists/arm-kernel/msg754895.html
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reported-by: Jurgen Lambrecht <J.Lambrecht@TELEVIC.com>
Link: https://lore.kernel.org/r/1569347584-3478-1-git-send-email-yibin.gong@nxp.com
[vkoul: update the patch title]
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeffrey Hugo [Fri, 11 Oct 2019 13:39:39 +0000 (06:39 -0700)]
drm/msm/dsi: Implement reset correctly
[ Upstream commit
78e31c42261779a01bc73472d0f65f15378e9de3 ]
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP. This is because the reset
logic is not correct per the hardware documentation.
The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.
wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes. Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.
Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.
Fixes:
a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li <hali@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Sean Paul <sean@poorly.run>
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 9 Oct 2019 22:10:15 +0000 (15:10 -0700)]
tcp: annotate lockless access to tcp_memory_pressure
[ Upstream commit
1f142c17d19a5618d5a633195a46f2c8be9bf232 ]
tcp_memory_pressure is read without holding any lock,
and its value could be changed on other cpus.
Use READ_ONCE() to annotate these lockless reads.
The write side is already using atomic ops.
Fixes:
b8da51ebb1aa ("tcp: introduce tcp_under_memory_pressure()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 9 Oct 2019 21:51:20 +0000 (14:51 -0700)]
net: add {READ|WRITE}_ONCE() annotations on ->rskq_accept_head
[ Upstream commit
60b173ca3d1cd1782bd0096dc17298ec242f6fb1 ]
reqsk_queue_empty() is called from inet_csk_listen_poll() while
other cpus might write ->rskq_accept_head value.
Use {READ|WRITE}_ONCE() to avoid compiler tricks
and potential KCSAN splats.
Fixes:
fff1f3001cc5 ("tcp: add a spinlock to protect struct request_sock_queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 9 Oct 2019 19:55:53 +0000 (12:55 -0700)]
net: avoid possible false sharing in sk_leave_memory_pressure()
[ Upstream commit
503978aca46124cd714703e180b9c8292ba50ba7 ]
As mentioned in https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE#it-may-improve-performance
a C compiler can legally transform :
if (memory_pressure && *memory_pressure)
*memory_pressure = 0;
to :
if (memory_pressure)
*memory_pressure = 0;
Fixes:
0604475119de ("tcp: add TCPMemoryPressuresChrono counter")
Fixes:
180d8cd942ce ("foundations of per-cgroup memory pressure controlling.")
Fixes:
3ab224be6d69 ("[NET] CORE: Introducing new memory accounting interface.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Wed, 9 Oct 2019 03:10:52 +0000 (11:10 +0800)]
act_mirred: Fix mirred_init_module error handling
[ Upstream commit
11c9a7d38af524217efb7a176ad322b97ac2f163 ]
If tcf_register_action failed, mirred_device_notifier
should be unregistered.
Fixes:
3b87956ea645 ("net sched: fix race in mirred device removal")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antonio Borneo [Mon, 7 Oct 2019 15:43:04 +0000 (17:43 +0200)]
net: stmmac: fix length of PTP clock's name string
[ Upstream commit
5da202c88f8c355ad79bc2e8eb582e6d433060e7 ]
The field "name" in struct ptp_clock_info has a fixed size of 16
chars and is used as zero terminated string by clock_name_show()
in drivers/ptp/ptp_sysfs.c
The current initialization value requires 17 chars to fit also the
null termination, and this causes overflow to the next bytes in
the struct when the string is read as null terminated:
hexdump -C /sys/class/ptp/ptp0/clock_name
00000000 73 74 6d 6d 61 63 5f 70 74 70 5f 63 6c 6f 63 6b |stmmac_ptp_clock|
00000010 a0 ac b9 03 0a |.....|
where the extra 4 bytes (excluding the newline) after the string
represent the integer 0x03b9aca0 =
62500000 assigned to the field
"max_adj" that follows "name" in the same struct.
There is no strict requirement for the "name" content and in the
comment in ptp_clock_kernel.h it's reported it should just be 'A
short "friendly name" to identify the clock'.
Replace it with "stmmac ptp".
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Fixes:
92ba6888510c ("stmmac: add the support for PTP hw clock driver")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Biggers [Sun, 6 Oct 2019 21:24:27 +0000 (14:24 -0700)]
llc: fix sk_buff refcounting in llc_conn_state_process()
[ Upstream commit
36453c852816f19947ca482a595dffdd2efa4965 ]
If llc_conn_state_process() sees that llc_conn_service() put the skb on
a list, it will drop one fewer references to it. This is wrong because
the current behavior is that llc_conn_service() never consumes a
reference to the skb.
The code also makes the number of skb references being dropped
conditional on which of ind_prim and cfm_prim are nonzero, yet neither
of these affects how many references are *acquired*. So there is extra
code that tries to fix this up by sometimes taking another reference.
Remove the unnecessary/broken refcounting logic and instead just add an
skb_get() before the only two places where an extra reference is
actually consumed.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Biggers [Sun, 6 Oct 2019 21:24:26 +0000 (14:24 -0700)]
llc: fix another potential sk_buff leak in llc_ui_sendmsg()
[ Upstream commit
fc8d5db10cbe1338a52ebc74e7feab9276721774 ]
All callers of llc_conn_state_process() except llc_build_and_send_pkt()
(via llc_ui_sendmsg() -> llc_ui_send_data()) assume that it always
consumes a reference to the skb. Fix this caller to do the same.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Fri, 4 Oct 2019 12:37:05 +0000 (15:37 +0300)]
mac80211: accept deauth frames in IBSS mode
[ Upstream commit
95697f9907bfe3eab0ef20265a766b22e27dde64 ]
We can process deauth frames and all, but we drop them very
early in the RX path today - this could never have worked.
Fixes:
2cc59e784b54 ("mac80211: reply to AUTH with DEAUTH if sta allocation fails in IBSS")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20191004123706.15768-2-luca@coelho.fi
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jose Abreu [Sun, 6 Oct 2019 11:08:56 +0000 (13:08 +0200)]
net: stmmac: gmac4+: Not all Unicast addresses may be available
[ Upstream commit
25683bab09a70542b9f8e3e28f79b3369e56701f ]
Some setups may not have all Unicast addresses filters available. Check
the number of available filters before trying to setup it.
Fixes:
477286b53f55 ("stmmac: add GMAC4 core support")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Thu, 3 Oct 2019 11:57:29 +0000 (13:57 +0200)]
nvme: retain split access workaround for capability reads
[ Upstream commit
3a8ecc935efabdad106b5e06d07b150c394b4465 ]
Commit
7fd8930f26be4
"nvme: add a common helper to read Identify Controller data"
has re-introduced an issue that we have attempted to work around in the
past, in commit
a310acd7a7ea ("NVMe: use split lo_hi_{read,write}q").
The problem is that some PCIe NVMe controllers do not implement 64-bit
outbound accesses correctly, which is why the commit above switched
to using lo_hi_[read|write]q for all 64-bit BAR accesses occuring in
the code.
In the mean time, the NVMe subsystem has been refactored, and now calls
into the PCIe support layer for NVMe via a .reg_read64() method, which
fails to use lo_hi_readq(), and thus reintroduces the problem that the
workaround above aimed to address.
Given that, at the moment, .reg_read64() is only used to read the
capability register [which is known to tolerate split reads], let's
switch .reg_read64() to lo_hi_readq() as well.
This fixes a boot issue on some ARM boxes with NVMe behind a Synopsys
DesignWare PCIe host controller.
Fixes:
7fd8930f26be4 ("nvme: add a common helper to read Identify Controller data")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 11:05:54 +0000 (14:05 +0300)]
net: ethernet: stmmac: Fix signedness bug in ipq806x_gmac_of_parse()
[ Upstream commit
231042181dc9d6122c6faba64e99ccb25f13cc6c ]
The "gmac->phy_mode" variable is an enum and in this context GCC will
treat it as an unsigned int so the error handling will never be
triggered.
Fixes:
b1c17215d718 ("stmmac: add ipq806x glue layer")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>