2020-08-10 15:31:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/48] 4.19.139-rc1 review

This is the start of the stable review cycle for the 4.19.139 release.
There are 48 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 12 Aug 2020 15:17:47 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.139-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.19.139-rc1

Eric Biggers <[email protected]>
Smack: fix use-after-free in smk_write_relabel_self()

Martyna Szapar <[email protected]>
i40e: Memory leak in i40e_config_iwarp_qvlist

Martyna Szapar <[email protected]>
i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

Grzegorz Siwik <[email protected]>
i40e: Wrong truncation from u16 to u8

Sergey Nemov <[email protected]>
i40e: add num_vectors checker in iwarp handler

David Howells <[email protected]>
rxrpc: Fix race between recvmsg and sendmsg on immediate call failure

Willem de Bruijn <[email protected]>
selftests/net: relax cpu affinity requirement in msg_zerocopy test

Hangbin Liu <[email protected]>
Revert "vxlan: fix tos value before xmit"

Peilin Ye <[email protected]>
openvswitch: Prevent kernel-infoleak in ovs_ct_put_key()

Xin Long <[email protected]>
net: thunderx: use spin_lock_bh in nicvf_set_rx_mode_task()

Lorenzo Bianconi <[email protected]>
net: gre: recompute gre csum for sctp over gre tunnels

Stephen Hemminger <[email protected]>
hv_netvsc: do not use VF device if link is down

Johan Hovold <[email protected]>
net: lan78xx: replace bogus endpoint lookup

Ido Schimmel <[email protected]>
vxlan: Ensure FDB dump is performed under RCU

Landen Chao <[email protected]>
net: ethernet: mtk_eth_soc: fix MTU warnings

Cong Wang <[email protected]>
ipv6: fix memory leaks on IPV6_ADDRFORM path

Ido Schimmel <[email protected]>
ipv4: Silence suspicious RCU usage warning

Frank van der Linden <[email protected]>
xattr: break delegations in {set,remove}xattr

Dexuan Cui <[email protected]>
Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)

Philippe Duplessis-Guindon <[email protected]>
tools lib traceevent: Fix memory leak in process_dynamic_array_len

Xin Xiong <[email protected]>
atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent

Francesco Ruggeri <[email protected]>
igb: reinit_locked() should be called with rtnl_lock

Julian Squires <[email protected]>
cfg80211: check vendor command doit pointer before use

Qiushi Wu <[email protected]>
firmware: Fix a reference count leak.

Rustam Kovhaev <[email protected]>
usb: hso: check for return value in hso_serial_common_create()

Wolfram Sang <[email protected]>
i2c: slave: add sanity check when unregistering

Wolfram Sang <[email protected]>
i2c: slave: improve sanity check when registering

Ben Skeggs <[email protected]>
drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure

Ben Skeggs <[email protected]>
drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason

Christoph Hellwig <[email protected]>
net/9p: validate fds in p9_fd_open

Johan Hovold <[email protected]>
leds: 88pm860x: fix use-after-free on unbind

Johan Hovold <[email protected]>
leds: lm3533: fix use-after-free on unbind

Johan Hovold <[email protected]>
leds: da903x: fix use-after-free on unbind

Johan Hovold <[email protected]>
leds: wm831x-status: fix use-after-free on unbind

Greg Kroah-Hartman <[email protected]>
mtd: properly check all write ioctls for permissions

Yunhai Zhang <[email protected]>
vgacon: Fix for missing check in scrollback handling

Jann Horn <[email protected]>
binder: Prevent context manager from incrementing ref 0

Adam Ford <[email protected]>
omapfb: dss: Fix max fclk divider for omap36xx

Peilin Ye <[email protected]>
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt()

Peilin Ye <[email protected]>
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt()

Peilin Ye <[email protected]>
Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()

Suren Baghdasaryan <[email protected]>
staging: android: ashmem: Fix lockdep warning for write operation

Takashi Iwai <[email protected]>
ALSA: seq: oss: Serialize ioctls

Hui Wang <[email protected]>
Revert "ALSA: hda: call runtime_allow() for all hda controllers"

Forest Crossman <[email protected]>
usb: xhci: Fix ASMedia ASM1142 DMA addressing

Forest Crossman <[email protected]>
usb: xhci: define IDs for various ASMedia host controllers

Greg Kroah-Hartman <[email protected]>
USB: iowarrior: fix up report size handling for some devices

Erik Ekman <[email protected]>
USB: serial: qcserial: add EM7305 QDL product ID


-------------

Diffstat:

Makefile | 4 +-
drivers/android/binder.c | 15 ++-
drivers/atm/atmtcp.c | 10 +-
drivers/firmware/qemu_fw_cfg.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +-
drivers/hv/channel_mgmt.c | 21 ++--
drivers/hv/vmbus_drv.c | 4 +
drivers/i2c/i2c-core-slave.c | 7 +-
drivers/leds/leds-88pm860x.c | 14 ++-
drivers/leds/leds-da903x.c | 14 ++-
drivers/leds/leds-lm3533.c | 12 ++-
drivers/leds/leds-wm831x-status.c | 14 ++-
drivers/mtd/mtdchar.c | 56 ++++++++--
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 4 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 51 ++++++---
drivers/net/ethernet/intel/igb/igb_main.c | 9 ++
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +
drivers/net/hyperv/netvsc_drv.c | 7 +-
drivers/net/usb/hso.c | 5 +-
drivers/net/usb/lan78xx.c | 117 ++++++---------------
drivers/net/vxlan.c | 10 +-
drivers/staging/android/ashmem.c | 12 +++
drivers/usb/host/xhci-pci.c | 10 +-
drivers/usb/misc/iowarrior.c | 35 ++++--
drivers/usb/serial/qcserial.c | 1 +
drivers/video/console/vgacon.c | 4 +
drivers/video/fbdev/omap2/omapfb/dss/dss.c | 2 +-
fs/xattr.c | 84 +++++++++++++--
include/linux/hyperv.h | 2 +
include/linux/xattr.h | 2 +
include/net/addrconf.h | 1 +
net/9p/trans_fd.c | 24 +++--
net/bluetooth/hci_event.c | 11 +-
net/ipv4/fib_trie.c | 2 +-
net/ipv4/gre_offload.c | 13 ++-
net/ipv6/anycast.c | 17 ++-
net/ipv6/ipv6_sockglue.c | 1 +
net/openvswitch/conntrack.c | 38 +++----
net/rxrpc/call_object.c | 27 +++--
net/rxrpc/conn_object.c | 8 +-
net/rxrpc/recvmsg.c | 2 +-
net/rxrpc/sendmsg.c | 3 +
net/wireless/nl80211.c | 6 +-
security/smack/smackfs.c | 13 ++-
sound/core/seq/oss/seq_oss.c | 8 +-
sound/pci/hda/hda_intel.c | 1 -
tools/lib/traceevent/event-parse.c | 1 +
tools/testing/selftests/net/msg_zerocopy.c | 5 +-
48 files changed, 488 insertions(+), 231 deletions(-)



2020-08-10 15:31:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 32/48] ipv4: Silence suspicious RCU usage warning

From: Ido Schimmel <[email protected]>

[ Upstream commit 83f3522860f702748143e022f1a546547314c715 ]

fib_trie_unmerge() is called with RTNL held, but not from an RCU
read-side critical section. This leads to the following warning [1] when
the FIB alias list in a leaf is traversed with
hlist_for_each_entry_rcu().

Since the function is always called with RTNL held and since
modification of the list is protected by RTNL, simply use
hlist_for_each_entry() and silence the warning.

[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
-----------------------------
net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/164:
#0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0

stack backtrace:
CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
fib_trie_unmerge+0x608/0xdb0
fib_unmerge+0x44/0x360
fib4_rule_configure+0xc8/0xad0
fib_nl_newrule+0x37a/0x1dd0
rtnetlink_rcv_msg+0x4f7/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
____sys_sendmsg+0x879/0xa00
___sys_sendmsg+0x122/0x190
__sys_sendmsg+0x103/0x1d0
__x64_sys_sendmsg+0x7d/0xb0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc80a234e97
Code: Bad RIP value.
RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020

Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/fib_trie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1749,7 +1749,7 @@ struct fib_table *fib_trie_unmerge(struc
while ((l = leaf_walk_rcu(&tp, key)) != NULL) {
struct key_vector *local_l = NULL, *local_tp;

- hlist_for_each_entry_rcu(fa, &l->leaf, fa_list) {
+ hlist_for_each_entry(fa, &l->leaf, fa_list) {
struct fib_alias *new_fa;

if (local_tb->tb_id != fa->tb_id)


2020-08-10 15:31:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 40/48] openvswitch: Prevent kernel-infoleak in ovs_ct_put_key()

From: Peilin Ye <[email protected]>

[ Upstream commit 9aba6c5b49254d5bee927d81593ed4429e91d4ae ]

ovs_ct_put_key() is potentially copying uninitialized kernel stack memory
into socket buffers, since the compiler may leave a 3-byte hole at the end
of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix
it by initializing `orig` with memset().

Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.")
Suggested-by: Dan Carpenter <[email protected]>
Signed-off-by: Peilin Ye <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/openvswitch/conntrack.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)

--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -283,10 +283,6 @@ void ovs_ct_fill_key(const struct sk_buf
ovs_ct_update_key(skb, NULL, key, false, false);
}

-#define IN6_ADDR_INITIALIZER(ADDR) \
- { (ADDR).s6_addr32[0], (ADDR).s6_addr32[1], \
- (ADDR).s6_addr32[2], (ADDR).s6_addr32[3] }
-
int ovs_ct_put_key(const struct sw_flow_key *swkey,
const struct sw_flow_key *output, struct sk_buff *skb)
{
@@ -308,24 +304,30 @@ int ovs_ct_put_key(const struct sw_flow_

if (swkey->ct_orig_proto) {
if (swkey->eth.type == htons(ETH_P_IP)) {
- struct ovs_key_ct_tuple_ipv4 orig = {
- output->ipv4.ct_orig.src,
- output->ipv4.ct_orig.dst,
- output->ct.orig_tp.src,
- output->ct.orig_tp.dst,
- output->ct_orig_proto,
- };
+ struct ovs_key_ct_tuple_ipv4 orig;
+
+ memset(&orig, 0, sizeof(orig));
+ orig.ipv4_src = output->ipv4.ct_orig.src;
+ orig.ipv4_dst = output->ipv4.ct_orig.dst;
+ orig.src_port = output->ct.orig_tp.src;
+ orig.dst_port = output->ct.orig_tp.dst;
+ orig.ipv4_proto = output->ct_orig_proto;
+
if (nla_put(skb, OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4,
sizeof(orig), &orig))
return -EMSGSIZE;
} else if (swkey->eth.type == htons(ETH_P_IPV6)) {
- struct ovs_key_ct_tuple_ipv6 orig = {
- IN6_ADDR_INITIALIZER(output->ipv6.ct_orig.src),
- IN6_ADDR_INITIALIZER(output->ipv6.ct_orig.dst),
- output->ct.orig_tp.src,
- output->ct.orig_tp.dst,
- output->ct_orig_proto,
- };
+ struct ovs_key_ct_tuple_ipv6 orig;
+
+ memset(&orig, 0, sizeof(orig));
+ memcpy(orig.ipv6_src, output->ipv6.ct_orig.src.s6_addr32,
+ sizeof(orig.ipv6_src));
+ memcpy(orig.ipv6_dst, output->ipv6.ct_orig.dst.s6_addr32,
+ sizeof(orig.ipv6_dst));
+ orig.src_port = output->ct.orig_tp.src;
+ orig.dst_port = output->ct.orig_tp.dst;
+ orig.ipv6_proto = output->ct_orig_proto;
+
if (nla_put(skb, OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6,
sizeof(orig), &orig))
return -EMSGSIZE;


2020-08-10 15:31:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 45/48] i40e: Wrong truncation from u16 to u8

From: Grzegorz Siwik <[email protected]>

[ Upstream commit c004804dceee9ca384d97d9857ea2e2795c2651d ]

In this patch fixed wrong truncation method from u16 to u8 during
validation.

It was changed by changing u8 to u32 parameter in method declaration
and arguments were changed to u32.

Fixes: 5c3c48ac6bf56 ("i40e: implement virtual device interface")
Signed-off-by: Grzegorz Siwik <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -196,7 +196,7 @@ static inline bool i40e_vc_isvalid_queue
*
* check for the valid vector id
**/
-static inline bool i40e_vc_isvalid_vector_id(struct i40e_vf *vf, u8 vector_id)
+static inline bool i40e_vc_isvalid_vector_id(struct i40e_vf *vf, u32 vector_id)
{
struct i40e_pf *pf = vf->pf;



2020-08-10 15:31:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 46/48] i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

From: Martyna Szapar <[email protected]>

[ Upstream commit 24474f2709af6729b9b1da1c5e160ab62e25e3a4 ]

Fixed possible memory leak in i40e_vc_add_cloud_filter function:
cfilter is being allocated and in some error conditions
the function returns without freeing the memory.

Fix of integer truncation from u16 (type of queue_id value) to u8
when calling i40e_vc_isvalid_queue_id function.

Fixes: e284fc280473b ("i40e: Add and delete cloud filter")
Signed-off-by: Martyna Szapar <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_i
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);
@@ -3345,7 +3345,7 @@ static int i40e_vc_add_cloud_filter(stru

if (!test_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states)) {
aq_ret = I40E_ERR_PARAM;
- goto err;
+ goto err_out;
}

if (!vf->adq_enabled) {
@@ -3353,15 +3353,15 @@ static int i40e_vc_add_cloud_filter(stru
"VF %d: ADq is not enabled, can't apply cloud filter\n",
vf->vf_id);
aq_ret = I40E_ERR_PARAM;
- goto err;
+ goto err_out;
}

if (i40e_validate_cloud_filter(vf, vcf)) {
dev_info(&pf->pdev->dev,
"VF %d: Invalid input/s, can't apply cloud filter\n",
vf->vf_id);
- aq_ret = I40E_ERR_PARAM;
- goto err;
+ aq_ret = I40E_ERR_PARAM;
+ goto err_out;
}

cfilter = kzalloc(sizeof(*cfilter), GFP_KERNEL);
@@ -3422,13 +3422,17 @@ static int i40e_vc_add_cloud_filter(stru
"VF %d: Failed to add cloud filter, err %s aq_err %s\n",
vf->vf_id, i40e_stat_str(&pf->hw, ret),
i40e_aq_str(&pf->hw, pf->hw.aq.asq_last_status));
- goto err;
+ goto err_free;
}

INIT_HLIST_NODE(&cfilter->cloud_node);
hlist_add_head(&cfilter->cloud_node, &vf->cloud_filter_list);
+ /* release the pointer passing it to the collection */
+ cfilter = NULL;
vf->num_cloud_filters++;
-err:
+err_free:
+ kfree(cfilter);
+err_out:
return i40e_vc_send_resp_to_vf(vf, VIRTCHNL_OP_ADD_CLOUD_FILTER,
aq_ret);
}


2020-08-10 15:32:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 48/48] Smack: fix use-after-free in smk_write_relabel_self()

From: Eric Biggers <[email protected]>

commit beb4ee6770a89646659e6a2178538d2b13e2654e upstream.

smk_write_relabel_self() frees memory from the task's credentials with
no locking, which can easily cause a use-after-free because multiple
tasks can share the same credentials structure.

Fix this by using prepare_creds() and commit_creds() to correctly modify
the task's credentials.

Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self":

#include <fcntl.h>
#include <pthread.h>
#include <unistd.h>

static void *thrproc(void *arg)
{
int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY);
for (;;) write(fd, "foo", 3);
}

int main()
{
pthread_t t;
pthread_create(&t, NULL, thrproc, NULL);
thrproc(NULL);
}

Reported-by: [email protected]
Fixes: 38416e53936e ("Smack: limited capability for changing process label")
Cc: <[email protected]> # v4.4+
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Casey Schaufler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
security/smack/smackfs.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)

