2020-12-06 11:47:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 00/39] 5.4.82-rc1 review

This is the start of the stable review cycle for the 5.4.82 release.
There are 39 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 Tue, 08 Dec 2020 11:15:42 +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/v5.x/stable-review/patch-5.4.82-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-5.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Shiraz Saleem <[email protected]>
RDMA/i40iw: Address an mmap handler exploit in i40iw

Vasily Averin <[email protected]>
tracing: Remove WARN_ON in start_thread()

Po-Hsu Lin <[email protected]>
Input: i8042 - add ByteSpeed touchpad to noloop table

Sanjay Govind <[email protected]>
Input: xpad - support Ardwiino Controllers

Hector Martin <[email protected]>
ALSA: usb-audio: US16x08: fix value count for level meters

Eran Ben Elisha <[email protected]>
net/mlx5: Fix wrong address reclaim when command interface is down

Yevgeny Kliteynik <[email protected]>
net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering

Davide Caratti <[email protected]>
net/sched: act_mpls: ensure LSE is pullable before reading it

Davide Caratti <[email protected]>
net: openvswitch: ensure LSE is pullable before reading it

Davide Caratti <[email protected]>
net: skbuff: ensure LSE is pullable before decrementing the MPLS ttl

Wang Hai <[email protected]>
net: mvpp2: Fix error return code in mvpp2_open()

Dan Carpenter <[email protected]>
chelsio/chtls: fix a double free in chtls_setkey()

Zhang Changzhong <[email protected]>
vxlan: fix error return code in __vxlan_dev_create()

Zhang Changzhong <[email protected]>
net: pasemi: fix error return code in pasemi_mac_open()

Zhang Changzhong <[email protected]>
cxgb3: fix error return code in t3_sge_alloc_qset()

Dan Carpenter <[email protected]>
net/x25: prevent a couple of overflows

Antoine Tenart <[email protected]>
net: ip6_gre: set dev->hard_header_len when using header_ops

Eric Dumazet <[email protected]>
geneve: pull IP header before ECN decapsulation

Toke Høiland-Jørgensen <[email protected]>
inet_ecn: Fix endianness of checksum update when setting ECT(1)

Thomas Falcon <[email protected]>
ibmvnic: Fix TX completion error handling

Thomas Falcon <[email protected]>
ibmvnic: Ensure that SCRQ entry reads are correctly ordered

Vinay Kumar Yadav <[email protected]>
chelsio/chtls: fix panic during unload reload chtls

Krzysztof Kozlowski <[email protected]>
dt-bindings: net: correct interrupt flags in examples

Guillaume Nault <[email protected]>
ipv4: Fix tos mask in inet_rtm_getroute()

Antoine Tenart <[email protected]>
netfilter: bridge: reset skb->pkt_type after NF_INET_POST_ROUTING traversal

Vincent Guittot <[email protected]>
sched/fair: Fix unthrottle_cfs_rq() for leaf_cfs_rq list

Maurizio Drocco <[email protected]>
ima: extend boot_aggregate with kernel measurements

Randy Dunlap <[email protected]>
staging/octeon: fix up merge error

Jamie Iles <[email protected]>
bonding: wait for sysfs kobject destruction before freeing struct slave

Yves-Alexis Perez <[email protected]>
usbnet: ipheth: fix connectivity with iOS 14

Jens Axboe <[email protected]>
tun: honor IOCB_NOWAIT flag

Alexander Duyck <[email protected]>
tcp: Set INET_ECN_xmit configuration in tcp_reinit_congestion_control

Willem de Bruijn <[email protected]>
sock: set sk_err to ee_errno on dequeue from errq

Anmol Karn <[email protected]>
rose: Fix Null pointer dereference in rose_send_frame()

Maxim Mikityanskiy <[email protected]>
net/tls: Protect from calling tls_dev_del for TLS RX twice

Vadim Fedorenko <[email protected]>
net/tls: missing received data after fast remote close

Julian Wiedmann <[email protected]>
net/af_iucv: set correct sk_protocol for child sockets

Wang Hai <[email protected]>
ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init

Parav Pandit <[email protected]>
devlink: Hold rtnl lock while reading netdev attributes


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

Diffstat:

.../devicetree/bindings/net/can/tcan4x5x.txt | 2 +-
.../devicetree/bindings/net/nfc/nxp-nci.txt | 2 +-
.../devicetree/bindings/net/nfc/pn544.txt | 2 +-
Makefile | 4 +-
drivers/crypto/chelsio/chtls/chtls_cm.c | 1 +
drivers/crypto/chelsio/chtls/chtls_hw.c | 1 +
drivers/infiniband/hw/i40iw/i40iw_main.c | 5 --
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 36 +++----------
drivers/input/joystick/xpad.c | 2 +
drivers/input/serio/i8042-x86ia64io.h | 4 ++
drivers/net/bonding/bond_main.c | 61 +++++++++++++++-------
drivers/net/bonding/bond_sysfs_slave.c | 18 +------
drivers/net/ethernet/chelsio/cxgb3/sge.c | 1 +
drivers/net/ethernet/ibm/ibmvnic.c | 22 ++++++--
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
.../net/ethernet/mellanox/mlx5/core/pagealloc.c | 21 +++++++-
.../ethernet/mellanox/mlx5/core/steering/dr_cmd.c | 1 +
.../mellanox/mlx5/core/steering/dr_domain.c | 5 ++
.../mellanox/mlx5/core/steering/dr_types.h | 1 +
drivers/net/ethernet/pasemi/pasemi_mac.c | 8 ++-
drivers/net/geneve.c | 20 +++++--
drivers/net/tun.c | 14 +++--
drivers/net/usb/ipheth.c | 2 +-
drivers/net/vxlan.c | 4 +-
drivers/staging/octeon/ethernet-tx.c | 2 +-
include/linux/mlx5/mlx5_ifc.h | 9 +++-
include/net/bonding.h | 8 +++
include/net/inet_ecn.h | 2 +-
include/net/tls.h | 6 +++
kernel/sched/fair.c | 36 ++++++++++---
kernel/trace/trace_hwlat.c | 2 +-
net/bridge/br_netfilter_hooks.c | 7 ++-
net/core/devlink.c | 4 ++
net/core/skbuff.c | 5 +-
net/ipv4/route.c | 7 +--
net/ipv4/tcp_cong.c | 5 ++
net/ipv6/addrlabel.c | 26 +++++----
net/ipv6/ip6_gre.c | 16 ++++--
net/iucv/af_iucv.c | 4 +-
net/openvswitch/actions.c | 3 ++
net/rose/rose_loopback.c | 17 ++++--
net/sched/act_mpls.c | 3 ++
net/tls/tls_device.c | 5 +-
net/tls/tls_sw.c | 6 +++
net/x25/af_x25.c | 6 ++-
security/integrity/ima/ima.h | 2 +-
security/integrity/ima/ima_crypto.c | 15 +++++-
sound/usb/mixer_us16x08.c | 2 +-
48 files changed, 304 insertions(+), 132 deletions(-)



2020-12-06 11:47:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 22/39] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet <[email protected]>

[ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ]

IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.

geneve does not ensure this yet.

Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since callers
pass a pointer that might be freed by pskb_may_pull()

syzbot reported :

BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline]
BUG: KMSAN: uninit-value in INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260
CPU: 1 PID: 8941 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197
__INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline]
INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260
geneve_rx+0x2103/0x2980 include/net/inet_ecn.h:306
geneve_udp_encap_recv+0x105c/0x1340 drivers/net/geneve.c:377
udp_queue_rcv_one_skb+0x193a/0x1af0 net/ipv4/udp.c:2093
udp_queue_rcv_skb+0x282/0x1050 net/ipv4/udp.c:2167
udp_unicast_rcv_skb net/ipv4/udp.c:2325 [inline]
__udp4_lib_rcv+0x399d/0x5880 net/ipv4/udp.c:2394
udp_rcv+0x5c/0x70 net/ipv4/udp.c:2564
ip_protocol_deliver_rcu+0x572/0xc50 net/ipv4/ip_input.c:204
ip_local_deliver_finish net/ipv4/ip_input.c:231 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ip_local_deliver+0x583/0x8d0 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish net/ipv4/ip_input.c:428 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ip_rcv+0x5c3/0x840 net/ipv4/ip_input.c:539
__netif_receive_skb_one_core net/core/dev.c:5315 [inline]
__netif_receive_skb+0x1ec/0x640 net/core/dev.c:5429
process_backlog+0x523/0xc10 net/core/dev.c:6319
napi_poll+0x420/0x1010 net/core/dev.c:6763
net_rx_action+0x35c/0xd40 net/core/dev.c:6833
__do_softirq+0x1a9/0x6fa kernel/softirq.c:298
asm_call_irq_on_stack+0xf/0x20
</IRQ>
__run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
do_softirq_own_stack+0x6e/0x90 arch/x86/kernel/irq_64.c:77
do_softirq kernel/softirq.c:343 [inline]
__local_bh_enable_ip+0x184/0x1d0 kernel/softirq.c:195
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:730 [inline]
__dev_queue_xmit+0x3a9b/0x4520 net/core/dev.c:4167
dev_queue_xmit+0x4b/0x60 net/core/dev.c:4173
packet_snd net/packet/af_packet.c:2992 [inline]
packet_sendmsg+0x86f9/0x99d0 net/packet/af_packet.c:3017
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg net/socket.c:671 [inline]
__sys_sendto+0x9dc/0xc80 net/socket.c:1992
__do_sys_sendto net/socket.c:2004 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:2000
__x64_sys_sendto+0x6e/0x90 net/socket.c:2000
do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/geneve.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -254,11 +254,21 @@ static void geneve_rx(struct geneve_dev
skb_dst_set(skb, &tun_dst->dst);

/* Ignore packet loops (and multicast echo) */
- if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr)) {
- geneve->dev->stats.rx_errors++;
- goto drop;
- }
+ if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr))
+ goto rx_error;