--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -2746,7 +2746,6 @@ static int smk_open_relabel_self(struct
static ssize_t smk_write_relabel_self(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
- struct task_smack *tsp = current_security();
char *data;
int rc;
LIST_HEAD(list_tmp);
@@ -2771,11 +2770,21 @@ static ssize_t smk_write_relabel_self(st
kfree(data);

if (!rc || (rc == -EINVAL && list_empty(&list_tmp))) {
+ struct cred *new;
+ struct task_smack *tsp;
+
+ new = prepare_creds();
+ if (!new) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ tsp = new->security;
smk_destroy_label_list(&tsp->smk_relabel);
list_splice(&list_tmp, &tsp->smk_relabel);
+ commit_creds(new);
return count;
}
-
+out:
smk_destroy_label_list(&list_tmp);
return rc;
}


2020-08-10 15:32:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 26/48] cfg80211: check vendor command doit pointer before use

From: Julian Squires <[email protected]>

[ Upstream commit 4052d3d2e8f47a15053320bbcbe365d15610437d ]

In the case where a vendor command does not implement doit, and has no
flags set, doit would not be validated and a NULL pointer dereference
would occur, for example when invoking the vendor command via iw.

I encountered this while developing new vendor commands. Perhaps in
practice it is advisable to always implement doit along with dumpit,
but it seems reasonable to me to always check doit anyway, not just
when NEED_WDEV.

Signed-off-by: Julian Squires <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/wireless/nl80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 0221849b72180..996b68b48a878 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12392,13 +12392,13 @@ static int nl80211_vendor_cmd(struct sk_buff *skb, struct genl_info *info)
if (!wdev_running(wdev))
return -ENETDOWN;
}
-
- if (!vcmd->doit)
- return -EOPNOTSUPP;
} else {
wdev = NULL;
}

+ if (!vcmd->doit)
+ return -EOPNOTSUPP;
+
if (info->attrs[NL80211_ATTR_VENDOR_DATA]) {
data = nla_data(info->attrs[NL80211_ATTR_VENDOR_DATA]);
len = nla_len(info->attrs[NL80211_ATTR_VENDOR_DATA]);
--
2.25.1



2020-08-10 15:32:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 29/48] tools lib traceevent: Fix memory leak in process_dynamic_array_len

From: Philippe Duplessis-Guindon <[email protected]>

[ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]

I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:

Direct leak of 28 byte(s) in 4 object(s) allocated from:
#0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.

Free the token variable before calling read_token in order to plug the
leak.

Signed-off-by: Philippe Duplessis-Guindon <[email protected]>
Reviewed-by: Steven Rostedt (VMware) <[email protected]>
Link: https://lore.kernel.org/linux-trace-devel/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/lib/traceevent/event-parse.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index 382e476629fb1..c0fcc8af2a3ef 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2766,6 +2766,7 @@ process_dynamic_array_len(struct event_format *event, struct print_arg *arg,
if (read_expected(EVENT_DELIM, ")") < 0)
goto out_err;

+ free_token(token);
type = read_token(&token);
*tok = token;

--
2.25.1



2020-08-10 15:32:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 38/48] net: gre: recompute gre csum for sctp over gre tunnels

From: Lorenzo Bianconi <[email protected]>

[ Upstream commit 622e32b7d4a6492cf5c1f759ef833f817418f7b3 ]

The GRE tunnel can be used to transport traffic that does not rely on a
Internet checksum (e.g. SCTP). The issue can be triggered creating a GRE
or GRETAP tunnel and transmitting SCTP traffic ontop of it where CRC
offload has been disabled. In order to fix the issue we need to
recompute the GRE csum in gre_gso_segment() not relying on the inner
checksum.
The issue is still present when we have the CRC offload enabled.
In this case we need to disable the CRC offload if we require GRE
checksum since otherwise skb_checksum() will report a wrong value.

Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Reviewed-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/gre_offload.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)

--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -19,12 +19,12 @@ static struct sk_buff *gre_gso_segment(s
netdev_features_t features)
{
int tnl_hlen = skb_inner_mac_header(skb) - skb_transport_header(skb);
+ bool need_csum, need_recompute_csum, gso_partial;
struct sk_buff *segs = ERR_PTR(-EINVAL);
u16 mac_offset = skb->mac_header;
__be16 protocol = skb->protocol;
u16 mac_len = skb->mac_len;
int gre_offset, outer_hlen;
- bool need_csum, gso_partial;

if (!skb->encapsulation)
goto out;
@@ -45,6 +45,7 @@ static struct sk_buff *gre_gso_segment(s
skb->protocol = skb->inner_protocol;

need_csum = !!(skb_shinfo(skb)->gso_type & SKB_GSO_GRE_CSUM);
+ need_recompute_csum = skb->csum_not_inet;
skb->encap_hdr_csum = need_csum;

features &= skb->dev->hw_enc_features;
@@ -102,7 +103,15 @@ static struct sk_buff *gre_gso_segment(s
}

*(pcsum + 1) = 0;
- *pcsum = gso_make_checksum(skb, 0);
+ if (need_recompute_csum && !skb_is_gso(skb)) {
+ __wsum csum;
+
+ csum = skb_checksum(skb, gre_offset,
+ skb->len - gre_offset, 0);
+ *pcsum = csum_fold(csum);
+ } else {
+ *pcsum = gso_make_checksum(skb, 0);
+ }
} while ((skb = skb->next));
out:
return segs;


2020-08-10 15:32:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 31/48] xattr: break delegations in {set,remove}xattr

From: Frank van der Linden <[email protected]>

commit 08b5d5014a27e717826999ad20e394a8811aae92 upstream.

set/removexattr on an exported filesystem should break NFS delegations.
This is true in general, but also for the upcoming support for
RFC 8726 (NFSv4 extended attribute support). Make sure that they do.

Additionally, they need to grow a _locked variant, since callers might
call this with i_rwsem held (like the NFS server code).

Cc: [email protected] # v4.9+
Cc: [email protected]
Cc: Al Viro <[email protected]>
Signed-off-by: Frank van der Linden <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/xattr.c | 84 +++++++++++++++++++++++++++++++++++++++++++++-----
include/linux/xattr.h | 2 +
2 files changed, 79 insertions(+), 7 deletions(-)

--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -203,10 +203,22 @@ int __vfs_setxattr_noperm(struct dentry
return error;
}

-
+/**
+ * __vfs_setxattr_locked: set an extended attribute while holding the inode
+ * lock
+ *
+ * @dentry - object to perform setxattr on
+ * @name - xattr name to set
+ * @value - value to set @name to
+ * @size - size of @value
+ * @flags - flags to pass into filesystem operations
+ * @delegated_inode - on return, will contain an inode pointer that
+ * a delegation was broken on, NULL if none.
+ */
int
-vfs_setxattr(struct dentry *dentry, const char *name, const void *value,
- size_t size, int flags)
+__vfs_setxattr_locked(struct dentry *dentry, const char *name,
+ const void *value, size_t size, int flags,
+ struct inode **delegated_inode)
{
struct inode *inode = dentry->d_inode;
int error;
@@ -215,15 +227,40 @@ vfs_setxattr(struct dentry *dentry, cons
if (error)
return error;

- inode_lock(inode);
error = security_inode_setxattr(dentry, name, value, size, flags);
if (error)
goto out;

+ error = try_break_deleg(inode, delegated_inode);
+ if (error)
+ goto out;
+
error = __vfs_setxattr_noperm(dentry, name, value, size, flags);

out:
+ return error;
+}
+EXPORT_SYMBOL_GPL(__vfs_setxattr_locked);
+
+int
+vfs_setxattr(struct dentry *dentry, const char *name, const void *value,
+ size_t size, int flags)
+{
+ struct inode *inode = dentry->d_inode;
+ struct inode *delegated_inode = NULL;
+ int error;
+
+retry_deleg:
+ inode_lock(inode);
+ error = __vfs_setxattr_locked(dentry, name, value, size, flags,
+ &delegated_inode);
inode_unlock(inode);
+
+ if (delegated_inode) {
+ error = break_deleg_wait(&delegated_inode);
+ if (!error)
+ goto retry_deleg;
+ }
return error;
}
EXPORT_SYMBOL_GPL(vfs_setxattr);
@@ -377,8 +414,18 @@ __vfs_removexattr(struct dentry *dentry,
}
EXPORT_SYMBOL(__vfs_removexattr);

+/**
+ * __vfs_removexattr_locked: set an extended attribute while holding the inode
+ * lock
+ *
+ * @dentry - object to perform setxattr on
+ * @name - name of xattr to remove
+ * @delegated_inode - on return, will contain an inode pointer that
+ * a delegation was broken on, NULL if none.
+ */
int
-vfs_removexattr(struct dentry *dentry, const char *name)
+__vfs_removexattr_locked(struct dentry *dentry, const char *name,
+ struct inode **delegated_inode)
{
struct inode *inode = dentry->d_inode;
int error;
@@ -387,11 +434,14 @@ vfs_removexattr(struct dentry *dentry, c
if (error)
return error;

- inode_lock(inode);
error = security_inode_removexattr(dentry, name);
if (error)
goto out;

+ error = try_break_deleg(inode, delegated_inode);
+ if (error)
+ goto out;
+
error = __vfs_removexattr(dentry, name);

if (!error) {
@@ -400,12 +450,32 @@ vfs_removexattr(struct dentry *dentry, c
}

out:
+ return error;
+}
+EXPORT_SYMBOL_GPL(__vfs_removexattr_locked);
+
+int
+vfs_removexattr(struct dentry *dentry, const char *name)
+{
+ struct inode *inode = dentry->d_inode;
+ struct inode *delegated_inode = NULL;
+ int error;
+
+retry_deleg:
+ inode_lock(inode);
+ error = __vfs_removexattr_locked(dentry, name, &delegated_inode);
inode_unlock(inode);
+
+ if (delegated_inode) {
+ error = break_deleg_wait(&delegated_inode);
+ if (!error)
+ goto retry_deleg;
+ }
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_removexattr);

-
/*
* Extended attribute SET operations
*/
--- a/include/linux/xattr.h
+++ b/include/linux/xattr.h
@@ -51,8 +51,10 @@ ssize_t vfs_getxattr(struct dentry *, co
ssize_t vfs_listxattr(struct dentry *d, char *list, size_t size);
int __vfs_setxattr(struct dentry *, struct inode *, const char *, const void *, size_t, int);
int __vfs_setxattr_noperm(struct dentry *, const char *, const void *, size_t, int);
+int __vfs_setxattr_locked(struct dentry *, const char *, const void *, size_t, int, struct inode **);
int vfs_setxattr(struct dentry *, const char *, const void *, size_t, int);
int __vfs_removexattr(struct dentry *, const char *);
+int __vfs_removexattr_locked(struct dentry *, const char *, struct inode **);
int vfs_removexattr(struct dentry *, const char *);

ssize_t generic_listxattr(struct dentry *dentry, char *buffer, size_t buffer_size);


2020-08-10 15:32:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 17/48] leds: lm3533: fix use-after-free on unbind

From: Johan Hovold <[email protected]>

commit d584221e683bbd173738603b83a315f27d27d043 upstream.

Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.

Fixes: 50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable <[email protected]> # 4.6
Cc: Amitoj Kaur Chawla <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/leds/leds-lm3533.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/leds/leds-lm3533.c
+++ b/drivers/leds/leds-lm3533.c
@@ -698,7 +698,7 @@ static int lm3533_led_probe(struct platf

platform_set_drvdata(pdev, led);

- ret = devm_led_classdev_register(pdev->dev.parent, &led->cdev);
+ ret = led_classdev_register(pdev->dev.parent, &led->cdev);
if (ret) {
dev_err(&pdev->dev, "failed to register LED %d\n", pdev->id);
return ret;
@@ -708,13 +708,18 @@ static int lm3533_led_probe(struct platf

ret = lm3533_led_setup(led, pdata);
if (ret)
- return ret;
+ goto err_deregister;

ret = lm3533_ctrlbank_enable(&led->cb);
if (ret)
- return ret;
+ goto err_deregister;

return 0;
+
+err_deregister:
+ led_classdev_unregister(&led->cdev);
+
+ return ret;
}

static int lm3533_led_remove(struct platform_device *pdev)
@@ -724,6 +729,7 @@ static int lm3533_led_remove(struct plat
dev_dbg(&pdev->dev, "%s\n", __func__);

lm3533_ctrlbank_disable(&led->cb);
+ led_classdev_unregister(&led->cdev);

return 0;
}


2020-08-10 15:32:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 14/48] mtd: properly check all write ioctls for permissions

From: Greg Kroah-Hartman <[email protected]>

commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream.

When doing a "write" ioctl call, properly check that we have permissions
to do so before copying anything from userspace or anything else so we
can "fail fast". This includes also covering the MEMWRITE ioctl which
previously missed checking for this.

Cc: Miquel Raynal <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Vignesh Raghavendra <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[rw: Fixed locking issue]
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mtd/mtdchar.c | 56 +++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 47 insertions(+), 9 deletions(-)

--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -368,9 +368,6 @@ static int mtdchar_writeoob(struct file
uint32_t retlen;
int ret = 0;

- if (!(file->f_mode & FMODE_WRITE))
- return -EPERM;
-
if (length > 4096)
return -EINVAL;

@@ -655,6 +652,48 @@ static int mtdchar_ioctl(struct file *fi

pr_debug("MTD_ioctl\n");

+ /*
+ * Check the file mode to require "dangerous" commands to have write
+ * permissions.
+ */
+ switch (cmd) {
+ /* "safe" commands */
+ case MEMGETREGIONCOUNT:
+ case MEMGETREGIONINFO:
+ case MEMGETINFO:
+ case MEMREADOOB:
+ case MEMREADOOB64:
+ case MEMLOCK:
+ case MEMUNLOCK:
+ case MEMISLOCKED:
+ case MEMGETOOBSEL:
+ case MEMGETBADBLOCK:
+ case MEMSETBADBLOCK:
+ case OTPSELECT:
+ case OTPGETREGIONCOUNT:
+ case OTPGETREGIONINFO:
+ case OTPLOCK:
+ case ECCGETLAYOUT:
+ case ECCGETSTATS:
+ case MTDFILEMODE:
+ case BLKPG:
+ case BLKRRPART:
+ break;
+
+ /* "dangerous" commands */
+ case MEMERASE:
+ case MEMERASE64:
+ case MEMWRITEOOB:
+ case MEMWRITEOOB64:
+ case MEMWRITE:
+ if (!(file->f_mode & FMODE_WRITE))
+ return -EPERM;
+ break;
+
+ default:
+ return -ENOTTY;
+ }
+
switch (cmd) {
case MEMGETREGIONCOUNT:
if (copy_to_user(argp, &(mtd->numeraseregions), sizeof(int)))
@@ -702,9 +741,6 @@ static int mtdchar_ioctl(struct file *fi
{
struct erase_info *erase;

- if(!(file->f_mode & FMODE_WRITE))
- return -EPERM;
-
erase=kzalloc(sizeof(struct erase_info),GFP_KERNEL);
if (!erase)
ret = -ENOMEM;
@@ -997,9 +1033,6 @@ static int mtdchar_ioctl(struct file *fi
ret = 0;
break;
}
-
- default:
- ret = -ENOTTY;
}

return ret;
@@ -1043,6 +1076,11 @@ static long mtdchar_compat_ioctl(struct
struct mtd_oob_buf32 buf;
struct mtd_oob_buf32 __user *buf_user = argp;

+ if (!(file->f_mode & FMODE_WRITE)) {
+ ret = -EPERM;
+ break;
+ }
+
if (copy_from_user(&buf, argp, sizeof(buf)))
ret = -EFAULT;
else


2020-08-10 15:32:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 28/48] atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent

From: Xin Xiong <[email protected]>

[ Upstream commit 51875dad43b44241b46a569493f1e4bfa0386d86 ]

atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
reference of atm_dev with increased refcount or NULL if fails.

The refcount leaks issues occur in two error handling paths. If
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
returns 0 without decreasing the refcount kept by a local variable,
resulting in refcount leaks.

Fix the issue by adding atm_dev_put() before returning 0 both when
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.

Signed-off-by: Xin Xiong <[email protected]>
Signed-off-by: Xiyu Yang <[email protected]>
Signed-off-by: Xin Tan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/atm/atmtcp.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index afebeb1c3e1e9..723bad1201cc5 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -432,9 +432,15 @@ static int atmtcp_remove_persistent(int itf)
return -EMEDIUMTYPE;
}
dev_data = PRIV(dev);
- if (!dev_data->persist) return 0;
+ if (!dev_data->persist) {
+ atm_dev_put(dev);
+ return 0;
+ }
dev_data->persist = 0;
- if (PRIV(dev)->vcc) return 0;
+ if (PRIV(dev)->vcc) {
+ atm_dev_put(dev);
+ return 0;
+ }
kfree(dev_data);
atm_dev_put(dev);
atm_dev_deregister(dev);
--
2.25.1



2020-08-10 15:32:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 27/48] igb: reinit_locked() should be called with rtnl_lock

From: Francesco Ruggeri <[email protected]>

[ Upstream commit 024a8168b749db7a4aa40a5fbdfa04bf7e77c1c0 ]

We observed two panics involving races with igb_reset_task.
The first panic is caused by this race condition:

kworker reboot -f

igb_reset_task
igb_reinit_locked
igb_down
napi_synchronize
__igb_shutdown
igb_clear_interrupt_scheme
igb_free_q_vectors
igb_free_q_vector
adapter->q_vector[v_idx] = NULL;
napi_disable
Panics trying to access
adapter->q_vector[v_idx].napi_state

The second panic (a divide error) is caused by this race:

kworker reboot -f tx packet

igb_reset_task
__igb_shutdown
rtnl_lock()
...
igb_clear_interrupt_scheme
igb_free_q_vectors
adapter->num_tx_queues = 0
...
rtnl_unlock()
rtnl_lock()
igb_reinit_locked
igb_down
igb_up
netif_tx_start_all_queues
dev_hard_start_xmit
igb_xmit_frame
igb_tx_queue_mapping
Panics on
r_idx % adapter->num_tx_queues

This commit applies to igb_reset_task the same changes that
were applied to ixgbe in commit 2f90b8657ec9 ("ixgbe: this patch
adds support for DCB to the kernel and ixgbe driver"),
commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in
reset subtask").

Signed-off-by: Francesco Ruggeri <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/intel/igb/igb_main.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 36db874f3c928..d85eb80d82497 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6226,9 +6226,18 @@ static void igb_reset_task(struct work_struct *work)
struct igb_adapter *adapter;
adapter = container_of(work, struct igb_adapter, reset_task);

+ rtnl_lock();
+ /* If we're already down or resetting, just bail */
+ if (test_bit(__IGB_DOWN, &adapter->state) ||
+ test_bit(__IGB_RESETTING, &adapter->state)) {
+ rtnl_unlock();
+ return;
+ }
+
igb_dump(adapter);
netdev_err(adapter->netdev, "Reset adapter\n");
igb_reinit_locked(adapter);
+ rtnl_unlock();
}

/**
--
2.25.1



2020-08-10 15:32:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 47/48] i40e: Memory leak in i40e_config_iwarp_qvlist

From: Martyna Szapar <[email protected]>

[ Upstream commit 0b63644602cfcbac849f7ea49272a39e90fa95eb ]

Added freeing the old allocation of vf->qvlist_info in function
i40e_config_iwarp_qvlist before overwriting it with
the new allocation.

Fixes: e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver")
Signed-off-by: Martyna Szapar <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 23 +++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -441,6 +441,7 @@ static int i40e_config_iwarp_qvlist(stru
u32 v_idx, i, reg_idx, reg;
u32 next_q_idx, next_q_type;
u32 msix_vf, size;
+ int ret = 0;

msix_vf = pf->hw.func_caps.num_msix_vectors_vf;

@@ -449,16 +450,19 @@ static int i40e_config_iwarp_qvlist(stru
"Incorrect number of iwarp vectors %u. Maximum %u allowed.\n",
qvlist_info->num_vectors,
msix_vf);
- goto err;
+ ret = -EINVAL;
+ goto err_out;
}

size = sizeof(struct virtchnl_iwarp_qvlist_info) +
(sizeof(struct virtchnl_iwarp_qv_info) *
(qvlist_info->num_vectors - 1));
+ kfree(vf->qvlist_info);
vf->qvlist_info = kzalloc(size, GFP_KERNEL);
- if (!vf->qvlist_info)
- return -ENOMEM;
-
+ if (!vf->qvlist_info) {
+ ret = -ENOMEM;
+ goto err_out;
+ }
vf->qvlist_info->num_vectors = qvlist_info->num_vectors;

msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
@@ -469,8 +473,10 @@ static int i40e_config_iwarp_qvlist(stru
v_idx = qv_info->v_idx;

/* Validate vector id belongs to this vf */
- if (!i40e_vc_isvalid_vector_id(vf, v_idx))
- goto err;
+ if (!i40e_vc_isvalid_vector_id(vf, v_idx)) {
+ ret = -EINVAL;
+ goto err_free;
+ }

vf->qvlist_info->qv_info[i] = *qv_info;

@@ -512,10 +518,11 @@ static int i40e_config_iwarp_qvlist(stru
}

return 0;
-err:
+err_free:
kfree(vf->qvlist_info);
vf->qvlist_info = NULL;
- return -EINVAL;
+err_out:
+ return ret;
}

/**


2020-08-10 15:33:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 24/48] usb: hso: check for return value in hso_serial_common_create()

From: Rustam Kovhaev <[email protected]>

[ Upstream commit e911e99a0770f760377c263bc7bac1b1593c6147 ]

in case of an error tty_register_device_attr() returns ERR_PTR(),
add IS_ERR() check

Reported-and-tested-by: [email protected]
Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e
Signed-off-by: Rustam Kovhaev <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/usb/hso.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 61b9d33681484..bff268b4a9a46 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2274,12 +2274,14 @@ static int hso_serial_common_create(struct hso_serial *serial, int num_urbs,

minor = get_free_serial_index();
if (minor < 0)
- goto exit;
+ goto exit2;

/* register our minor number */
serial->parent->dev = tty_port_register_device_attr(&serial->port,
tty_drv, minor, &serial->parent->interface->dev,
serial->parent, hso_serial_dev_groups);
+ if (IS_ERR(serial->parent->dev))
+ goto exit2;

/* fill in specific data for later use */
serial->minor = minor;
@@ -2324,6 +2326,7 @@ static int hso_serial_common_create(struct hso_serial *serial, int num_urbs,
return 0;
exit:
hso_serial_tty_unregister(serial);
+exit2:
hso_serial_common_free(serial);
return -1;
}
--
2.25.1



2020-08-10 15:33:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 39/48] net: thunderx: use spin_lock_bh in nicvf_set_rx_mode_task()

From: Xin Long <[email protected]>

[ Upstream commit bab9693a9a8c6dd19f670408ec1e78e12a320682 ]

A dead lock was triggered on thunderx driver:

CPU0 CPU1
---- ----
[01] lock(&(&nic->rx_mode_wq_lock)->rlock);
[11] lock(&(&mc->mca_lock)->rlock);
[12] lock(&(&nic->rx_mode_wq_lock)->rlock);
[02] <Interrupt> lock(&(&mc->mca_lock)->rlock);

The path for each is:

[01] worker_thread() -> process_one_work() -> nicvf_set_rx_mode_task()
[02] mld_ifc_timer_expire()
[11] ipv6_add_dev() -> ipv6_dev_mc_inc() -> igmp6_group_added() ->
[12] dev_mc_add() -> __dev_set_rx_mode() -> nicvf_set_rx_mode()

To fix it, it needs to disable bh on [1], so that the timer on [2]
wouldn't be triggered until rx_mode_wq_lock is released. So change
to use spin_lock_bh() instead of spin_lock().

Thanks to Paolo for helping with this.

v1->v2:
- post to netdev.

Reported-by: Rafael P. <[email protected]>
Tested-by: Dean Nelson <[email protected]>
Fixes: 469998c861fa ("net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode")
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -2015,11 +2015,11 @@ static void nicvf_set_rx_mode_task(struc
/* Save message data locally to prevent them from
* being overwritten by next ndo_set_rx_mode call().
*/
- spin_lock(&nic->rx_mode_wq_lock);
+ spin_lock_bh(&nic->rx_mode_wq_lock);
mode = vf_work->mode;
mc = vf_work->mc;
vf_work->mc = NULL;
- spin_unlock(&nic->rx_mode_wq_lock);
+ spin_unlock_bh(&nic->rx_mode_wq_lock);

__nicvf_set_rx_mode_task(mode, mc, nic);
}


2020-08-10 15:33:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 09/48] Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt()

From: Peilin Ye <[email protected]>

commit 75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream.

Check `num_rsp` before using it as for-loop counter.

Cc: [email protected]
Signed-off-by: Peilin Ye <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/bluetooth/hci_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2360,7 +2360,7 @@ static void hci_inquiry_result_evt(struc

BT_DBG("%s num_rsp %d", hdev->name, num_rsp);

- if (!num_rsp)
+ if (!num_rsp || skb->len < num_rsp * sizeof(*info) + 1)
return;

if (hci_dev_test_flag(hdev, HCI_PERIODIC_INQ))


2020-08-10 15:33:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 37/48] hv_netvsc: do not use VF device if link is down

From: Stephen Hemminger <[email protected]>

[ Upstream commit 7c9864bbccc23e1812ac82966555d68c13ea4006 ]

If the accelerated networking SRIOV VF device has lost carrier
use the synthetic network device which is available as backup
path. This is a rare case since if VF link goes down, normally
the VMBus device will also loose external connectivity as well.
But if the communication is between two VM's on the same host
the VMBus device will still work.

Reported-by: "Shah, Ashish N" <[email protected]>
Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
Signed-off-by: Stephen Hemminger <[email protected]>
Reviewed-by: Haiyang Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/hyperv/netvsc_drv.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -543,12 +543,13 @@ static int netvsc_start_xmit(struct sk_b
u32 hash;
struct hv_page_buffer pb[MAX_PAGE_BUFFER_COUNT];

- /* if VF is present and up then redirect packets
- * already called with rcu_read_lock_bh
+ /* If VF is present and up then redirect packets to it.
+ * Skip the VF if it is marked down or has no carrier.
+ * If netpoll is in uses, then VF can not be used either.
*/
vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
if (vf_netdev && netif_running(vf_netdev) &&
- !netpoll_tx_running(net))
+ netif_carrier_ok(vf_netdev) && !netpoll_tx_running(net))
return netvsc_vf_xmit(net, vf_netdev, skb);

/* We will atmost need two pages to describe the rndis


2020-08-10 15:33:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 22/48] i2c: slave: improve sanity check when registering

From: Wolfram Sang <[email protected]>

[ Upstream commit 1b1be3bf27b62f5abcf85c6f3214bdb9c7526685 ]

Add check for ERR_PTR and simplify code while here.

Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Alain Volmat <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/i2c-core-slave.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/i2c/i2c-core-slave.c b/drivers/i2c/i2c-core-slave.c
index 47a9f70a24a97..88959c8580ce0 100644
--- a/drivers/i2c/i2c-core-slave.c
+++ b/drivers/i2c/i2c-core-slave.c
@@ -22,10 +22,8 @@ int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb)
{
int ret;

- if (!client || !slave_cb) {
- WARN(1, "insufficient data\n");
+ if (WARN(IS_ERR_OR_NULL(client) || !slave_cb, "insufficient data\n"))
return -EINVAL;
- }

if (!(client->flags & I2C_CLIENT_SLAVE))
dev_warn(&client->dev, "%s: client slave flag not set. You might see address collisions\n",
--
2.25.1



2020-08-10 15:33:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 33/48] ipv6: fix memory leaks on IPV6_ADDRFORM path

From: Cong Wang <[email protected]>

[ Upstream commit 8c0de6e96c9794cb523a516c465991a70245da1c ]

IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
to IPv4, particularly struct ipv6_ac_socklist. Similar to
struct ipv6_mc_socklist, we should just close it on this path.

This bug can be easily reproduced with the following C program:

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

int main()
{
int s, value;
struct sockaddr_in6 addr;
struct ipv6_mreq m6;

s = socket(AF_INET6, SOCK_DGRAM, 0);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(5000);
inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
connect(s, (struct sockaddr *)&addr, sizeof(addr));

inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
m6.ipv6mr_interface = 5;
setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));

value = AF_INET;
setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));

close(s);
return 0;
}

Reported-by: [email protected]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/addrconf.h | 1 +
net/ipv6/anycast.c | 17 ++++++++++++-----
net/ipv6/ipv6_sockglue.c | 1 +
3 files changed, 14 insertions(+), 5 deletions(-)

--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -305,6 +305,7 @@ int ipv6_sock_ac_join(struct sock *sk, i
const struct in6_addr *addr);
int ipv6_sock_ac_drop(struct sock *sk, int ifindex,
const struct in6_addr *addr);
+void __ipv6_sock_ac_close(struct sock *sk);
void ipv6_sock_ac_close(struct sock *sk);

int __ipv6_dev_ac_inc(struct inet6_dev *idev, const struct in6_addr *addr);
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -173,7 +173,7 @@ int ipv6_sock_ac_drop(struct sock *sk, i
return 0;
}

-void ipv6_sock_ac_close(struct sock *sk)
+void __ipv6_sock_ac_close(struct sock *sk)
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct net_device *dev = NULL;
@@ -181,10 +181,7 @@ void ipv6_sock_ac_close(struct sock *sk)
struct net *net = sock_net(sk);
int prev_index;

- if (!np->ipv6_ac_list)
- return;
-
- rtnl_lock();
+ ASSERT_RTNL();
pac = np->ipv6_ac_list;
np->ipv6_ac_list = NULL;

@@ -201,6 +198,16 @@ void ipv6_sock_ac_close(struct sock *sk)
sock_kfree_s(sk, pac, sizeof(*pac));
pac = next;
}
+}
+
+void ipv6_sock_ac_close(struct sock *sk)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+
+ if (!np->ipv6_ac_list)
+ return;
+ rtnl_lock();
+ __ipv6_sock_ac_close(sk);
rtnl_unlock();
}

--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -207,6 +207,7 @@ static int do_ipv6_setsockopt(struct soc

fl6_free_socklist(sk);
__ipv6_sock_mc_close(sk);
+ __ipv6_sock_ac_close(sk);

/*
* Sock is moving from IPv6 to IPv4 (sk_prot), so


2020-08-10 15:33:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 36/48] net: lan78xx: replace bogus endpoint lookup

From: Johan Hovold <[email protected]>

[ Upstream commit ea060b352654a8de1e070140d25fe1b7e4d50310 ]

Drop the bogus endpoint-lookup helper which could end up accepting
interfaces based on endpoints belonging to unrelated altsettings.

Note that the returned bulk pipes and interrupt endpoint descriptor
were never actually used. Instead the bulk-endpoint numbers are
hardcoded to 1 and 2 (matching the specification), while the interrupt-
endpoint descriptor was assumed to be the third descriptor created by
USB core.

Try to bring some order to this by dropping the bogus lookup helper and
adding the missing endpoint sanity checks while keeping the interrupt-
descriptor assumption for now.

Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/lan78xx.c | 117 +++++++++++-----------------------------------
1 file changed, 30 insertions(+), 87 deletions(-)

--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -388,10 +388,6 @@ struct lan78xx_net {
struct tasklet_struct bh;
struct delayed_work wq;

- struct usb_host_endpoint *ep_blkin;
- struct usb_host_endpoint *ep_blkout;
- struct usb_host_endpoint *ep_intr;
-
int msg_enable;

struct urb *urb_intr;
@@ -2883,78 +2879,12 @@ lan78xx_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}

-static int
-lan78xx_get_endpoints(struct lan78xx_net *dev, struct usb_interface *intf)
-{
- int tmp;
- struct usb_host_interface *alt = NULL;
- struct usb_host_endpoint *in = NULL, *out = NULL;
- struct usb_host_endpoint *status = NULL;
-
- for (tmp = 0; tmp < intf->num_altsetting; tmp++) {
- unsigned ep;
-
- in = NULL;
- out = NULL;
- status = NULL;
- alt = intf->altsetting + tmp;
-
- for (ep = 0; ep < alt->desc.bNumEndpoints; ep++) {
- struct usb_host_endpoint *e;
- int intr = 0;
-
- e = alt->endpoint + ep;
- switch (e->desc.bmAttributes) {
- case USB_ENDPOINT_XFER_INT:
- if (!usb_endpoint_dir_in(&e->desc))
- continue;
- intr = 1;
- /* FALLTHROUGH */
- case USB_ENDPOINT_XFER_BULK:
- break;
- default:
- continue;
- }
- if (usb_endpoint_dir_in(&e->desc)) {
- if (!intr && !in)
- in = e;
- else if (intr && !status)
- status = e;
- } else {
- if (!out)
- out = e;
- }
- }
- if (in && out)
- break;
- }
- if (!alt || !in || !out)
- return -EINVAL;
-
- dev->pipe_in = usb_rcvbulkpipe(dev->udev,
- in->desc.bEndpointAddress &
- USB_ENDPOINT_NUMBER_MASK);
- dev->pipe_out = usb_sndbulkpipe(dev->udev,
- out->desc.bEndpointAddress &
- USB_ENDPOINT_NUMBER_MASK);
- dev->ep_intr = status;
-
- return 0;
-}
-
static int lan78xx_bind(struct lan78xx_net *dev, struct usb_interface *intf)
{
struct lan78xx_priv *pdata = NULL;
int ret;
int i;

- ret = lan78xx_get_endpoints(dev, intf);
- if (ret) {
- netdev_warn(dev->net, "lan78xx_get_endpoints failed: %d\n",
- ret);
- return ret;
- }
-
dev->data[0] = (unsigned long)kzalloc(sizeof(*pdata), GFP_KERNEL);

pdata = (struct lan78xx_priv *)(dev->data[0]);
@@ -3726,6 +3656,7 @@ static void lan78xx_stat_monitor(struct
static int lan78xx_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ struct usb_host_endpoint *ep_blkin, *ep_blkout, *ep_intr;
struct lan78xx_net *dev;
struct net_device *netdev;
struct usb_device *udev;
@@ -3774,6 +3705,34 @@ static int lan78xx_probe(struct usb_inte

mutex_init(&dev->stats.access_lock);

+ if (intf->cur_altsetting->desc.bNumEndpoints < 3) {
+ ret = -ENODEV;
+ goto out2;
+ }
+
+ dev->pipe_in = usb_rcvbulkpipe(udev, BULK_IN_PIPE);
+ ep_blkin = usb_pipe_endpoint(udev, dev->pipe_in);
+ if (!ep_blkin || !usb_endpoint_is_bulk_in(&ep_blkin->desc)) {
+ ret = -ENODEV;
+ goto out2;
+ }
+
+ dev->pipe_out = usb_sndbulkpipe(udev, BULK_OUT_PIPE);
+ ep_blkout = usb_pipe_endpoint(udev, dev->pipe_out);
+ if (!ep_blkout || !usb_endpoint_is_bulk_out(&ep_blkout->desc)) {
+ ret = -ENODEV;
+ goto out2;
+ }
+
+ ep_intr = &intf->cur_altsetting->endpoint[2];
+ if (!usb_endpoint_is_int_in(&ep_intr->desc)) {
+ ret = -ENODEV;
+ goto out2;
+ }
+
+ dev->pipe_intr = usb_rcvintpipe(dev->udev,
+ usb_endpoint_num(&ep_intr->desc));
+
ret = lan78xx_bind(dev, intf);
if (ret < 0)
goto out2;
@@ -3786,23 +3745,7 @@ static int lan78xx_probe(struct usb_inte
netdev->max_mtu = MAX_SINGLE_PACKET_SIZE;
netif_set_gso_max_size(netdev, MAX_SINGLE_PACKET_SIZE - MAX_HEADER);

- if (intf->cur_altsetting->desc.bNumEndpoints < 3) {
- ret = -ENODEV;
- goto out3;
- }
-
- dev->ep_blkin = (intf->cur_altsetting)->endpoint + 0;
- dev->ep_blkout = (intf->cur_altsetting)->endpoint + 1;
- dev->ep_intr = (intf->cur_altsetting)->endpoint + 2;
-
- dev->pipe_in = usb_rcvbulkpipe(udev, BULK_IN_PIPE);
- dev->pipe_out = usb_sndbulkpipe(udev, BULK_OUT_PIPE);
-
- dev->pipe_intr = usb_rcvintpipe(dev->udev,
- dev->ep_intr->desc.bEndpointAddress &
- USB_ENDPOINT_NUMBER_MASK);
- period = dev->ep_intr->desc.bInterval;
-
+ period = ep_intr->desc.bInterval;
maxp = usb_maxpacket(dev->udev, dev->pipe_intr, 0);
buf = kmalloc(maxp, GFP_KERNEL);
if (buf) {


2020-08-10 15:33:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 44/48] i40e: add num_vectors checker in iwarp handler

From: Sergey Nemov <[email protected]>

[ Upstream commit 7015ca3df965378bcef072cca9cd63ed098665b5 ]

Field num_vectors from struct virtchnl_iwarp_qvlist_info should not be
larger than num_msix_vectors_vf in the hw struct. The iwarp uses the
same set of vectors as the LAN VF driver.

Fixes: e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver")
Signed-off-by: Sergey Nemov <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -442,6 +442,16 @@ static int i40e_config_iwarp_qvlist(stru
u32 next_q_idx, next_q_type;
u32 msix_vf, size;

+ msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
+
+ if (qvlist_info->num_vectors > msix_vf) {
+ dev_warn(&pf->pdev->dev,
+ "Incorrect number of iwarp vectors %u. Maximum %u allowed.\n",
+ qvlist_info->num_vectors,
+ msix_vf);
+ goto err;
+ }
+
size = sizeof(struct virtchnl_iwarp_qvlist_info) +
(sizeof(struct virtchnl_iwarp_qv_info) *
(qvlist_info->num_vectors - 1));


2020-08-10 15:33:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 35/48] vxlan: Ensure FDB dump is performed under RCU

From: Ido Schimmel <[email protected]>

[ Upstream commit b5141915b5aec3b29a63db869229e3741ebce258 ]

The commit cited below removed the RCU read-side critical section from
rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
without RCU protection.

This results in the following warning [1] in the VXLAN driver, which
relied on the callback being invoked from an RCU read-side critical
section.

Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
in the bridge driver.

[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
-----------------------------
drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by bridge/166:
#0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090

stack backtrace:
CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
vxlan_fdb_dump+0x51e/0x6d0
rtnl_fdb_dump+0x4dc/0xad0
netlink_dump+0x540/0x1090
__netlink_dump_start+0x695/0x950
rtnetlink_rcv_msg+0x802/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
__sys_sendto+0x279/0x3b0
__x64_sys_sendto+0xe6/0x1a0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fe14fa2ade0
Code: Bad RIP value.
RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Fixes: 5e6d24358799 ("bridge: netlink dump interface at par with brctl")
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/vxlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -975,6 +975,7 @@ static int vxlan_fdb_dump(struct sk_buff
for (h = 0; h < FDB_HASH_SIZE; ++h) {
struct vxlan_fdb *f;

+ rcu_read_lock();
hlist_for_each_entry_rcu(f, &vxlan->fdb_head[h], hlist) {
struct vxlan_rdst *rd;

@@ -987,12 +988,15 @@ static int vxlan_fdb_dump(struct sk_buff
cb->nlh->nlmsg_seq,
RTM_NEWNEIGH,
NLM_F_MULTI, rd);
- if (err < 0)
+ if (err < 0) {
+ rcu_read_unlock();
goto out;
+ }
skip:
*idx += 1;
}
}
+ rcu_read_unlock();
}
out:
return err;


2020-08-10 15:33:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 34/48] net: ethernet: mtk_eth_soc: fix MTU warnings

From: Landen Chao <[email protected]>

[ Upstream commit 555a893303872e044fb86f0a5834ce78d41ad2e2 ]

in recent kernel versions there are warnings about incorrect MTU size
like these:

eth0: mtu greater than device maximum
mtk_soc_eth 1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead

Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Fixes: 72579e14a1d3 ("net: dsa: don't fail to probe if we couldn't set the MTU")
Fixes: 7a4c53bee332 ("net: report invalid mtu value via netlink extack")
Signed-off-by: Landen Chao <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2452,6 +2452,8 @@ static int mtk_add_mac(struct mtk_eth *e
eth->netdev[id]->irq = eth->irq[0];
eth->netdev[id]->dev.of_node = np;

+ eth->netdev[id]->max_mtu = MTK_MAX_RX_LENGTH - MTK_RX_ETH_HLEN;
+
return 0;

free_netdev:


2020-08-10 15:33:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 41/48] Revert "vxlan: fix tos value before xmit"

From: Hangbin Liu <[email protected]>

[ Upstream commit a0dced17ad9dc08b1b25e0065b54c97a318e6e8b ]

This reverts commit 71130f29979c7c7956b040673e6b9d5643003176.

In commit 71130f29979c ("vxlan: fix tos value before xmit") we want to
make sure the tos value are filtered by RT_TOS() based on RFC1349.

0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+

But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like

0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+

So with

IPTOS_TOS_MASK 0x1E
RT_TOS(tos) ((tos)&IPTOS_TOS_MASK)

the first 3 bits DSCP info will get lost.

To take all the DSCP info in xmit, we should revert the patch and just push
all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later.

Fixes: 71130f29979c ("vxlan: fix tos value before xmit")
Signed-off-by: Hangbin Liu <[email protected]>
Acked-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/vxlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2223,7 +2223,7 @@ static void vxlan_xmit_one(struct sk_buf
ndst = &rt->dst;
skb_tunnel_check_pmtu(skb, ndst, VXLAN_HEADROOM);

- tos = ip_tunnel_ecn_encap(RT_TOS(tos), old_iph, skb);
+ tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
ttl = ttl ? : ip4_dst_hoplimit(&rt->dst);
err = vxlan_build_skb(skb, ndst, sizeof(struct iphdr),
vni, md, flags, udp_sum);
@@ -2260,7 +2260,7 @@ static void vxlan_xmit_one(struct sk_buf

skb_tunnel_check_pmtu(skb, ndst, VXLAN6_HEADROOM);

- tos = ip_tunnel_ecn_encap(RT_TOS(tos), old_iph, skb);
+ tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
ttl = ttl ? : ip6_dst_hoplimit(ndst);
skb_scrub_packet(skb, xnet);
err = vxlan_build_skb(skb, ndst, sizeof(struct ipv6hdr),


2020-08-10 15:33:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 08/48] Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()

From: Peilin Ye <[email protected]>

commit 51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream.

Check upon `num_rsp` is insufficient. A malformed event packet with a
large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
of bounds. Fix it.

This patch fixes the following syzbot bug:

https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2

Reported-by: [email protected]
Cc: [email protected]
Signed-off-by: Peilin Ye <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/bluetooth/hci_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4151,7 +4151,7 @@ static void hci_extended_inquiry_result_

BT_DBG("%s num_rsp %d", hdev->name, num_rsp);

- if (!num_rsp)
+ if (!num_rsp || skb->len < num_rsp * sizeof(*info) + 1)
return;

if (hci_dev_test_flag(hdev, HCI_PERIODIC_INQ))


2020-08-10 15:33:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 42/48] selftests/net: relax cpu affinity requirement in msg_zerocopy test

From: Willem de Bruijn <[email protected]>

[ Upstream commit 16f6458f2478b55e2b628797bc81a4455045c74e ]

The msg_zerocopy test pins the sender and receiver threads to separate
cores to reduce variance between runs.

But it hardcodes the cores and skips core 0, so it fails on machines
with the selected cores offline, or simply fewer cores.

The test mainly gives code coverage in automated runs. The throughput
of zerocopy ('-z') and non-zerocopy runs is logged for manual
inspection.

Continue even when sched_setaffinity fails. Just log to warn anyone
interpreting the data.

Fixes: 07b65c5b31ce ("test: add msg_zerocopy test")
Reported-by: Colin Ian King <[email protected]>
Signed-off-by: Willem de Bruijn <[email protected]>
Acked-by: Colin Ian King <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/net/msg_zerocopy.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/tools/testing/selftests/net/msg_zerocopy.c
+++ b/tools/testing/selftests/net/msg_zerocopy.c
@@ -125,9 +125,8 @@ static int do_setcpu(int cpu)
CPU_ZERO(&mask);
CPU_SET(cpu, &mask);
if (sched_setaffinity(0, sizeof(mask), &mask))
- error(1, 0, "setaffinity %d", cpu);
-
- if (cfg_verbose)
+ fprintf(stderr, "cpu: unable to pin, may increase variance.\n");
+ else if (cfg_verbose)
fprintf(stderr, "cpu: %u\n", cpu);

return 0;


2020-08-10 15:33:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 05/48] Revert "ALSA: hda: call runtime_allow() for all hda controllers"

From: Hui Wang <[email protected]>

commit 07c9983b567d0ef33aefc063299de95a987e12a8 upstream.

This reverts commit 9a6418487b56 ("ALSA: hda: call runtime_allow()
for all hda controllers").

The reverted patch already introduced some regressions on some
machines:
- on gemini-lake machines, the error of "azx_get_response timeout"
happens in the hda driver.
- on the machines with alc662 codec, the audio jack detection doesn't
work anymore.

Fixes: 9a6418487b56 ("ALSA: hda: call runtime_allow() for all hda controllers")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208511
Cc: <[email protected]>
Signed-off-by: Hui Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/hda_intel.c | 1 -
1 file changed, 1 deletion(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2478,7 +2478,6 @@ static int azx_probe_continue(struct azx

if (azx_has_pm_runtime(chip)) {
pm_runtime_use_autosuspend(&pci->dev);
- pm_runtime_allow(&pci->dev);
pm_runtime_put_autosuspend(&pci->dev);
}



2020-08-10 15:34:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 25/48] firmware: Fix a reference count leak.

From: Qiushi Wu <[email protected]>

[ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ]

kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Callback function fw_cfg_sysfs_release_entry() in kobject_put()
can handle the pointer "entry" properly.

Signed-off-by: Qiushi Wu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/firmware/qemu_fw_cfg.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 039e0f91dba8f..6945c3c966375 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -605,8 +605,10 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f)
/* register entry under "/sys/firmware/qemu_fw_cfg/by_key/" */
err = kobject_init_and_add(&entry->kobj, &fw_cfg_sysfs_entry_ktype,
fw_cfg_sel_ko, "%d", entry->select);
- if (err)
- goto err_register;
+ if (err) {
+ kobject_put(&entry->kobj);
+ return err;
+ }

/* add raw binary content access */
err = sysfs_create_bin_file(&entry->kobj, &fw_cfg_sysfs_attr_raw);
@@ -622,7 +624,6 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f)

err_add_raw:
kobject_del(&entry->kobj);
-err_register:
kfree(entry);
return err;
}
--
2.25.1



2020-08-10 15:34:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 07/48] staging: android: ashmem: Fix lockdep warning for write operation

From: Suren Baghdasaryan <[email protected]>

commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.

syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);

kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.

[1]: https://lkml.kernel.org/lkml/[email protected]/

Reported-by: [email protected]
Signed-off-by: Suren Baghdasaryan <[email protected]>
Cc: stable <[email protected]>
Reviewed-by: Joel Fernandes (Google) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/android/ashmem.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -95,6 +95,15 @@ static DEFINE_MUTEX(ashmem_mutex);
static struct kmem_cache *ashmem_area_cachep __read_mostly;
static struct kmem_cache *ashmem_range_cachep __read_mostly;

+/*
+ * A separate lockdep class for the backing shmem inodes to resolve the lockdep
+ * warning about the race between kswapd taking fs_reclaim before inode_lock
+ * and write syscall taking inode_lock and then fs_reclaim.
+ * Note that such race is impossible because ashmem does not support write
+ * syscalls operating on the backing shmem.
+ */
+static struct lock_class_key backing_shmem_inode_class;
+
static inline unsigned long range_size(struct ashmem_range *range)
{
return range->pgend - range->pgstart + 1;
@@ -395,6 +404,7 @@ static int ashmem_mmap(struct file *file
if (!asma->file) {
char *name = ASHMEM_NAME_DEF;
struct file *vmfile;
+ struct inode *inode;

if (asma->name[ASHMEM_NAME_PREFIX_LEN] != '\0')
name = asma->name;
@@ -406,6 +416,8 @@ static int ashmem_mmap(struct file *file
goto out;
}
vmfile->f_mode |= FMODE_LSEEK;
+ inode = file_inode(vmfile);
+ lockdep_set_class(&inode->i_rwsem, &backing_shmem_inode_class);
asma->file = vmfile;
/*
* override mmap operation of the vmfile so that it can't be


2020-08-10 15:34:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 30/48] Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)

From: Dexuan Cui <[email protected]>

[ Upstream commit ddc9d357b991838c2d975e8d7e4e9db26f37a7ff ]

When a Linux hv_sock app tries to connect to a Service GUID on which no
host app is listening, a recent host (RS3+) sends a
CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such
a warning:

unknown msgtype=23
WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc

Actually Linux can safely ignore the message because the Linux app's
connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT
and vsock_stream_connect(). We don't bother to make use of the message
because: 1) it's only supported on recent hosts; 2) a non-trivial effort
is required to use the message in Linux, but the benefit is small.

So, let's not see the warning by silently ignoring the message.

Signed-off-by: Dexuan Cui <[email protected]>
Reviewed-by: Michael Kelley <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hv/channel_mgmt.c | 21 +++++++--------------
drivers/hv/vmbus_drv.c | 4 ++++
include/linux/hyperv.h | 2 ++
3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 3bf1f9ef8ea25..c83361a8e2033 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -1249,6 +1249,8 @@ channel_message_table[CHANNELMSG_COUNT] = {
{ CHANNELMSG_19, 0, NULL },
{ CHANNELMSG_20, 0, NULL },
{ CHANNELMSG_TL_CONNECT_REQUEST, 0, NULL },
+ { CHANNELMSG_22, 0, NULL },
+ { CHANNELMSG_TL_CONNECT_RESULT, 0, NULL },
};

/*
@@ -1260,25 +1262,16 @@ void vmbus_onmessage(void *context)
{
struct hv_message *msg = context;
struct vmbus_channel_message_header *hdr;
- int size;

hdr = (struct vmbus_channel_message_header *)msg->u.payload;
- size = msg->header.payload_size;

trace_vmbus_on_message(hdr);

- if (hdr->msgtype >= CHANNELMSG_COUNT) {
- pr_err("Received invalid channel message type %d size %d\n",
- hdr->msgtype, size);
- print_hex_dump_bytes("", DUMP_PREFIX_NONE,
- (unsigned char *)msg->u.payload, size);
- return;
- }
-
- if (channel_message_table[hdr->msgtype].message_handler)
- channel_message_table[hdr->msgtype].message_handler(hdr);
- else
- pr_err("Unhandled channel message type %d\n", hdr->msgtype);
+ /*
+ * vmbus_on_msg_dpc() makes sure the hdr->msgtype here can not go
+ * out of bound and the message_handler pointer can not be NULL.
+ */
+ channel_message_table[hdr->msgtype].message_handler(hdr);
}

/*
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index fb22b72fd535a..0699c60188895 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -939,6 +939,10 @@ void vmbus_on_msg_dpc(unsigned long data)
}

entry = &channel_message_table[hdr->msgtype];
+
+ if (!entry->message_handler)
+ goto msg_handled;
+
if (entry->handler_type == VMHT_BLOCKING) {
ctx = kmalloc(sizeof(*ctx), GFP_ATOMIC);
if (ctx == NULL)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index c43e694fef7dd..35461d49d3aee 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -428,6 +428,8 @@ enum vmbus_channel_message_type {
CHANNELMSG_19 = 19,
CHANNELMSG_20 = 20,
CHANNELMSG_TL_CONNECT_REQUEST = 21,
+ CHANNELMSG_22 = 22,
+ CHANNELMSG_TL_CONNECT_RESULT = 23,
CHANNELMSG_COUNT
};

--
2.25.1



2020-08-10 15:34:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 02/48] USB: iowarrior: fix up report size handling for some devices

From: Greg Kroah-Hartman <[email protected]>

commit 17a82716587e9d7c3b246a789add490b2b5dcab6 upstream.

In previous patches that added support for new iowarrior devices, the
handling of the report size was not done correct.

Fix that up and update the copyright date for the driver

Reworked from an original patch written by Christoph Jung.

Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device")
Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices")
Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices")
Cc: stable <[email protected]>
Reported-by: Christoph Jung <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/misc/iowarrior.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)

--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -2,8 +2,9 @@
/*
* Native support for the I/O-Warrior USB devices
*
- * Copyright (c) 2003-2005 Code Mercenaries GmbH
- * written by Christian Lucht <[email protected]>
+ * Copyright (c) 2003-2005, 2020 Code Mercenaries GmbH
+ * written by Christian Lucht <[email protected]> and
+ * Christoph Jung <[email protected]>
*
* based on

@@ -817,14 +818,28 @@ static int iowarrior_probe(struct usb_in

/* we have to check the report_size often, so remember it in the endianness suitable for our machine */
dev->report_size = usb_endpoint_maxp(dev->int_in_endpoint);
- if ((dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) &&
- ((dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56) ||
- (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56AM) ||
- (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28) ||
- (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28L) ||
- (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW100)))
- /* IOWarrior56 has wMaxPacketSize different from report size */
- dev->report_size = 7;
+
+ /*
+ * Some devices need the report size to be different than the
+ * endpoint size.
+ */
+ if (dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) {
+ switch (dev->product_id) {
+ case USB_DEVICE_ID_CODEMERCS_IOW56:
+ case USB_DEVICE_ID_CODEMERCS_IOW56AM:
+ dev->report_size = 7;
+ break;
+
+ case USB_DEVICE_ID_CODEMERCS_IOW28:
+ case USB_DEVICE_ID_CODEMERCS_IOW28L:
+ dev->report_size = 4;
+ break;
+
+ case USB_DEVICE_ID_CODEMERCS_IOW100:
+ dev->report_size = 13;
+ break;
+ }
+ }

/* create the urb and buffer for reading */
dev->int_in_urb = usb_alloc_urb(0, GFP_KERNEL);


2020-08-10 15:34:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 11/48] omapfb: dss: Fix max fclk divider for omap36xx

From: Adam Ford <[email protected]>

commit 254503a2b186caa668a188dbbd7ab0d25149c0a5 upstream.

The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.

This patch fixes the divider for fbdev driver instead of the drm.

Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: <[email protected]> #4.5+
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Rob Clark <[email protected]>
[b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)]
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/video/fbdev/omap2/omapfb/dss/dss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -844,7 +844,7 @@ static const struct dss_features omap34x
};