+ switch (skb_protocol(skb, true)) {
+ case htons(ETH_P_IP):
+ if (pskb_may_pull(skb, sizeof(struct iphdr)))
+ goto rx_error;
+ break;
+ case htons(ETH_P_IPV6):
+ if (pskb_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto rx_error;
+ break;
+ default:
+ goto rx_error;
+ }
oiph = skb_network_header(skb);
skb_reset_network_header(skb);

@@ -299,6 +309,8 @@ static void geneve_rx(struct geneve_dev
u64_stats_update_end(&stats->syncp);
}
return;
+rx_error:
+ geneve->dev->stats.rx_errors++;
drop:
/* Consume bad packet */
kfree_skb(skb);


2020-12-06 11:47:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 23/39] net: ip6_gre: set dev->hard_header_len when using header_ops

From: Antoine Tenart <[email protected]>

[ Upstream commit 832ba596494b2c9eac7760259eff2d8b7dcad0ee ]

syzkaller managed to crash the kernel using an NBMA ip6gre interface. I
could reproduce it creating an NBMA ip6gre interface and forwarding
traffic to it:

skbuff: skb_under_panic: text:ffffffff8250e927 len:148 put:44 head:ffff8c03c7a33
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:109!
Call Trace:
skb_push+0x10/0x10
ip6gre_header+0x47/0x1b0
neigh_connected_output+0xae/0xf0

ip6gre tunnel provides its own header_ops->create, and sets it
conditionally when initializing the tunnel in NBMA mode. When
header_ops->create is used, dev->hard_header_len should reflect the
length of the header created. Otherwise, when not used,
dev->needed_headroom should be used.

Fixes: eb95f52fc72d ("net: ipv6_gre: Fix GRO to work on IPv6 over GRE tap")
Cc: Maria Pasechnik <[email protected]>
Signed-off-by: Antoine Tenart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_gre.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1120,8 +1120,13 @@ static void ip6gre_tnl_link_config_route
return;