static const struct dss_features omap3630_dss_feats = {
- .fck_div_max = 32,
+ .fck_div_max = 31,
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,


2020-08-10 15:35:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 03/48] usb: xhci: define IDs for various ASMedia host controllers

From: Forest Crossman <[email protected]>

commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream.

Not all ASMedia host controllers have a device ID that matches its part
number. #define some of these IDs to make it clearer at a glance which
chips require what quirks.

Acked-by: Mathias Nyman <[email protected]>
Signed-off-by: Forest Crossman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-pci.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -47,7 +47,9 @@
#define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba
#define PCI_DEVICE_ID_AMD_PROMONTORYA_2 0x43bb
#define PCI_DEVICE_ID_AMD_PROMONTORYA_1 0x43bc
+#define PCI_DEVICE_ID_ASMEDIA_1042_XHCI 0x1042
#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
+#define PCI_DEVICE_ID_ASMEDIA_2142_XHCI 0x2142

static const char hcd_name[] = "xhci_hcd";

@@ -226,13 +228,13 @@ static void xhci_pci_quirks(struct devic
xhci->quirks |= XHCI_BROKEN_STREAMS;

if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
- pdev->device == 0x1042)
+ pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI)
xhci->quirks |= XHCI_BROKEN_STREAMS;
if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
- pdev->device == 0x1142)
+ pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
- pdev->device == 0x2142)
+ pdev->device == PCI_DEVICE_ID_ASMEDIA_2142_XHCI)
xhci->quirks |= XHCI_NO_64BIT_SUPPORT;

if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&


2020-08-10 15:35:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 43/48] rxrpc: Fix race between recvmsg and sendmsg on immediate call failure

From: David Howells <[email protected]>

[ Upstream commit 65550098c1c4db528400c73acf3e46bfa78d9264 ]

There's a race between rxrpc_sendmsg setting up a call, but then failing to
send anything on it due to an error, and recvmsg() seeing the call
completion occur and trying to return the state to the user.

An assertion fails in rxrpc_recvmsg() because the call has already been
released from the socket and is about to be released again as recvmsg deals
with it. (The recvmsg_q queue on the socket holds a ref, so there's no
problem with use-after-free.)

We also have to be careful not to end up reporting an error twice, in such
a way that both returns indicate to userspace that the user ID supplied
with the call is no longer in use - which could cause the client to
malfunction if it recycles the user ID fast enough.

Fix this by the following means:

(1) When sendmsg() creates a call after the point that the call has been
successfully added to the socket, don't return any errors through
sendmsg(), but rather complete the call and let recvmsg() retrieve
them. Make sendmsg() return 0 at this point. Further calls to
sendmsg() for that call will fail with ESHUTDOWN.

Note that at this point, we haven't send any packets yet, so the
server doesn't yet know about the call.

(2) If sendmsg() returns an error when it was expected to create a new
call, it means that the user ID wasn't used.

(3) Mark the call disconnected before marking it completed to prevent an
oops in rxrpc_release_call().

(4) recvmsg() will then retrieve the error and set MSG_EOR to indicate
that the user ID is no longer known by the kernel.

An oops like the following is produced:

kernel BUG at net/rxrpc/recvmsg.c:605!
...
RIP: 0010:rxrpc_recvmsg+0x256/0x5ae
...
Call Trace:
? __init_waitqueue_head+0x2f/0x2f
____sys_recvmsg+0x8a/0x148
? import_iovec+0x69/0x9c
? copy_msghdr_from_user+0x5c/0x86
___sys_recvmsg+0x72/0xaa
? __fget_files+0x22/0x57
? __fget_light+0x46/0x51
? fdget+0x9/0x1b
do_recvmmsg+0x15e/0x232
? _raw_spin_unlock+0xa/0xb
? vtime_delta+0xf/0x25
__x64_sys_recvmmsg+0x2c/0x2f
do_syscall_64+0x4c/0x78
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 357f5ef64628 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()")
Reported-by: [email protected]
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Marc Dionne <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/rxrpc/call_object.c | 27 +++++++++++++++++++--------
net/rxrpc/conn_object.c | 8 +++++---
net/rxrpc/recvmsg.c | 2 +-
net/rxrpc/sendmsg.c | 3 +++
4 files changed, 28 insertions(+), 12 deletions(-)

--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -290,7 +290,7 @@ struct rxrpc_call *rxrpc_new_client_call
*/
ret = rxrpc_connect_call(rx, call, cp, srx, gfp);
if (ret < 0)
- goto error;
+ goto error_attached_to_socket;

trace_rxrpc_call(call, rxrpc_call_connected, atomic_read(&call->usage),
here, NULL);
@@ -310,18 +310,29 @@ struct rxrpc_call *rxrpc_new_client_call
error_dup_user_ID:
write_unlock(&rx->call_lock);
release_sock(&rx->sk);
- ret = -EEXIST;
-
-error:
__rxrpc_set_call_completion(call, RXRPC_CALL_LOCAL_ERROR,
- RX_CALL_DEAD, ret);
+ RX_CALL_DEAD, -EEXIST);
trace_rxrpc_call(call, rxrpc_call_error, atomic_read(&call->usage),
- here, ERR_PTR(ret));
+ here, ERR_PTR(-EEXIST));
rxrpc_release_call(rx, call);
mutex_unlock(&call->user_mutex);
rxrpc_put_call(call, rxrpc_call_put);
- _leave(" = %d", ret);
- return ERR_PTR(ret);
+ _leave(" = -EEXIST");
+ return ERR_PTR(-EEXIST);
+
+ /* We got an error, but the call is attached to the socket and is in
+ * need of release. However, we might now race with recvmsg() when
+ * completing the call queues it. Return 0 from sys_sendmsg() and
+ * leave the error to recvmsg() to deal with.
+ */
+error_attached_to_socket:
+ trace_rxrpc_call(call, rxrpc_call_error, atomic_read(&call->usage),
+ here, ERR_PTR(ret));
+ set_bit(RXRPC_CALL_DISCONNECTED, &call->flags);
+ __rxrpc_set_call_completion(call, RXRPC_CALL_LOCAL_ERROR,
+ RX_CALL_DEAD, ret);
+ _leave(" = c=%08x [err]", call->debug_id);
+ return call;
}

/*
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -215,9 +215,11 @@ void rxrpc_disconnect_call(struct rxrpc_

call->peer->cong_cwnd = call->cong_cwnd;

- spin_lock_bh(&conn->params.peer->lock);
- hlist_del_rcu(&call->error_link);
- spin_unlock_bh(&conn->params.peer->lock);
+ if (!hlist_unhashed(&call->error_link)) {
+ spin_lock_bh(&call->peer->lock);
+ hlist_del_rcu(&call->error_link);
+ spin_unlock_bh(&call->peer->lock);
+ }

if (rxrpc_is_client_call(call))
return rxrpc_disconnect_client_call(call);
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -530,7 +530,7 @@ try_again:
goto error_unlock_call;
}

- if (msg->msg_name) {
+ if (msg->msg_name && call->peer) {
struct sockaddr_rxrpc *srx = msg->msg_name;
size_t len = sizeof(call->peer->srx);

--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -654,6 +654,9 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *
if (IS_ERR(call))
return PTR_ERR(call);
/* ... and we have the call lock. */
+ ret = 0;
+ if (READ_ONCE(call->state) == RXRPC_CALL_COMPLETE)
+ goto out_put_unlock;
} else {
switch (READ_ONCE(call->state)) {
case RXRPC_CALL_UNINITIALISED:


2020-08-10 15:35:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 23/48] i2c: slave: add sanity check when unregistering

From: Wolfram Sang <[email protected]>

[ Upstream commit 8808981baf96e1b3dea1f08461e4d958aa0dbde1 ]

Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Alain Volmat <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/i2c-core-slave.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/i2c-core-slave.c b/drivers/i2c/i2c-core-slave.c
index 88959c8580ce0..f2e7e373ee478 100644
--- a/drivers/i2c/i2c-core-slave.c
+++ b/drivers/i2c/i2c-core-slave.c
@@ -62,6 +62,9 @@ int i2c_slave_unregister(struct i2c_client *client)
{
int ret;

+ if (IS_ERR_OR_NULL(client))
+ return -EINVAL;
+
if (!client->adapter->algo->unreg_slave) {
dev_err(&client->dev, "%s: not supported by adapter\n", __func__);
return -EOPNOTSUPP;
--
2.25.1



2020-08-10 15:35:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 06/48] ALSA: seq: oss: Serialize ioctls

From: Takashi Iwai <[email protected]>

commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.

Some ioctls via OSS sequencer API may race and lead to UAF when the
port create and delete are performed concurrently, as spotted by a
couple of syzkaller cases. This patch is an attempt to address it by
serializing the ioctls with the existing register_mutex.

Basically OSS sequencer API is an obsoleted interface and was designed
without much consideration of the concurrency. There are very few
applications with it, and the concurrent performance isn't asked,
hence this "big hammer" approach should be good enough.

Reported-by: [email protected]
Reported-by: [email protected]
Suggested-by: Hillf Danton <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/seq/oss/seq_oss.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/sound/core/seq/oss/seq_oss.c
+++ b/sound/core/seq/oss/seq_oss.c
@@ -181,10 +181,16 @@ static long
odev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
struct seq_oss_devinfo *dp;
+ long rc;
+
dp = file->private_data;
if (snd_BUG_ON(!dp))
return -ENXIO;
- return snd_seq_oss_ioctl(dp, cmd, arg);
+
+ mutex_lock(&register_mutex);
+ rc = snd_seq_oss_ioctl(dp, cmd, arg);
+ mutex_unlock(&register_mutex);
+ return rc;
}

#ifdef CONFIG_COMPAT


2020-08-10 15:36:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 20/48] drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason

From: Ben Skeggs <[email protected]>

[ Upstream commit 498595abf5bd51f0ae074cec565d888778ea558f ]

Stale pointer was tripping up the unload path.

Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 0f64c0a1d4b30..fef38ea146a2a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -599,6 +599,7 @@ fini:
drm_fb_helper_fini(&fbcon->helper);
free:
kfree(fbcon);
+ drm->fbcon = NULL;
return ret;
}

--
2.25.1



2020-08-10 15:36:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 21/48] drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure

From: Ben Skeggs <[email protected]>

[ Upstream commit 15fbc3b938534cc8eaac584a7b0c1183fc968b86 ]

This is tripping up the format modifier patches.

Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index fef38ea146a2a..406cb99af7f21 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -315,7 +315,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
struct nouveau_framebuffer *fb;
struct nouveau_channel *chan;
struct nouveau_bo *nvbo;
- struct drm_mode_fb_cmd2 mode_cmd;
+ struct drm_mode_fb_cmd2 mode_cmd = {};
int ret;

mode_cmd.width = sizes->surface_width;
--
2.25.1



2020-08-10 15:36:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 16/48] leds: da903x: fix use-after-free on unbind

From: Johan Hovold <[email protected]>

commit 6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream.

Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.

Fixes: eed16255d66b ("leds: da903x: Use devm_led_classdev_register")
Cc: stable <[email protected]> # 4.6
Cc: Amitoj Kaur Chawla <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/leds/leds-da903x.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

--- a/drivers/leds/leds-da903x.c
+++ b/drivers/leds/leds-da903x.c
@@ -113,12 +113,23 @@ static int da903x_led_probe(struct platf
led->flags = pdata->flags;
led->master = pdev->dev.parent;

- ret = devm_led_classdev_register(led->master, &led->cdev);
+ ret = led_classdev_register(led->master, &led->cdev);
if (ret) {
dev_err(&pdev->dev, "failed to register LED %d\n", id);
return ret;
}

+ platform_set_drvdata(pdev, led);
+
+ return 0;
+}
+
+static int da903x_led_remove(struct platform_device *pdev)
+{
+ struct da903x_led *led = platform_get_drvdata(pdev);
+
+ led_classdev_unregister(&led->cdev);
+
return 0;
}

@@ -127,6 +138,7 @@ static struct platform_driver da903x_led
.name = "da903x-led",
},
.probe = da903x_led_probe,
+ .remove = da903x_led_remove,
};

module_platform_driver(da903x_led_driver);


2020-08-10 15:36:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/48] leds: wm831x-status: fix use-after-free on unbind

From: Johan Hovold <[email protected]>

commit 47a459ecc800a17109d0c496a4e21e478806ee40 upstream.

Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.

Fixes: 8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable <[email protected]> # 4.6
Cc: Amitoj Kaur Chawla <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/leds/leds-wm831x-status.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

--- a/drivers/leds/leds-wm831x-status.c
+++ b/drivers/leds/leds-wm831x-status.c
@@ -273,12 +273,23 @@ static int wm831x_status_probe(struct pl
drvdata->cdev.blink_set = wm831x_status_blink_set;
drvdata->cdev.groups = wm831x_status_groups;

- ret = devm_led_classdev_register(wm831x->dev, &drvdata->cdev);
+ ret = led_classdev_register(wm831x->dev, &drvdata->cdev);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to register LED: %d\n", ret);
return ret;
}

+ platform_set_drvdata(pdev, drvdata);
+
+ return 0;
+}
+
+static int wm831x_status_remove(struct platform_device *pdev)
+{
+ struct wm831x_status *drvdata = platform_get_drvdata(pdev);
+
+ led_classdev_unregister(&drvdata->cdev);
+
return 0;
}

@@ -287,6 +298,7 @@ static struct platform_driver wm831x_sta
.name = "wm831x-status",
},
.probe = wm831x_status_probe,
+ .remove = wm831x_status_remove,
};

module_platform_driver(wm831x_status_driver);


2020-08-10 15:36:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 01/48] USB: serial: qcserial: add EM7305 QDL product ID

From: Erik Ekman <[email protected]>

commit d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream.

When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
laptop, it changed product ID to 0x9062 when entering QDL mode:

usb 2-4: new high-speed USB device number 78 using xhci_hcd
usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-4: Product: EM7305
usb 2-4: Manufacturer: Sierra Wireless, Incorporated

The upgrade could complete after running
# echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id

qcserial 2-4:1.0: Qualcomm USB modem converter detected
usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0

Signed-off-by: Erik Ekman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -155,6 +155,7 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x1199, 0x9056)}, /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)}, /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)}, /* Sierra Wireless Modem */
+ {DEVICE_SWI(0x1199, 0x9062)}, /* Sierra Wireless EM7305 QDL */
{DEVICE_SWI(0x1199, 0x9063)}, /* Sierra Wireless EM7305 */
{DEVICE_SWI(0x1199, 0x9070)}, /* Sierra Wireless MC74xx */
{DEVICE_SWI(0x1199, 0x9071)}, /* Sierra Wireless MC74xx */


2020-08-10 16:38:37

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 06/48] ALSA: seq: oss: Serialize ioctls

Hi!

> commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
>
> Some ioctls via OSS sequencer API may race and lead to UAF when the
> port create and delete are performed concurrently, as spotted by a
> couple of syzkaller cases. This patch is an attempt to address it by
> serializing the ioctls with the existing register_mutex.
>
> Basically OSS sequencer API is an obsoleted interface and was designed
> without much consideration of the concurrency. There are very few
> applications with it, and the concurrent performance isn't asked,
> hence this "big hammer" approach should be good enough.

That really is a "big hammer". And I believe it is too big.

In particular, do we need to drop the lock while sleeping in
SNDCTL_SEQ_SYNC: => snd_seq_oss_writeq_sync ?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (975.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-08-10 16:39:58

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 14/48] mtd: properly check all write ioctls for permissions

Hi!

> From: Greg Kroah-Hartman <[email protected]>
>
> commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream.
>
> When doing a "write" ioctl call, properly check that we have permissions
> to do so before copying anything from userspace or anything else so we
> can "fail fast". This includes also covering the MEMWRITE ioctl which
> previously missed checking for this.

> + /* "safe" commands */
> + case MEMGETREGIONCOUNT:

I wonder if MEMSETBADBLOCK, MEMLOCK/MEMUNLOCK, BLKPG, OTPLOCK and
MTDFILEMODE should be in the list of "safe" commands? Sounds like they
can do at least as much damage as average MEMWRITE...

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (830.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-08-10 16:43:14

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 25/48] firmware: Fix a reference count leak.

Hi!

> From: Qiushi Wu <[email protected]>
>
> [ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ]
>
> kobject_init_and_add() takes reference even when it fails.
> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object.
> Callback function fw_cfg_sysfs_release_entry() in kobject_put()
> can handle the pointer "entry" properly.

Okay, but... does that mean err_add_raw: should be using
kobject_put(), too (w/o the kfree)? It is strange to have different
error handling for different error paths.

Best regards,
Pavel

> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -605,8 +605,10 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f)
> /* register entry under "/sys/firmware/qemu_fw_cfg/by_key/" */
> err = kobject_init_and_add(&entry->kobj, &fw_cfg_sysfs_entry_ktype,
> fw_cfg_sel_ko, "%d", entry->select);
> - if (err)
> - goto err_register;
> + if (err) {
> + kobject_put(&entry->kobj);
> + return err;
> + }
>
> /* add raw binary content access */
> err = sysfs_create_bin_file(&entry->kobj, &fw_cfg_sysfs_attr_raw);
> @@ -622,7 +624,6 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f)
>
> err_add_raw:
> kobject_del(&entry->kobj);
> -err_register:
> kfree(entry);
> return err;
> }

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (1.48 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-08-10 17:32:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 06/48] ALSA: seq: oss: Serialize ioctls

On Mon, Aug 10, 2020 at 06:37:17PM +0200, Pavel Machek wrote:
> Hi!
>
> > commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
> >
> > Some ioctls via OSS sequencer API may race and lead to UAF when the
> > port create and delete are performed concurrently, as spotted by a
> > couple of syzkaller cases. This patch is an attempt to address it by
> > serializing the ioctls with the existing register_mutex.
> >
> > Basically OSS sequencer API is an obsoleted interface and was designed
> > without much consideration of the concurrency. There are very few
> > applications with it, and the concurrent performance isn't asked,
> > hence this "big hammer" approach should be good enough.
>
> That really is a "big hammer". And I believe it is too big.

Please discuss code architecture decisions on the mailing list for the
subsystem/patch. Doing it in random stable backports does not help out
as all of the developers involved are not copied here.

thanks,

greg k-h

2020-08-10 17:56:00

by Takashi Iwai

[permalink] [raw]
Subject: Re: [PATCH 4.19 06/48] ALSA: seq: oss: Serialize ioctls

On Mon, 10 Aug 2020 18:37:17 +0200,
Pavel Machek wrote:
>
> Hi!
>
> > commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
> >
> > Some ioctls via OSS sequencer API may race and lead to UAF when the
> > port create and delete are performed concurrently, as spotted by a
> > couple of syzkaller cases. This patch is an attempt to address it by
> > serializing the ioctls with the existing register_mutex.
> >
> > Basically OSS sequencer API is an obsoleted interface and was designed
> > without much consideration of the concurrency. There are very few
> > applications with it, and the concurrent performance isn't asked,
> > hence this "big hammer" approach should be good enough.
>
> That really is a "big hammer". And I believe it is too big.
>
> In particular, do we need to drop the lock while sleeping in
> SNDCTL_SEQ_SYNC: => snd_seq_oss_writeq_sync ?

Well, do you see any issue with this for really used applications?
If yes, I'd happily take a look and give finer locking.


thanks,

Takashi

2020-08-10 18:43:47

by Richard Weinberger

[permalink] [raw]
Subject: Re: [PATCH 4.19 14/48] mtd: properly check all write ioctls for permissions

----- Ursprüngliche Mail -----
> Von: "Pavel Machek" <[email protected]>
>> When doing a "write" ioctl call, properly check that we have permissions
>> to do so before copying anything from userspace or anything else so we
>> can "fail fast". This includes also covering the MEMWRITE ioctl which
>> previously missed checking for this.
>
>> + /* "safe" commands */
>> + case MEMGETREGIONCOUNT:
>
> I wonder if MEMSETBADBLOCK, MEMLOCK/MEMUNLOCK, BLKPG, OTPLOCK and
> MTDFILEMODE should be in the list of "safe" commands? Sounds like they
> can do at least as much damage as average MEMWRITE...

Most of the ioctls you listed are not write-exclusive because existing
user space applications (such as mtd-utils) issue them on a read-only fd.
So, we didn't want to break them.
Before we move such an ioctl to the "non-safe" list, common user space needs to
be inspected. This includes, android, openwrt, mtd-utils, etc...

On the other hand, this is a raw mtd, it is hard to draw the line.
For NAND even reading allows an attacker doing harm, she can trigger read-distrurb
super efficiently using the read ioctl...

So passing an mtdchar fd (no matter whether read or write mode) to untrusted
entities is a bad idea.

Thanks,
//richard

2020-08-10 23:14:11

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/48] 4.19.139-rc1 review

On 8/10/20 9:21 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.139 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 12 Aug 2020 15:17:47 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.139-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah

2020-08-11 08:29:21

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/48] 4.19.139-rc1 review

On Mon, 10 Aug 2020 at 21:00, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.139 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 12 Aug 2020 15:17:47 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.139-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
Regressions on x86_64.

We have added LTP tracing test suite this week and started noticing
kernel BUG on x86_64 KASAN enabled kernel. Which means this issue might not be
specific to this release candidate.

[ 90.134426] ==================================================================
[ 90.141651] BUG: KASAN: use-after-free in trace_stack_print+0x133/0x150
[ 90.148264] Read of size 8 at addr ffff888228015ffc by task cat/3569
[ 90.154613]
[ 90.156106] CPU: 3 PID: 3569 Comm: cat Not tainted 4.19.139-rc1 #1
[ 90.162278] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 90.169669] Call Trace:
[ 90.172115] dump_stack+0x7d/0xaa
[ 90.175463] print_address_description+0x67/0x229
[ 90.180165] ? trace_stack_print+0x133/0x150
[ 90.184460] kasan_report.cold+0xae/0x2fe
[ 90.188469] __asan_load8+0x54/0x90
[ 90.191959] trace_stack_print+0x133/0x150
[ 90.196051] print_trace_line+0x3c7/0x930
[ 90.200063] ? tracing_buffers_read+0x310/0x310
[ 90.204589] tracing_read_pipe+0x2db/0x530
[ 90.208687] __vfs_read+0xe5/0x3c0
[ 90.212093] ? __x64_sys_copy_file_range+0x360/0x360
[ 90.217059] ? fsnotify+0x7cb/0x7f0
[ 90.220550] ? _cond_resched+0x14/0x30
[ 90.224296] ? __inode_security_revalidate+0x5d/0x70
[ 90.229262] ? avc_policy_seqno+0x21/0x30
[ 90.233273] ? security_file_permission+0xc6/0xf0
[ 90.237970] ? security_file_permission+0xc6/0xf0
[ 90.242667] ? rw_verify_area+0x73/0x140
[ 90.246584] vfs_read+0xc8/0x1d0
[ 90.249808] ksys_read+0xbb/0x170
[ 90.253120] ? kernel_write+0xa0/0xa0
[ 90.256786] ? __audit_syscall_exit+0x3bb/0x430
[ 90.261320] __x64_sys_read+0x3e/0x50
[ 90.264985] do_syscall_64+0x63/0x160
[ 90.268649] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 90.273693] RIP: 0033:0x7f9596d9e071
[ 90.277266] Code: fe ff ff 48 8d 3d 3f 71 09 00 48 83 ec 08 e8 26
ee 01 00 66 0f 1f 44 00 00 48 8d 05 91 e8 2c 00 8b 00 85 c0 75 13 31
c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 41 54 49 89 d4
55 48
[ 90.296011] RSP: 002b:00007ffee5028688 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 90.303575] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f9596d9e071
[ 90.310699] RDX: 0000000000020000 RSI: 00007f9597269000 RDI: 0000000000000006
[ 90.317823] RBP: 0000000000020000 R08: 00000000ffffffff R09: 0000000000000000
[ 90.324947] R10: 00000000000008c6 R11: 0000000000000246 R12: 00007f9597269000
[ 90.332071] R13: 0000000000000006 R14: 0000000000000f8e R15: 0000000000020000
[ 90.339194]
[ 90.340684] The buggy address belongs to the page:
[ 90.345470] page:ffffea0008a00540 count:1 mapcount:0
mapping:0000000000000000 index:0x0
[ 90.353461] flags: 0x200000000000000()
[ 90.357215] raw: 0200000000000000 dead000000000100 dead000000000200
0000000000000000
[ 90.364952] raw: 0000000000000000 0000000000000000 00000001ffffffff
0000000000000000
[ 90.372681] page dumped because: kasan: bad access detected
[ 90.378245]
[ 90.379736] Memory state around the buggy address:
[ 90.384523] ffff888228015f00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 90.391741] ffff888228015f80: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 90.398951] >ffff888228016000: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 90.406161] ^
[ 90.409407] ffff888228016080: fc fc fc fc fc fc fc fc fb fb fb fb
fb fb fb fb
[ 90.416665] ffff888228016100: fb fb fb fb fb fb fb fb fc fc fc fc
fc fc fc fc
[ 90.423876] ==================================================================
[ 90.431095] Disabling lock debugging due to kernel taint


steps to reproduce:
- boot x86_64 with kasan enabled 4.19 stable kernel
- cd /opt/ltp
- ./runltp -f tracing

Full test log link,
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.138-49-gb0e1bc72f7dd/testrun/3050053/suite/linux-log-parser/test/check-kernel-bug-1656536/log

kernel-config link,
https://builds.tuxbuild.com/BDfU1nbOpLG7hFIf-nv5dQ/kernel.config

Summary
------------------------------------------------------------------------

kernel: 4.19.139-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: b0e1bc72f7ddff40c7c5b68313d3ac76495d678d
git describe: v4.19.138-49-gb0e1bc72f7dd
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.138-49-gb0e1bc72f7dd

No fixes (compared to build v4.19.138)


Ran 34683 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kvm-unit-tests
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* v4l2-compliance
* ltp-commands-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-math-tests
* network-basic-tests
* perf
* libhugetlbfs
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-open-posix-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net

--
Linaro LKFT
https://lkft.linaro.org

2020-08-11 08:33:17

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/48] 4.19.139-rc1 review

On Mon 2020-08-10 17:21:22, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.139 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 12 Aug 2020 15:17:47 +0000.
> Anything received after that time might be too late.

No problems detected in -cip testing:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/176251340

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (717.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-08-11 12:47:50

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 47/48] i40e: Memory leak in i40e_config_iwarp_qvlist

Hi!

> From: Martyna Szapar <[email protected]>
>
> [ Upstream commit 0b63644602cfcbac849f7ea49272a39e90fa95eb ]
>
> Added freeing the old allocation of vf->qvlist_info in function
> i40e_config_iwarp_qvlist before overwriting it with
> the new allocation.

Ok, but this also other error paths:

> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> @@ -449,16 +450,19 @@ static int i40e_config_iwarp_qvlist(stru
> "Incorrect number of iwarp vectors %u. Maximum %u allowed.\n",
> qvlist_info->num_vectors,
> msix_vf);
> - goto err;
> + ret = -EINVAL;
> + goto err_out;
> }

And it is no longer freeing data qvlist_info() in this path. Is that
correct? Should it goto err_free instead?

> @@ -512,10 +518,11 @@ static int i40e_config_iwarp_qvlist(stru
> }
>
> return 0;
> -err:
> +err_free:
> kfree(vf->qvlist_info);
> vf->qvlist_info = NULL;
> - return -EINVAL;
> +err_out:
> + return ret;
> }

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (1.18 kB)
signature.asc (201.00 B)
Download all attachments

2020-08-11 14:24:22

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/48] 4.19.139-rc1 review

On Mon, Aug 10, 2020 at 05:21:22PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.139 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 12 Aug 2020 15:17:47 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 421 pass: 421 fail: 0

Guenter

2020-08-11 16:46:18

by Jesse Brandeburg

[permalink] [raw]
Subject: Re: [PATCH 4.19 47/48] i40e: Memory leak in i40e_config_iwarp_qvlist

On Tue, 11 Aug 2020 14:46:14 +0200
Pavel Machek <[email protected]> wrote:

> > --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > @@ -449,16 +450,19 @@ static int i40e_config_iwarp_qvlist(stru
> > "Incorrect number of iwarp vectors %u.
> > Maximum %u allowed.\n", qvlist_info->num_vectors,
> > msix_vf);
> > - goto err;
> > + ret = -EINVAL;
> > + goto err_out;
> > }
>
> And it is no longer freeing data qvlist_info() in this path. Is that
> correct? Should it goto err_free instead?

Hi Pavel, thanks for the review.

I believe it is still correct, the logic is a bit convoluted, but
tracing back, I see that the caller in i40e_main.c allocates a buffer,
calls this function (eventually) with that memory cast to the *input*
variable qvlist_info, and then the top caller frees the original buffer.

One thing that I'll admit is confusing here is that the *input* struct
qvlist_info is different than the vf->qvlist_info struct managed by
this function. Maybe that they have the same name was confusing to you?
It confused me for a moment while I investigated, but I believe there
is no actual problem.

The reason for the function working this way is that the input data is
from the VF message, and the driver data structures in the PF (i40e)
driver representing state of the VF are managed separately.

Jesse