if (rt->dst.dev) {
- dev->needed_headroom = rt->dst.dev->hard_header_len +
- t_hlen;
+ unsigned short dst_len = rt->dst.dev->hard_header_len +
+ t_hlen;
+
+ if (t->dev->header_ops)
+ dev->hard_header_len = dst_len;
+ else
+ dev->needed_headroom = dst_len;

if (set_mtu) {
dev->mtu = rt->dst.dev->mtu - t_hlen;
@@ -1146,7 +1151,12 @@ static int ip6gre_calc_hlen(struct ip6_t
tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen;

t_hlen = tunnel->hlen + sizeof(struct ipv6hdr);
- tunnel->dev->needed_headroom = LL_MAX_HEADER + t_hlen;
+
+ if (tunnel->dev->header_ops)
+ tunnel->dev->hard_header_len = LL_MAX_HEADER + t_hlen;
+ else
+ tunnel->dev->needed_headroom = LL_MAX_HEADER + t_hlen;
+
return t_hlen;
}



2020-12-06 11:47:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 21/39] inet_ecn: Fix endianness of checksum update when setting ECT(1)

From: "Toke H?iland-J?rgensen" <[email protected]>

[ Upstream commit 2867e1eac61016f59b3d730e3f7aa488e186e917 ]

When adding support for propagating ECT(1) marking in IP headers it seems I
suffered from endianness-confusion in the checksum update calculation: In
fact the ECN field is in the *lower* bits of the first 16-bit word of the
IP header when calculating in network byte order. This means that the
addition performed to update the checksum field was wrong; let's fix that.

Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040")
Reported-by: Jonathan Morton <[email protected]>
Tested-by: Pete Heist <[email protected]>
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/inet_ecn.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/inet_ecn.h
+++ b/include/net/inet_ecn.h
@@ -107,7 +107,7 @@ static inline int IP_ECN_set_ect1(struct
if ((iph->tos & INET_ECN_MASK) != INET_ECN_ECT_0)
return 0;

- check += (__force u16)htons(0x100);
+ check += (__force u16)htons(0x1);

iph->check = (__force __sum16)(check + (check>=0xFFFF));
iph->tos ^= INET_ECN_MASK;


2020-12-06 11:47:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 26/39] net: pasemi: fix error return code in pasemi_mac_open()

From: Zhang Changzhong <[email protected]>

[ Upstream commit aba84871bd4f52c4dfcf3ad5d4501a6c9d2de90e ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 72b05b9940f0 ("pasemi_mac: RX/TX ring management cleanup")
Fixes: 8d636d8bc5ff ("pasemi_mac: jumbo frame support")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Changzhong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/pasemi/pasemi_mac.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1078,16 +1078,20 @@ static int pasemi_mac_open(struct net_de

mac->tx = pasemi_mac_setup_tx_resources(dev);

- if (!mac->tx)
+ if (!mac->tx) {
+ ret = -ENOMEM;
goto out_tx_ring;
+ }

/* We might already have allocated rings in case mtu was changed
* before interface was brought up.
*/
if (dev->mtu > 1500 && !mac->num_cs) {
pasemi_mac_setup_csrings(mac);
- if (!mac->num_cs)
+ if (!mac->num_cs) {
+ ret = -ENOMEM;
goto out_tx_ring;
+ }
}

/* Zero out rmon counters */


2020-12-06 11:47:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 24/39] net/x25: prevent a couple of overflows

From: Dan Carpenter <[email protected]>

[ Upstream commit 6ee50c8e262a0f0693dad264c3c99e30e6442a56 ]

The .x25_addr[] address comes from the user and is not necessarily
NUL terminated. This leads to a couple problems. The first problem is
that the strlen() in x25_bind() can read beyond the end of the buffer.

The second problem is more subtle and could result in memory corruption.
The call tree is:
x25_connect()
--> x25_write_internal()
--> x25_addr_aton()

The .x25_addr[] buffers are copied to the "addresses" buffer from
x25_write_internal() so it will lead to stack corruption.

Verify that the strings are NUL terminated and return -EINVAL if they
are not.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters")
Reported-by: "kiyin(尹亮)" <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Martin Schiller <[email protected]>
Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/x25/af_x25.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -675,7 +675,8 @@ static int x25_bind(struct socket *sock,
int len, i, rc = 0;

if (addr_len != sizeof(struct sockaddr_x25) ||
- addr->sx25_family != AF_X25) {
+ addr->sx25_family != AF_X25 ||
+ strnlen(addr->sx25_addr.x25_addr, X25_ADDR_LEN) == X25_ADDR_LEN) {
rc = -EINVAL;
goto out;
}
@@ -769,7 +770,8 @@ static int x25_connect(struct socket *so

rc = -EINVAL;
if (addr_len != sizeof(struct sockaddr_x25) ||
- addr->sx25_family != AF_X25)
+ addr->sx25_family != AF_X25 ||
+ strnlen(addr->sx25_addr.x25_addr, X25_ADDR_LEN) == X25_ADDR_LEN)
goto out;

rc = -ENETUNREACH;


2020-12-06 11:47:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 35/39] ALSA: usb-audio: US16x08: fix value count for level meters

From: Hector Martin <[email protected]>

commit 402d5840b0d40a2a26c8651165d29b534abb6d36 upstream.

The level meter control returns 34 integers of info. This fixes:

snd-usb-audio 3-1:1.0: control 2:0:0:Level Meter:0: access overflow

Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk")
Cc: [email protected]
Signed-off-by: Hector Martin <[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/usb/mixer_us16x08.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/usb/mixer_us16x08.c
+++ b/sound/usb/mixer_us16x08.c
@@ -607,7 +607,7 @@ static int snd_us16x08_eq_put(struct snd
static int snd_us16x08_meter_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
- uinfo->count = 1;
+ uinfo->count = 34;
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->value.integer.max = 0x7FFF;
uinfo->value.integer.min = 0;


2020-12-06 11:47:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 32/39] net/sched: act_mpls: ensure LSE is pullable before reading it

From: Davide Caratti <[email protected]>

[ Upstream commit 9608fa653059c3f72faab0c148ac8773c46e7314 ]

when 'act_mpls' is used to mangle the LSE, the current value is read from
the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is
contained in the skb "linear" area.

Found by code inspection.

v2:
- use MPLS_HLEN instead of sizeof(new_lse), thanks to Jakub Kicinski

Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
Signed-off-by: Davide Caratti <[email protected]>
Acked-by: Guillaume Nault <[email protected]>
Link: https://lore.kernel.org/r/3243506cba43d14858f3bd21ee0994160e44d64a.1606987058.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/act_mpls.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/sched/act_mpls.c
+++ b/net/sched/act_mpls.c
@@ -88,6 +88,9 @@ static int tcf_mpls_act(struct sk_buff *
goto drop;
break;
case TCA_MPLS_ACT_MODIFY:
+ if (!pskb_may_pull(skb,
+ skb_network_offset(skb) + MPLS_HLEN))
+ goto drop;
new_lse = tcf_mpls_get_lse(mpls_hdr(skb), p, false);
if (skb_mpls_update_lse(skb, new_lse))
goto drop;


2020-12-06 11:48:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 33/39] net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering

From: Yevgeny Kliteynik <[email protected]>

[ Upstream commit d421e466c2373095f165ddd25cbabd6c5b077928 ]

STEs format for Connect-X5 and Connect-X6DX different. Currently, on
Connext-X6DX the SW steering would break at some point when building STEs
w/o giving a proper error message. Fix this by checking the STE format of
the current device when initializing domain: add mlx5_ifc definitions for
Connect-X6DX SW steering, read FW capability to get the current format
version, and check this version when domain is being created.

Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities")
Signed-off-by: Yevgeny Kliteynik <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c | 5 +++++
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h | 1 +
include/linux/mlx5/mlx5_ifc.h | 9 ++++++++-
4 files changed, 15 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
@@ -92,6 +92,7 @@ int mlx5dr_cmd_query_device(struct mlx5_
caps->eswitch_manager = MLX5_CAP_GEN(mdev, eswitch_manager);
caps->gvmi = MLX5_CAP_GEN(mdev, vhca_id);
caps->flex_protocols = MLX5_CAP_GEN(mdev, flex_parser_protocols);
+ caps->sw_format_ver = MLX5_CAP_GEN(mdev, steering_format_version);

if (mlx5dr_matcher_supp_flex_parser_icmp_v4(caps)) {
caps->flex_parser_id_icmp_dw0 = MLX5_CAP_GEN(mdev, flex_parser_id_icmp_dw0);
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c
@@ -223,6 +223,11 @@ static int dr_domain_caps_init(struct ml
if (ret)
return ret;

+ if (dmn->info.caps.sw_format_ver != MLX5_STEERING_FORMAT_CONNECTX_5) {
+ mlx5dr_err(dmn, "SW steering is not supported on this device\n");
+ return -EOPNOTSUPP;
+ }
+
ret = dr_domain_query_fdb_caps(mdev, dmn);
if (ret)
return ret;
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h
@@ -613,6 +613,7 @@ struct mlx5dr_cmd_caps {
u8 max_ft_level;
u16 roce_min_src_udp;
u8 num_esw_ports;
+ u8 sw_format_ver;
bool eswitch_manager;
bool rx_sw_owner;
bool tx_sw_owner;
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1139,6 +1139,11 @@ enum mlx5_fc_bulk_alloc_bitmask {

#define MLX5_FC_BULK_NUM_FCS(fc_enum) (MLX5_FC_BULK_SIZE_FACTOR * (fc_enum))

+enum {
+ MLX5_STEERING_FORMAT_CONNECTX_5 = 0,
+ MLX5_STEERING_FORMAT_CONNECTX_6DX = 1,
+};
+
struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_0[0x30];
u8 vhca_id[0x10];
@@ -1419,7 +1424,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {

u8 general_obj_types[0x40];

- u8 reserved_at_440[0x20];
+ u8 reserved_at_440[0x4];
+ u8 steering_format_version[0x4];
+ u8 create_qp_start_hint[0x18];

u8 reserved_at_460[0x3];
u8 log_max_uctx[0x5];


2020-12-06 11:48:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 36/39] Input: xpad - support Ardwiino Controllers

From: Sanjay Govind <[email protected]>

commit 2aab1561439032be2e98811dd0ddbeb5b2ae4c61 upstream.

This commit adds support for Ardwiino Controllers

Signed-off-by: Sanjay Govind <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -241,6 +241,7 @@ static const struct xpad_device {
{ 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
+ { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0303, "Mortal Kombat Klassic FightStick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
@@ -418,6 +419,7 @@ static const struct usb_device_id xpad_t
XPAD_XBOXONE_VENDOR(0x0f0d), /* Hori Controllers */
XPAD_XBOX360_VENDOR(0x1038), /* SteelSeries Controllers */
XPAD_XBOX360_VENDOR(0x11c9), /* Nacon GC100XF */
+ XPAD_XBOX360_VENDOR(0x1209), /* Ardwiino Controllers */
XPAD_XBOX360_VENDOR(0x12ab), /* X-Box 360 dance pads */
XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x146b), /* BigBen Interactive Controllers */


2020-12-06 11:48:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 38/39] tracing: Remove WARN_ON in start_thread()

From: Vasily Averin <[email protected]>

commit 310e3a4b5a4fc718a72201c1e4cf5c64ac6f5442 upstream.

This patch reverts commit 978defee11a5 ("tracing: Do a WARN_ON()
if start_thread() in hwlat is called when thread exists")

.start hook can be legally called several times if according
tracer is stopped

screen window 1
[root@localhost ~]# echo 1 > /sys/kernel/tracing/events/kmem/kfree/enable
[root@localhost ~]# echo 1 > /sys/kernel/tracing/options/pause-on-trace
[root@localhost ~]# less -F /sys/kernel/tracing/trace

screen window 2
[root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on
0
[root@localhost ~]# echo hwlat > /sys/kernel/debug/tracing/current_tracer
[root@localhost ~]# echo 1 > /sys/kernel/debug/tracing/tracing_on
[root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on
0
[root@localhost ~]# echo 2 > /sys/kernel/debug/tracing/tracing_on

triggers warning in dmesg:
WARNING: CPU: 3 PID: 1403 at kernel/trace/trace_hwlat.c:371 hwlat_tracer_start+0xc9/0xd0

Link: https://lkml.kernel.org/r/[email protected]

Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Fixes: 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists")
Signed-off-by: Vasily Averin <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/trace/trace_hwlat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace_hwlat.c
+++ b/kernel/trace/trace_hwlat.c
@@ -355,7 +355,7 @@ static int start_kthread(struct trace_ar
struct task_struct *kthread;
int next_cpu;

- if (WARN_ON(hwlat_kthread))
+ if (hwlat_kthread)
return 0;

/* Just pick the first CPU on first iteration */


2020-12-06 11:48:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 37/39] Input: i8042 - add ByteSpeed touchpad to noloop table

From: Po-Hsu Lin <[email protected]>

commit a48491c65b513e5cdc3e7a886a4db915f848a5f5 upstream.

It looks like the C15B laptop got another vendor: ByteSpeed LLC.

Avoid AUX loopback on this touchpad as well, thus input subsystem will
be able to recognize a Synaptics touchpad in the AUX port.

BugLink: https://bugs.launchpad.net/bugs/1906128
Signed-off-by: Po-Hsu Lin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/serio/i8042-x86ia64io.h | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -219,6 +219,10 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
},
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ByteSpeed LLC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ByteSpeed Laptop C15B"),
+ },
},
{ }
};


2020-12-06 11:48:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 29/39] net: mvpp2: Fix error return code in mvpp2_open()

From: Wang Hai <[email protected]>

[ Upstream commit 82a10dc7f0960735f40e8d7d3bee56934291600f ]

Fix to return negative error code -ENOENT from invalid configuration
error handling case instead of 0, as done elsewhere in this function.

Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Wang Hai <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3696,6 +3696,7 @@ static int mvpp2_open(struct net_device
if (!valid) {
netdev_err(port->dev,
"invalid configuration: no dt or link IRQ");
+ err = -ENOENT;
goto err_free_irq;
}



2020-12-06 11:49:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 06/39] rose: Fix Null pointer dereference in rose_send_frame()

From: Anmol Karn <[email protected]>

[ Upstream commit 3b3fd068c56e3fbea30090859216a368398e39bf ]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Jakub Kicinski <[email protected]>
Reported-by: [email protected]
Tested-by: [email protected]
Link: https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/rose/rose_loopback.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)

--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,10 +96,19 @@ static void rose_loopback_timer(struct t
}

if (frametype == ROSE_CALL_REQUEST) {
- if ((dev = rose_dev_get(dest)) != NULL) {
- if (rose_rx_call_request(skb, dev, rose_loopback_neigh, lci_o) == 0)
- kfree_skb(skb);
- } else {
+ if (!rose_loopback_neigh->dev) {
+ kfree_skb(skb);
+ continue;
+ }
+
+ dev = rose_dev_get(dest);
+ if (!dev) {
+ kfree_skb(skb);
+ continue;
+ }
+
+ if (rose_rx_call_request(skb, dev, rose_loopback_neigh, lci_o) == 0) {
+ dev_put(dev);
kfree_skb(skb);
}
} else {


2020-12-06 11:49:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 04/39] net/tls: missing received data after fast remote close

From: Vadim Fedorenko <[email protected]>

[ Upstream commit 20ffc7adf53a5fd3d19751fbff7895bcca66686e ]

In case when tcp socket received FIN after some data and the
parser haven't started before reading data caller will receive
an empty buffer. This behavior differs from plain TCP socket and
leads to special treating in user-space.
The flow that triggers the race is simple. Server sends small
amount of data right after the connection is configured to use TLS
and closes the connection. In this case receiver sees TLS Handshake
data, configures TLS socket right after Change Cipher Spec record.
While the configuration is in process, TCP socket receives small
Application Data record, Encrypted Alert record and FIN packet. So
the TCP socket changes sk_shutdown to RCV_SHUTDOWN and sk_flag with
SK_DONE bit set. The received data is not parsed upon arrival and is
never sent to user-space.

Patch unpauses parser directly if we have unparsed data in tcp
receive queue.

Fixes: fcf4793e278e ("tls: check RCV_SHUTDOWN in tls_wait_data")
Signed-off-by: Vadim Fedorenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tls/tls_sw.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1291,6 +1291,12 @@ static struct sk_buff *tls_wait_data(str
return NULL;
}

+ if (!skb_queue_empty(&sk->sk_receive_queue)) {
+ __strp_unpause(&ctx->strp);
+ if (ctx->recv_pkt)
+ return ctx->recv_pkt;
+ }
+
if (sk->sk_shutdown & RCV_SHUTDOWN)
return NULL;



2020-12-06 11:49:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 25/39] cxgb3: fix error return code in t3_sge_alloc_qset()

From: Zhang Changzhong <[email protected]>

[ Upstream commit ff9924897f8bfed82e61894b373ab9d2dfea5b10 ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: b1fb1f280d09 ("cxgb3 - Fix dma mapping error path")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Changzhong <[email protected]>
Acked-by: Raju Rangoju <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb3/sge.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -3176,6 +3176,7 @@ int t3_sge_alloc_qset(struct adapter *ad
GFP_KERNEL | __GFP_COMP);
if (!avail) {
CH_ALERT(adapter, "free list queue 0 initialization failed\n");
+ ret = -ENOMEM;
goto err;
}
if (avail < q->fl[0].size)


2020-12-06 11:49:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 18/39] chelsio/chtls: fix panic during unload reload chtls

From: Vinay Kumar Yadav <[email protected]>

[ Upstream commit e3d5e971d2f83d8ddd4b91a50cea4517fb488383 ]

there is kernel panic in inet_twsk_free() while chtls
module unload when socket is in TIME_WAIT state because
sk_prot_creator was not preserved on connection socket.

Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
Signed-off-by: Udai Sharma <[email protected]>
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/crypto/chelsio/chtls/chtls_cm.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
@@ -1077,6 +1077,7 @@ static struct sock *chtls_recv_sock(stru
sk_setup_caps(newsk, dst);
ctx = tls_get_ctx(lsk);
newsk->sk_destruct = ctx->sk_destruct;
+ newsk->sk_prot_creator = lsk->sk_prot_creator;
csk->sk = newsk;
csk->passive_reap_next = oreq;
csk->tx_chan = cxgb4_port_chan(ndev);


2020-12-06 11:50:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 28/39] chelsio/chtls: fix a double free in chtls_setkey()

From: Dan Carpenter <[email protected]>

[ Upstream commit 391119fb5c5c4bdb4d57c7ffeb5e8d18560783d1 ]

The "skb" is freed by the transmit code in cxgb4_ofld_send() and we
shouldn't use it again. But in the current code, if we hit an error
later on in the function then the clean up code will call kfree_skb(skb)
and so it causes a double free.

Set the "skb" to NULL and that makes the kfree_skb() a no-op.

Fixes: d25f2f71f653 ("crypto: chtls - Program the TLS session Key")
Signed-off-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/X8ilb6PtBRLWiSHp@mwanda
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/crypto/chelsio/chtls/chtls_hw.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/chelsio/chtls/chtls_hw.c
+++ b/drivers/crypto/chelsio/chtls/chtls_hw.c
@@ -365,6 +365,7 @@ int chtls_setkey(struct chtls_sock *csk,
csk->wr_unacked += DIV_ROUND_UP(len, 16);
enqueue_wr(csk, skb);
cxgb4_ofld_send(csk->egress_dev, skb);
+ skb = NULL;

chtls_set_scmd(csk);
/* Clear quiesce for Rx key */


2020-12-06 11:50:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 34/39] net/mlx5: Fix wrong address reclaim when command interface is down

From: Eran Ben Elisha <[email protected]>

[ Upstream commit 1d2bb5ad89f47d8ce8aedc70ef85059ab3870292 ]

When command interface is down, driver to reclaim all 4K page chucks that
were hold by the Firmeware. Fix a bug for 64K page size systems, where
driver repeatedly released only the first chunk of the page.

Define helper function to fill 4K chunks for a given Firmware pages.
Iterate over all unreleased Firmware pages and call the hepler per each.

Fixes: 5adff6a08862 ("net/mlx5: Fix incorrect page count when in internal error")
Signed-off-by: Eran Ben Elisha <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 21 ++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
@@ -339,6 +339,24 @@ out_free:
return err;
}

+static u32 fwp_fill_manage_pages_out(struct fw_page *fwp, u32 *out, u32 index,
+ u32 npages)
+{
+ u32 pages_set = 0;
+ unsigned int n;
+
+ for_each_clear_bit(n, &fwp->bitmask, MLX5_NUM_4K_IN_PAGE) {
+ MLX5_ARRAY_SET64(manage_pages_out, out, pas, index + pages_set,
+ fwp->addr + (n * MLX5_ADAPTER_PAGE_SIZE));
+ pages_set++;
+
+ if (!--npages)
+ break;
+ }
+
+ return pages_set;
+}
+
static int reclaim_pages_cmd(struct mlx5_core_dev *dev,
u32 *in, int in_size, u32 *out, int out_size)
{
@@ -362,8 +380,7 @@ static int reclaim_pages_cmd(struct mlx5
if (fwp->func_id != func_id)
continue;

- MLX5_ARRAY_SET64(manage_pages_out, out, pas, i, fwp->addr);
- i++;
+ i += fwp_fill_manage_pages_out(fwp, out, i, npages - i);
}

MLX5_SET(manage_pages_out, out, output_num_entries, i);


2020-12-06 11:50:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 07/39] sock: set sk_err to ee_errno on dequeue from errq

From: Willem de Bruijn <[email protected]>

[ Upstream commit 985f7337421a811cb354ca93882f943c8335a6f5 ]

When setting sk_err, set it to ee_errno, not ee_origin.

Commit f5f99309fa74 ("sock: do not set sk_err in
sock_dequeue_err_skb") disabled updating sk_err on errq dequeue,
which is correct for most error types (origins):

- sk->sk_err = err;

Commit 38b257938ac6 ("sock: reset sk_err when the error queue is
empty") reenabled the behavior for IMCP origins, which do require it:

+ if (icmp_next)
+ sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin;

But read from ee_errno.

Fixes: 38b257938ac6 ("sock: reset sk_err when the error queue is empty")
Reported-by: Ayush Ranjan <[email protected]>
Signed-off-by: Willem de Bruijn <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4452,7 +4452,7 @@ struct sk_buff *sock_dequeue_err_skb(str
if (skb && (skb_next = skb_peek(q))) {
icmp_next = is_icmp_err_skb(skb_next);
if (icmp_next)
- sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin;
+ sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_errno;
}
spin_unlock_irqrestore(&q->lock, flags);



2020-12-06 11:51:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 03/39] net/af_iucv: set correct sk_protocol for child sockets

From: Julian Wiedmann <[email protected]>

[ Upstream commit c5dab0941fcdc9664eb0ec0d4d51433216d91336 ]

Child sockets erroneously inherit their parent's sk_type (ie. SOCK_*),
instead of the PF_IUCV protocol that the parent was created with in
iucv_sock_create().

We're currently not using sk->sk_protocol ourselves, so this shouldn't
have much impact (except eg. getting the output in skb_dump() right).

Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support")
Signed-off-by: Julian Wiedmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/iucv/af_iucv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1785,7 +1785,7 @@ static int iucv_callback_connreq(struct
}

/* Create the new socket */
- nsk = iucv_sock_alloc(NULL, sk->sk_type, GFP_ATOMIC, 0);
+ nsk = iucv_sock_alloc(NULL, sk->sk_protocol, GFP_ATOMIC, 0);
if (!nsk) {
err = pr_iucv->path_sever(path, user_data);
iucv_path_free(path);
@@ -1991,7 +1991,7 @@ static int afiucv_hs_callback_syn(struct
goto out;
}

- nsk = iucv_sock_alloc(NULL, sk->sk_type, GFP_ATOMIC, 0);
+ nsk = iucv_sock_alloc(NULL, sk->sk_protocol, GFP_ATOMIC, 0);
bh_lock_sock(sk);
if ((sk->sk_state != IUCV_LISTEN) ||
sk_acceptq_is_full(sk) ||


2020-12-07 08:07:25

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/39] 5.4.82-rc1 review

On Sun, 6 Dec 2020 at 17:14, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.82 release.
> There are 39 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 Tue, 08 Dec 2020 11:15:42 +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/v5.x/stable-review/patch-5.4.82-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

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

kernel: 5.4.82-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 08a1fd1f5653a704bab8d0da9940b59073a56d04
git describe: v5.4.81-40-g08a1fd1f5653
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.81-40-g08a1fd1f5653

No regressions (compared to build v5.4.81)

No fixes (compared to build v5.4.81)


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

Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

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

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

2020-12-07 16:00:03

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/39] 5.4.82-rc1 review

On Sun, Dec 06, 2020 at 12:17:04PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.82 release.
> There are 39 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 Tue, 08 Dec 2020 11:15:42 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 426 pass: 426 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter