2019-05-04 10:29:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/23] 4.19.40-stable review

This is the start of the stable review cycle for the 4.19.40 release.
There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
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.40-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.40-rc1

Rafael J. Wysocki <[email protected]>
ath10k: Drop WARN_ON()s that always trigger during system resume

Greg Kroah-Hartman <[email protected]>
ALSA: line6: use dynamic buffers

Jim Mattson <[email protected]>
KVM: nVMX: Fix size checks in vmx_set_nested_state

Sean Christopherson <[email protected]>
KVM: x86: Whitelist port 0x7e for pre-incrementing %rip

Jakub Kicinski <[email protected]>
net/tls: fix copy to fragments in reencrypt

Jakub Kicinski <[email protected]>
net/tls: don't copy negative amounts of data in reencrypt

Michael Chan <[email protected]>
bnxt_en: Fix uninitialized variable usage in bnxt_rx_pkt().

Vasundhara Volam <[email protected]>
bnxt_en: Free short FW command HWRM memory in error path in bnxt_init_one()

Michael Chan <[email protected]>
bnxt_en: Improve multicast address setup logic.

Willem de Bruijn <[email protected]>
packet: validate msg_namelen in send directly

Hangbin Liu <[email protected]>
selftests: fib_rule_tests: print the result and return 1 if any tests failed

Xin Long <[email protected]>
sctp: avoid running the sctp state machine recursively

David Howells <[email protected]>
rxrpc: Fix net namespace cleanup

Jakub Kicinski <[email protected]>
net/tls: avoid NULL pointer deref on nskb->sk in fallback

Andrew Lunn <[email protected]>
net: phy: marvell: Fix buffer overrun with stats counters

Dan Carpenter <[email protected]>
net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc

Eric Dumazet <[email protected]>
l2tp: use rcu_dereference_sk_user_data() in l2tp_udp_encap_recv()

Eric Dumazet <[email protected]>
l2ip: fix possible use-after-free

Willem de Bruijn <[email protected]>
ipv6: invert flowlabel sharing check in process and user mode

Eric Dumazet <[email protected]>
ipv6/flowlabel: wait rcu grace period before put_pid()

Eric Dumazet <[email protected]>
ipv6: fix races in ip6_dst_destroy()

Martin KaFai Lau <[email protected]>
ipv6: A few fixes on dereferencing rt->from

Shmulik Ladkani <[email protected]>
ipv4: ip_do_fragment: Preserve skb_iif during fragmentation


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

Diffstat:

Makefile | 4 +-
arch/x86/include/uapi/asm/kvm.h | 1 +
arch/x86/kvm/vmx.c | 4 +-
arch/x86/kvm/x86.c | 21 +++++++++-
drivers/net/dsa/bcm_sf2_cfp.c | 6 +++
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 ++++++---
drivers/net/phy/marvell.c | 6 ++-
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
include/net/sctp/command.h | 1 -
net/ipv4/ip_output.c | 1 +
net/ipv6/ip6_fib.c | 4 +-
net/ipv6/ip6_flowlabel.c | 22 ++++++----
net/ipv6/route.c | 47 +++++++++------------
net/l2tp/l2tp_core.c | 10 ++---
net/packet/af_packet.c | 24 ++++++-----
net/rxrpc/call_object.c | 32 +++++++-------
net/sctp/sm_sideeffect.c | 29 -------------
net/sctp/sm_statefuns.c | 35 ++++++++++++----
net/tls/tls_device.c | 39 ++++++++++++-----
net/tls/tls_device_fallback.c | 3 +-
sound/usb/line6/driver.c | 60 ++++++++++++++++-----------
sound/usb/line6/podhd.c | 21 ++++++----
sound/usb/line6/toneport.c | 24 ++++++++---
tools/testing/selftests/net/fib_rule_tests.sh | 6 +++
24 files changed, 248 insertions(+), 173 deletions(-)



2019-05-04 10:29:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 09/23] net: phy: marvell: Fix buffer overrun with stats counters

From: Andrew Lunn <[email protected]>

[ Upstream commit fdfdf86720a34527f777cbe0d8599bf0528fa146 ]

marvell_get_sset_count() returns how many statistics counters there
are. If the PHY supports fibre, there are 3, otherwise two.

marvell_get_strings() does not make this distinction, and always
returns 3 strings. This then often results in writing past the end
of the buffer for the strings.

Fixes: 2170fef78a40 ("Marvell phy: add field to get errors from fiber link.")
Signed-off-by: Andrew Lunn <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/phy/marvell.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1513,9 +1513,10 @@ static int marvell_get_sset_count(struct

static void marvell_get_strings(struct phy_device *phydev, u8 *data)
{
+ int count = marvell_get_sset_count(phydev);
int i;

- for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++) {
+ for (i = 0; i < count; i++) {
strlcpy(data + i * ETH_GSTRING_LEN,
marvell_hw_stats[i].string, ETH_GSTRING_LEN);
}
@@ -1543,9 +1544,10 @@ static u64 marvell_get_stat(struct phy_d
static void marvell_get_stats(struct phy_device *phydev,
struct ethtool_stats *stats, u64 *data)
{
+ int count = marvell_get_sset_count(phydev);
int i;

- for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++)
+ for (i = 0; i < count; i++)
data[i] = marvell_get_stat(phydev, i);
}



2019-05-04 10:30:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 04/23] ipv6/flowlabel: wait rcu grace period before put_pid()

From: Eric Dumazet <[email protected]>

[ Upstream commit 6c0afef5fb0c27758f4d52b2210c61b6bd8b4470 ]

syzbot was able to catch a use-after-free read in pid_nr_ns() [1]

ip6fl_seq_show() seems to use RCU protection, dereferencing fl->owner.pid
but fl_free() releases fl->owner.pid before rcu grace period is started.

[1]

BUG: KASAN: use-after-free in pid_nr_ns+0x128/0x140 kernel/pid.c:407
Read of size 4 at addr ffff888094012a04 by task syz-executor.0/18087

CPU: 0 PID: 18087 Comm: syz-executor.0 Not tainted 5.1.0-rc6+ #89
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
pid_nr_ns+0x128/0x140 kernel/pid.c:407
ip6fl_seq_show+0x2f8/0x4f0 net/ipv6/ip6_flowlabel.c:794
seq_read+0xad3/0x1130 fs/seq_file.c:268
proc_reg_read+0x1fe/0x2c0 fs/proc/inode.c:227
do_loop_readv_writev fs/read_write.c:701 [inline]
do_loop_readv_writev fs/read_write.c:688 [inline]
do_iter_read+0x4a9/0x660 fs/read_write.c:922
vfs_readv+0xf0/0x160 fs/read_write.c:984
kernel_readv fs/splice.c:358 [inline]
default_file_splice_read+0x475/0x890 fs/splice.c:413
do_splice_to+0x12a/0x190 fs/splice.c:876
splice_direct_to_actor+0x2d2/0x970 fs/splice.c:953
do_splice_direct+0x1da/0x2a0 fs/splice.c:1062
do_sendfile+0x597/0xd00 fs/read_write.c:1443
__do_sys_sendfile64 fs/read_write.c:1498 [inline]
__se_sys_sendfile64 fs/read_write.c:1490 [inline]
__x64_sys_sendfile64+0x15a/0x220 fs/read_write.c:1490
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x458da9
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f300d24bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000458da9
RDX: 00000000200000c0 RSI: 0000000000000008 RDI: 0000000000000007
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000005a R11: 0000000000000246 R12: 00007f300d24c6d4
R13: 00000000004c5fa3 R14: 00000000004da748 R15: 00000000ffffffff

Allocated by task 17543:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:497 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
slab_post_alloc_hook mm/slab.h:437 [inline]
slab_alloc mm/slab.c:3393 [inline]
kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
alloc_pid+0x55/0x8f0 kernel/pid.c:168
copy_process.part.0+0x3b08/0x7980 kernel/fork.c:1932
copy_process kernel/fork.c:1709 [inline]
_do_fork+0x257/0xfd0 kernel/fork.c:2226
__do_sys_clone kernel/fork.c:2333 [inline]
__se_sys_clone kernel/fork.c:2327 [inline]
__x64_sys_clone+0xbf/0x150 kernel/fork.c:2327
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 7789:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
__cache_free mm/slab.c:3499 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3765
put_pid.part.0+0x111/0x150 kernel/pid.c:111
put_pid+0x20/0x30 kernel/pid.c:105
fl_free+0xbe/0xe0 net/ipv6/ip6_flowlabel.c:102
ip6_fl_gc+0x295/0x3e0 net/ipv6/ip6_flowlabel.c:152
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:293

The buggy address belongs to the object at ffff888094012a00
which belongs to the cache pid_2 of size 88
The buggy address is located 4 bytes inside of
88-byte region [ffff888094012a00, ffff888094012a58)
The buggy address belongs to the page:
page:ffffea0002500480 count:1 mapcount:0 mapping:ffff88809a483080 index:0xffff888094012980
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea00018a3508 ffffea0002524a88 ffff88809a483080
raw: ffff888094012980 ffff888094012000 000000010000001b 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff888094012900: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
ffff888094012980: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
>ffff888094012a00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
^
ffff888094012a80: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
ffff888094012b00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc

Fixes: 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_flowlabel.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)

--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -94,15 +94,21 @@ static struct ip6_flowlabel *fl_lookup(s
return fl;
}

+static void fl_free_rcu(struct rcu_head *head)
+{
+ struct ip6_flowlabel *fl = container_of(head, struct ip6_flowlabel, rcu);
+
+ if (fl->share == IPV6_FL_S_PROCESS)
+ put_pid(fl->owner.pid);
+ kfree(fl->opt);
+ kfree(fl);
+}
+

static void fl_free(struct ip6_flowlabel *fl)
{
- if (fl) {
- if (fl->share == IPV6_FL_S_PROCESS)
- put_pid(fl->owner.pid);
- kfree(fl->opt);
- kfree_rcu(fl, rcu);
- }
+ if (fl)
+ call_rcu(&fl->rcu, fl_free_rcu);
}

static void fl_release(struct ip6_flowlabel *fl)


2019-05-04 10:30:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 18/23] net/tls: dont copy negative amounts of data in reencrypt

From: Jakub Kicinski <[email protected]>

[ Upstream commit 97e1caa517e22d62a283b876fb8aa5f4672c83dd ]

There is no guarantee the record starts before the skb frags.
If we don't check for this condition copy amount will get
negative, leading to reads and writes to random memory locations.
Familiar hilarity ensues.

Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: John Hurley <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tls/tls_device.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)

--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -600,14 +600,16 @@ static int tls_device_reencrypt(struct s
else
err = 0;

- copy = min_t(int, skb_pagelen(skb) - offset,
- rxm->full_len - TLS_CIPHER_AES_GCM_128_TAG_SIZE);
+ if (skb_pagelen(skb) > offset) {
+ copy = min_t(int, skb_pagelen(skb) - offset,
+ rxm->full_len - TLS_CIPHER_AES_GCM_128_TAG_SIZE);

- if (skb->decrypted)
- skb_store_bits(skb, offset, buf, copy);
+ if (skb->decrypted)
+ skb_store_bits(skb, offset, buf, copy);

- offset += copy;
- buf += copy;
+ offset += copy;
+ buf += copy;
+ }

skb_walk_frags(skb, skb_iter) {
copy = min_t(int, skb_iter->len,


2019-05-04 10:30:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 19/23] net/tls: fix copy to fragments in reencrypt

From: Jakub Kicinski <[email protected]>

[ Upstream commit eb3d38d5adb520435d4e4af32529ccb13ccc9935 ]

Fragments may contain data from other records so we have to account
for that when we calculate the destination and max length of copy we
can perform. Note that 'offset' is the offset within the message,
so it can't be passed as offset within the frag..

Here skb_store_bits() would have realised the call is wrong and
simply not copy data.

Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: John Hurley <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tls/tls_device.c | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)

--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -569,7 +569,7 @@ void handle_device_resync(struct sock *s
static int tls_device_reencrypt(struct sock *sk, struct sk_buff *skb)
{
struct strp_msg *rxm = strp_msg(skb);
- int err = 0, offset = rxm->offset, copy, nsg;
+ int err = 0, offset = rxm->offset, copy, nsg, data_len, pos;
struct sk_buff *skb_iter, *unused;
struct scatterlist sg[1];
char *orig_buf, *buf;
@@ -600,9 +600,10 @@ static int tls_device_reencrypt(struct s
else
err = 0;

+ data_len = rxm->full_len - TLS_CIPHER_AES_GCM_128_TAG_SIZE;
+
if (skb_pagelen(skb) > offset) {
- copy = min_t(int, skb_pagelen(skb) - offset,
- rxm->full_len - TLS_CIPHER_AES_GCM_128_TAG_SIZE);
+ copy = min_t(int, skb_pagelen(skb) - offset, data_len);

if (skb->decrypted)
skb_store_bits(skb, offset, buf, copy);
@@ -611,16 +612,30 @@ static int tls_device_reencrypt(struct s
buf += copy;
}

+ pos = skb_pagelen(skb);
skb_walk_frags(skb, skb_iter) {
- copy = min_t(int, skb_iter->len,
- rxm->full_len - offset + rxm->offset -
- TLS_CIPHER_AES_GCM_128_TAG_SIZE);
+ int frag_pos;
+
+ /* Practically all frags must belong to msg if reencrypt
+ * is needed with current strparser and coalescing logic,
+ * but strparser may "get optimized", so let's be safe.
+ */
+ if (pos + skb_iter->len <= offset)
+ goto done_with_frag;
+ if (pos >= data_len + rxm->offset)
+ break;
+
+ frag_pos = offset - pos;
+ copy = min_t(int, skb_iter->len - frag_pos,
+ data_len + rxm->offset - offset);

if (skb_iter->decrypted)
- skb_store_bits(skb_iter, offset, buf, copy);
+ skb_store_bits(skb_iter, frag_pos, buf, copy);

offset += copy;
buf += copy;
+done_with_frag:
+ pos += skb_iter->len;
}

free_buf:


2019-05-04 10:30:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 21/23] KVM: nVMX: Fix size checks in vmx_set_nested_state

From: Jim Mattson <[email protected]>

commit e8ab8d24b488632d07ce5ddb261f1d454114415b upstream.

The size checks in vmx_nested_state are wrong because the calculations
are made based on the size of a pointer to a struct kvm_nested_state
rather than the size of a struct kvm_nested_state.

Reported-by: Felix Wilhelm <[email protected]>
Signed-off-by: Jim Mattson <[email protected]>
Reviewed-by: Drew Schmitt <[email protected]>
Reviewed-by: Marc Orr <[email protected]>
Reviewed-by: Peter Shier <[email protected]>
Reviewed-by: Krish Sadhukhan <[email protected]>
Fixes: 8fcc4b5923af5de58b80b53a069453b135693304
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/vmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -14236,7 +14236,7 @@ static int vmx_set_nested_state(struct k
return ret;

/* Empty 'VMXON' state is permitted */
- if (kvm_state->size < sizeof(kvm_state) + sizeof(*vmcs12))
+ if (kvm_state->size < sizeof(*kvm_state) + sizeof(*vmcs12))
return 0;

if (kvm_state->vmx.vmcs_pa == kvm_state->vmx.vmxon_pa ||
@@ -14269,7 +14269,7 @@ static int vmx_set_nested_state(struct k
if (nested_cpu_has_shadow_vmcs(vmcs12) &&
vmcs12->vmcs_link_pointer != -1ull) {
struct vmcs12 *shadow_vmcs12 = get_shadow_vmcs12(vcpu);
- if (kvm_state->size < sizeof(kvm_state) + 2 * sizeof(*vmcs12))
+ if (kvm_state->size < sizeof(*kvm_state) + 2 * sizeof(*vmcs12))
return -EINVAL;

if (copy_from_user(shadow_vmcs12,


2019-05-04 10:30:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 17/23] bnxt_en: Fix uninitialized variable usage in bnxt_rx_pkt().

From: Michael Chan <[email protected]>

[ Upstream commit 0b397b17a4120cb80f7bf89eb30587b3dd9b0d1d ]

In bnxt_rx_pkt(), if the driver encounters BD errors, it will recycle
the buffers and jump to the end where the uninitailized variable "len"
is referenced. Fix it by adding a new jump label that will skip
the length update. This is the most correct fix since the length
may not be valid when we get this type of error.

Fixes: 6a8788f25625 ("bnxt_en: add support for software dynamic interrupt moderation")
Reported-by: Nathan Chancellor <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Signed-off-by: Michael Chan <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1584,7 +1584,7 @@ static int bnxt_rx_pkt(struct bnxt *bp,
netdev_warn(bp->dev, "RX buffer error %x\n", rx_err);
bnxt_sched_reset(bp, rxr);
}
- goto next_rx;
+ goto next_rx_no_len;
}

len = le32_to_cpu(rxcmp->rx_cmp_len_flags_type) >> RX_CMP_LEN_SHIFT;
@@ -1665,12 +1665,13 @@ static int bnxt_rx_pkt(struct bnxt *bp,
rc = 1;

next_rx:
- rxr->rx_prod = NEXT_RX(prod);
- rxr->rx_next_cons = NEXT_RX(cons);
-
cpr->rx_packets += 1;
cpr->rx_bytes += len;

+next_rx_no_len:
+ rxr->rx_prod = NEXT_RX(prod);
+ rxr->rx_next_cons = NEXT_RX(cons);
+
next_rx_no_prod_no_len:
*raw_cons = tmp_raw_cons;



2019-05-04 10:30:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 13/23] selftests: fib_rule_tests: print the result and return 1 if any tests failed

From: Hangbin Liu <[email protected]>

[ Upstream commit f68d7c44e76532e46f292ad941aa3706cb9e6e40 ]

Fixes: 65b2b4939a64 ("selftests: net: initial fib rule tests")
Signed-off-by: Hangbin Liu <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/net/fib_rule_tests.sh | 6 ++++++
1 file changed, 6 insertions(+)

--- a/tools/testing/selftests/net/fib_rule_tests.sh
+++ b/tools/testing/selftests/net/fib_rule_tests.sh
@@ -27,6 +27,7 @@ log_test()
nsuccess=$((nsuccess+1))
printf "\n TEST: %-50s [ OK ]\n" "${msg}"
else
+ ret=1
nfail=$((nfail+1))
printf "\n TEST: %-50s [FAIL]\n" "${msg}"
if [ "${PAUSE_ON_FAIL}" = "yes" ]; then
@@ -245,4 +246,9 @@ setup
run_fibrule_tests
cleanup

+if [ "$TESTS" != "none" ]; then
+ printf "\nTests passed: %3d\n" ${nsuccess}
+ printf "Tests failed: %3d\n" ${nfail}
+fi
+
exit $ret


2019-05-04 10:30:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 12/23] sctp: avoid running the sctp state machine recursively

From: Xin Long <[email protected]>

[ Upstream commit fbd019737d71e405f86549fd738f81e2ff3dd073 ]

Ying triggered a call trace when doing an asconf testing:

BUG: scheduling while atomic: swapper/12/0/0x10000100
Call Trace:
<IRQ> [<ffffffffa4375904>] dump_stack+0x19/0x1b
[<ffffffffa436fcaf>] __schedule_bug+0x64/0x72
[<ffffffffa437b93a>] __schedule+0x9ba/0xa00
[<ffffffffa3cd5326>] __cond_resched+0x26/0x30
[<ffffffffa437bc4a>] _cond_resched+0x3a/0x50
[<ffffffffa3e22be8>] kmem_cache_alloc_node+0x38/0x200
[<ffffffffa423512d>] __alloc_skb+0x5d/0x2d0
[<ffffffffc0995320>] sctp_packet_transmit+0x610/0xa20 [sctp]
[<ffffffffc098510e>] sctp_outq_flush+0x2ce/0xc00 [sctp]
[<ffffffffc098646c>] sctp_outq_uncork+0x1c/0x20 [sctp]
[<ffffffffc0977338>] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp]
[<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
[<ffffffffc099443d>] sctp_primitive_ASCONF+0x3d/0x50 [sctp]
[<ffffffffc0977384>] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp]
[<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
[<ffffffffc097b3a4>] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp]
[<ffffffffc09840f1>] sctp_inq_push+0x51/0x70 [sctp]
[<ffffffffc099732b>] sctp_rcv+0xa8b/0xbd0 [sctp]

As it shows, the first sctp_do_sm() running under atomic context (NET_RX
softirq) invoked sctp_primitive_ASCONF() that uses GFP_KERNEL flag later,
and this flag is supposed to be used in non-atomic context only. Besides,
sctp_do_sm() was called recursively, which is not expected.

Vlad tried to fix this recursive call in Commit c0786693404c ("sctp: Fix
oops when sending queued ASCONF chunks") by introducing a new command
SCTP_CMD_SEND_NEXT_ASCONF. But it didn't work as this command is still
used in the first sctp_do_sm() call, and sctp_primitive_ASCONF() will
be called in this command again.

To avoid calling sctp_do_sm() recursively, we send the next queued ASCONF
not by sctp_primitive_ASCONF(), but by sctp_sf_do_prm_asconf() in the 1st
sctp_do_sm() directly.

Reported-by: Ying Xu <[email protected]>
Signed-off-by: Xin Long <[email protected]>
Acked-by: Neil Horman <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/sctp/command.h | 1 -
net/sctp/sm_sideeffect.c | 29 -----------------------------
net/sctp/sm_statefuns.c | 35 +++++++++++++++++++++++++++--------
3 files changed, 27 insertions(+), 38 deletions(-)

--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -105,7 +105,6 @@ enum sctp_verb {
SCTP_CMD_T1_RETRAN, /* Mark for retransmission after T1 timeout */
SCTP_CMD_UPDATE_INITTAG, /* Update peer inittag */
SCTP_CMD_SEND_MSG, /* Send the whole use message */
- SCTP_CMD_SEND_NEXT_ASCONF, /* Send the next ASCONF after ACK */
SCTP_CMD_PURGE_ASCONF_QUEUE, /* Purge all asconf queues.*/
SCTP_CMD_SET_ASOC, /* Restore association context */
SCTP_CMD_LAST
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1112,32 +1112,6 @@ static void sctp_cmd_send_msg(struct sct
}


-/* Sent the next ASCONF packet currently stored in the association.
- * This happens after the ASCONF_ACK was succeffully processed.
- */
-static void sctp_cmd_send_asconf(struct sctp_association *asoc)
-{
- struct net *net = sock_net(asoc->base.sk);
-
- /* Send the next asconf chunk from the addip chunk
- * queue.
- */
- if (!list_empty(&asoc->addip_chunk_list)) {
- struct list_head *entry = asoc->addip_chunk_list.next;
- struct sctp_chunk *asconf = list_entry(entry,
- struct sctp_chunk, list);
- list_del_init(entry);
-
- /* Hold the chunk until an ASCONF_ACK is received. */
- sctp_chunk_hold(asconf);
- if (sctp_primitive_ASCONF(net, asoc, asconf))
- sctp_chunk_free(asconf);
- else
- asoc->addip_last_asconf = asconf;
- }
-}
-
-
/* These three macros allow us to pull the debugging code out of the
* main flow of sctp_do_sm() to keep attention focused on the real
* functionality there.
@@ -1783,9 +1757,6 @@ static int sctp_cmd_interpreter(enum sct
}
sctp_cmd_send_msg(asoc, cmd->obj.msg, gfp);
break;
- case SCTP_CMD_SEND_NEXT_ASCONF:
- sctp_cmd_send_asconf(asoc);
- break;
case SCTP_CMD_PURGE_ASCONF_QUEUE:
sctp_asconf_queue_teardown(asoc);
break;
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -3824,6 +3824,29 @@ enum sctp_disposition sctp_sf_do_asconf(
return SCTP_DISPOSITION_CONSUME;
}

+static enum sctp_disposition sctp_send_next_asconf(
+ struct net *net,
+ const struct sctp_endpoint *ep,
+ struct sctp_association *asoc,
+ const union sctp_subtype type,
+ struct sctp_cmd_seq *commands)
+{
+ struct sctp_chunk *asconf;
+ struct list_head *entry;
+
+ if (list_empty(&asoc->addip_chunk_list))
+ return SCTP_DISPOSITION_CONSUME;
+
+ entry = asoc->addip_chunk_list.next;
+ asconf = list_entry(entry, struct sctp_chunk, list);
+
+ list_del_init(entry);
+ sctp_chunk_hold(asconf);
+ asoc->addip_last_asconf = asconf;
+
+ return sctp_sf_do_prm_asconf(net, ep, asoc, type, asconf, commands);
+}
+
/*
* ADDIP Section 4.3 General rules for address manipulation
* When building TLV parameters for the ASCONF Chunk that will add or
@@ -3915,14 +3938,10 @@ enum sctp_disposition sctp_sf_do_asconf_
SCTP_TO(SCTP_EVENT_TIMEOUT_T4_RTO));

if (!sctp_process_asconf_ack((struct sctp_association *)asoc,
- asconf_ack)) {
- /* Successfully processed ASCONF_ACK. We can
- * release the next asconf if we have one.
- */
- sctp_add_cmd_sf(commands, SCTP_CMD_SEND_NEXT_ASCONF,
- SCTP_NULL());
- return SCTP_DISPOSITION_CONSUME;
- }
+ asconf_ack))
+ return sctp_send_next_asconf(net, ep,
+ (struct sctp_association *)asoc,
+ type, commands);

abort = sctp_make_abort(asoc, asconf_ack,
sizeof(struct sctp_errhdr));


2019-05-04 10:30:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 07/23] l2tp: use rcu_dereference_sk_user_data() in l2tp_udp_encap_recv()

From: Eric Dumazet <[email protected]>

[ Upstream commit c1c477217882c610a2ba0268f5faf36c9c092528 ]

Canonical way to fetch sk_user_data from an encap_rcv() handler called
from UDP stack in rcu protected section is to use rcu_dereference_sk_user_data(),
otherwise compiler might read it multiple times.

Fixes: d00fa9adc528 ("il2tp: fix races with tunnel socket close")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: James Chapman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -909,7 +909,7 @@ int l2tp_udp_encap_recv(struct sock *sk,
{
struct l2tp_tunnel *tunnel;

- tunnel = l2tp_tunnel(sk);
+ tunnel = rcu_dereference_sk_user_data(sk);
if (tunnel == NULL)
goto pass_up;



2019-05-04 10:30:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 10/23] net/tls: avoid NULL pointer deref on nskb->sk in fallback

From: Jakub Kicinski <[email protected]>

[ Upstream commit 2dcb003314032c6efb13a065ffae60d164b2dd35 ]

update_chksum() accesses nskb->sk before it has been set
by complete_skb(), move the init up.

Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tls/tls_device_fallback.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/tls/tls_device_fallback.c
+++ b/net/tls/tls_device_fallback.c
@@ -200,13 +200,14 @@ static void complete_skb(struct sk_buff

skb_put(nskb, skb->len);
memcpy(nskb->data, skb->data, headln);
- update_chksum(nskb, headln);

nskb->destructor = skb->destructor;
nskb->sk = sk;
skb->destructor = NULL;
skb->sk = NULL;

+ update_chksum(nskb, headln);
+
delta = nskb->truesize - skb->truesize;
if (likely(delta < 0))
WARN_ON_ONCE(refcount_sub_and_test(-delta, &sk->sk_wmem_alloc));


2019-05-04 10:30:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 08/23] net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc

From: Dan Carpenter <[email protected]>

[ Upstream commit f949a12fd697479f68d99dc65e9bbab68ee49043 ]

The "fs->location" is a u32 that comes from the user in ethtool_set_rxnfc().
We can't pass unclamped values to test_bit() or it results in an out of
bounds access beyond the end of the bitmap.

Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/dsa/bcm_sf2_cfp.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -742,6 +742,9 @@ static int bcm_sf2_cfp_rule_set(struct d
fs->m_ext.data[1]))
return -EINVAL;

+ if (fs->location != RX_CLS_LOC_ANY && fs->location >= CFP_NUM_RULES)
+ return -EINVAL;
+
if (fs->location != RX_CLS_LOC_ANY &&
test_bit(fs->location, priv->cfp.used))
return -EBUSY;
@@ -836,6 +839,9 @@ static int bcm_sf2_cfp_rule_del(struct b
u32 next_loc = 0;
int ret;

+ if (loc >= CFP_NUM_RULES)
+ return -EINVAL;
+
/* Refuse deleting unused rules, and those that are not unique since
* that could leave IPv6 rules with one of the chained rule in the
* table.


2019-05-04 10:31:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 06/23] l2ip: fix possible use-after-free

From: Eric Dumazet <[email protected]>

[ Upstream commit a622b40035d16196bf19b2b33b854862595245fc ]

Before taking a refcount on a rcu protected structure,
we need to make sure the refcount is not zero.

syzbot reported :

refcount_t: increment on 0; use-after-free.
WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked lib/refcount.c:156 [inline]
WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked+0x61/0x70 lib/refcount.c:154
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 23533 Comm: syz-executor.2 Not tainted 5.1.0-rc7+ #93
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:571
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:refcount_inc_checked lib/refcount.c:156 [inline]
RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:154
Code: 1d 98 2b 2a 06 31 ff 89 de e8 db 2c 40 fe 84 db 75 dd e8 92 2b 40 fe 48 c7 c7 20 7a a1 87 c6 05 78 2b 2a 06 01 e8 7d d9 12 fe <0f> 0b eb c1 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41
RSP: 0018:ffff888069f0fba8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000f353 RSI: ffffffff815afcb6 RDI: ffffed100d3e1f67
RBP: ffff888069f0fbb8 R08: ffff88809b1845c0 R09: ffffed1015d23ef1
R10: ffffed1015d23ef0 R11: ffff8880ae91f787 R12: ffff8880a8f26968
R13: 0000000000000004 R14: dffffc0000000000 R15: ffff8880a49a6440
l2tp_tunnel_inc_refcount net/l2tp/l2tp_core.h:240 [inline]
l2tp_tunnel_get+0x250/0x580 net/l2tp/l2tp_core.c:173
pppol2tp_connect+0xc00/0x1c70 net/l2tp/l2tp_ppp.c:702
__sys_connect+0x266/0x330 net/socket.c:1808
__do_sys_connect net/socket.c:1819 [inline]
__se_sys_connect net/socket.c:1816 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1816

Fixes: 54652eb12c1b ("l2tp: hold tunnel while looking up sessions in l2tp_netlink")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Cc: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -169,8 +169,8 @@ struct l2tp_tunnel *l2tp_tunnel_get(cons

rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- if (tunnel->tunnel_id == tunnel_id) {
- l2tp_tunnel_inc_refcount(tunnel);
+ if (tunnel->tunnel_id == tunnel_id &&
+ refcount_inc_not_zero(&tunnel->ref_count)) {
rcu_read_unlock_bh();

return tunnel;
@@ -190,8 +190,8 @@ struct l2tp_tunnel *l2tp_tunnel_get_nth(

rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- if (++count > nth) {
- l2tp_tunnel_inc_refcount(tunnel);
+ if (++count > nth &&
+ refcount_inc_not_zero(&tunnel->ref_count)) {
rcu_read_unlock_bh();
return tunnel;
}


2019-05-04 10:31:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 02/23] ipv6: A few fixes on dereferencing rt->from

From: Martin KaFai Lau <[email protected]>

[ Upstream commit 886b7a50100a50f1cbd08a6f8ec5884dfbe082dc ]

It is a followup after the fix in
commit 9c69a1320515 ("route: Avoid crash from dereferencing NULL rt->from")

rt6_do_redirect():
1. NULL checking is needed on rt->from because a parallel
fib6_info delete could happen that sets rt->from to NULL.
(e.g. rt6_remove_exception() and fib6_drop_pcpu_from()).

2. fib6_info_hold() is not enough. Same reason as (1).
Meaning, holding dst->__refcnt cannot ensure
rt->from is not NULL or rt->from->fib6_ref is not 0.

Instead of using fib6_info_hold_safe() which ip6_rt_cache_alloc()
is already doing, this patch chooses to extend the rcu section
to keep "from" dereference-able after checking for NULL.

inet6_rtm_getroute():
1. NULL checking is also needed on rt->from for a similar reason.
Note that inet6_rtm_getroute() is using RTNL_FLAG_DOIT_UNLOCKED.

Fixes: a68886a69180 ("net/ipv6: Make from in rt6_info rcu protected")
Signed-off-by: Martin KaFai Lau <[email protected]>
Acked-by: Wei Wang <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/route.c | 38 ++++++++++++++++++--------------------
1 file changed, 18 insertions(+), 20 deletions(-)

--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3454,11 +3454,8 @@ static void rt6_do_redirect(struct dst_e

rcu_read_lock();
from = rcu_dereference(rt->from);
- /* This fib6_info_hold() is safe here because we hold reference to rt
- * and rt already holds reference to fib6_info.
- */
- fib6_info_hold(from);
- rcu_read_unlock();
+ if (!from)
+ goto out;

nrt = ip6_rt_cache_alloc(from, &msg->dest, NULL);
if (!nrt)
@@ -3470,10 +3467,7 @@ static void rt6_do_redirect(struct dst_e

nrt->rt6i_gateway = *(struct in6_addr *)neigh->primary_key;

- /* No need to remove rt from the exception table if rt is
- * a cached route because rt6_insert_exception() will
- * takes care of it
- */
+ /* rt6_insert_exception() will take care of duplicated exceptions */
if (rt6_insert_exception(nrt, from)) {
dst_release_immediate(&nrt->dst);
goto out;
@@ -3486,7 +3480,7 @@ static void rt6_do_redirect(struct dst_e
call_netevent_notifiers(NETEVENT_REDIRECT, &netevent);

out:
- fib6_info_release(from);
+ rcu_read_unlock();
neigh_release(neigh);
}

@@ -4991,16 +4985,20 @@ static int inet6_rtm_getroute(struct sk_

rcu_read_lock();
from = rcu_dereference(rt->from);
-
- if (fibmatch)
- err = rt6_fill_node(net, skb, from, NULL, NULL, NULL, iif,
- RTM_NEWROUTE, NETLINK_CB(in_skb).portid,
- nlh->nlmsg_seq, 0);
- else
- err = rt6_fill_node(net, skb, from, dst, &fl6.daddr,
- &fl6.saddr, iif, RTM_NEWROUTE,
- NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
- 0);
+ if (from) {
+ if (fibmatch)
+ err = rt6_fill_node(net, skb, from, NULL, NULL, NULL,
+ iif, RTM_NEWROUTE,
+ NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq, 0);
+ else
+ err = rt6_fill_node(net, skb, from, dst, &fl6.daddr,
+ &fl6.saddr, iif, RTM_NEWROUTE,
+ NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq, 0);
+ } else {
+ err = -ENETUNREACH;
+ }
rcu_read_unlock();

if (err < 0) {


2019-05-04 10:31:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/23] bnxt_en: Improve multicast address setup logic.

From: Michael Chan <[email protected]>

[ Upstream commit b4e30e8e7ea1d1e35ffd64ca46f7d9a7f227b4bf ]

The driver builds a list of multicast addresses and sends it to the
firmware when the driver's ndo_set_rx_mode() is called. In rare
cases, the firmware can fail this call if internal resources to
add multicast addresses are exhausted. In that case, we should
try the call again by setting the ALL_MCAST flag which is more
guaranteed to succeed.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -7441,8 +7441,15 @@ static int bnxt_cfg_rx_mode(struct bnxt

skip_uc:
rc = bnxt_hwrm_cfa_l2_set_rx_mask(bp, 0);
+ if (rc && vnic->mc_list_count) {
+ netdev_info(bp->dev, "Failed setting MC filters rc: %d, turning on ALL_MCAST mode\n",
+ rc);
+ vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_ALL_MCAST;
+ vnic->mc_list_count = 0;
+ rc = bnxt_hwrm_cfa_l2_set_rx_mask(bp, 0);
+ }
if (rc)
- netdev_err(bp->dev, "HWRM cfa l2 rx mask failure rc: %x\n",
+ netdev_err(bp->dev, "HWRM cfa l2 rx mask failure rc: %d\n",
rc);

return rc;


2019-05-04 11:49:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 16/23] bnxt_en: Free short FW command HWRM memory in error path in bnxt_init_one()

From: Vasundhara Volam <[email protected]>

[ Upstream commit f9099d611449836a51a65f40ea7dc9cb5f2f665e ]

In the bnxt_init_one() error path, short FW command request memory
is not freed. This patch fixes it.

Fixes: e605db801bde ("bnxt_en: Support for Short Firmware Message")
Signed-off-by: Vasundhara Volam <[email protected]>
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -9084,6 +9084,7 @@ init_err_cleanup_tc:
bnxt_clear_int_mode(bp);

init_err_pci_clean:
+ bnxt_free_hwrm_short_cmd_req(bp);
bnxt_free_hwrm_resources(bp);
bnxt_cleanup_pci(bp);



2019-05-04 11:49:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 05/23] ipv6: invert flowlabel sharing check in process and user mode

From: Willem de Bruijn <[email protected]>

[ Upstream commit 95c169251bf734aa555a1e8043e4d88ec97a04ec ]

A request for a flowlabel fails in process or user exclusive mode must
fail if the caller pid or uid does not match. Invert the test.

Previously, the test was unsafe wrt PID recycling, but indeed tested
for inequality: fl1->owner != fl->owner

Fixes: 4f82f45730c68 ("net ip6 flowlabel: Make owner a union of struct pid* and kuid_t")
Signed-off-by: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_flowlabel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -639,9 +639,9 @@ recheck:
if (fl1->share == IPV6_FL_S_EXCL ||
fl1->share != fl->share ||
((fl1->share == IPV6_FL_S_PROCESS) &&
- (fl1->owner.pid == fl->owner.pid)) ||
+ (fl1->owner.pid != fl->owner.pid)) ||
((fl1->share == IPV6_FL_S_USER) &&
- uid_eq(fl1->owner.uid, fl->owner.uid)))
+ !uid_eq(fl1->owner.uid, fl->owner.uid)))
goto release;

err = -ENOMEM;


2019-05-04 18:49:26

by kernelci.org bot

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

stable-rc/linux-4.19.y boot: 128 boots: 0 failed, 123 passed with 4 offline, 1 untried/unknown (v4.19.39-24-gb0d6421bd855)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.39-24-gb0d6421bd855/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.39-24-gb0d6421bd855/

Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.39-24-gb0d6421bd855
Git Commit: b0d6421bd85515e878edcf33121a818666df7749
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 70 unique boards, 24 SoC families, 14 builds out of 206

Offline Platforms:

arm:

davinci_all_defconfig:
gcc-7
dm365evm,legacy: 1 offline lab

exynos_defconfig:
gcc-7
exynos5800-peach-pi: 1 offline lab

multi_v7_defconfig:
gcc-7
exynos5800-peach-pi: 1 offline lab
stih410-b2120: 1 offline lab

---
For more info write to <[email protected]>

2019-05-04 23:37:22

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On 5/4/19 3:25 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.40 release.
> There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> Anything received after that time might be too late.
>

Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 349 pass: 349 fail: 0

Guenter

2019-05-05 03:23:31

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sat, May 04, 2019 at 12:25:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.40 release.
> There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> Anything received after that time might be too late.


Results from Linaro’s test farm.
Regressions detected.

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

kernel: 4.19.40-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: b0d6421bd85515e878edcf33121a818666df7749
git describe: v4.19.39-24-gb0d6421bd855
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.39-24-gb0d6421bd855

No regressions (compared to build v4.19.38-73-gdb2d00a74567)

No fixes (compared to build v4.19.38-73-gdb2d00a74567)

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

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-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-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

2019-05-05 07:24:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sat, May 04, 2019 at 10:00:44PM -0500, Dan Rue wrote:
> On Sat, May 04, 2019 at 12:25:02PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.40 release.
> > There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> > Anything received after that time might be too late.
>
>
> Results from Linaro’s test farm.
> Regressions detected.

Really? Where?

2019-05-05 09:08:57

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sun, 5 May 2019 at 12:38, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Sat, May 04, 2019 at 10:00:44PM -0500, Dan Rue wrote:
> > On Sat, May 04, 2019 at 12:25:02PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.19.40 release.
> > > There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> > > Anything received after that time might be too late.
> >
> >
> > Results from Linaro’s test farm.
> > Regressions detected.
>
> Really? Where?

Not really.
selftest: net: msg_zerocopy.sh is an intermittent failure on qemu_i386 device.
We could ignore this failure as known issues.

- Naresh

2019-05-05 09:11:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sun, May 05, 2019 at 02:23:22PM +0530, Naresh Kamboju wrote:
> On Sun, 5 May 2019 at 12:38, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > On Sat, May 04, 2019 at 10:00:44PM -0500, Dan Rue wrote:
> > > On Sat, May 04, 2019 at 12:25:02PM +0200, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.19.40 release.
> > > > There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> > > > Anything received after that time might be too late.
> > >
> > >
> > > Results from Linaro’s test farm.
> > > Regressions detected.
> >
> > Really? Where?
>
> Not really.
> selftest: net: msg_zerocopy.sh is an intermittent failure on qemu_i386 device.

Is that a test problem, or a qemu problem?

> We could ignore this failure as known issues.

It wasn't listed in the report, or did I miss it?

2019-05-05 11:55:42

by Bharath Vedartham

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

Built and booted on my x86_64 machine. No dmesg regressions observed.

Thanks
Bharath

2019-05-05 12:00:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sun, May 05, 2019 at 04:42:46PM +0530, Bharath Vedartham wrote:
> Built and booted on my x86_64 machine. No dmesg regressions observed.

Wonderful, thanks for testing and letting me know.

greg k-h

2019-05-05 12:51:27

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/23] 4.19.40-stable review

On Sun, May 05, 2019 at 11:02:36AM +0200, Greg Kroah-Hartman wrote:
> On Sun, May 05, 2019 at 02:23:22PM +0530, Naresh Kamboju wrote:
> > On Sun, 5 May 2019 at 12:38, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > On Sat, May 04, 2019 at 10:00:44PM -0500, Dan Rue wrote:
> > > > On Sat, May 04, 2019 at 12:25:02PM +0200, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.19.40 release.
> > > > > There are 23 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 Mon 06 May 2019 10:24:19 AM UTC.
> > > > > Anything received after that time might be too late.
> > > >
> > > >
> > > > Results from Linaro’s test farm.
> > > > Regressions detected.
> > >
> > > Really? Where?
> >
> > Not really.
> > selftest: net: msg_zerocopy.sh is an intermittent failure on qemu_i386 device.
>
> Is that a test problem, or a qemu problem?
>
> > We could ignore this failure as known issues.
>
> It wasn't listed in the report, or did I miss it?

It needs further investigation, but it's unrelated to this RC. It's an
intermittent failure that we see sometimes but only ever on qemu. With
the amount of tests that we run, this is common - our process is to
investigate the failure and determine if the failure is a regression or
not. In this case, I determined that it was not a real regression, but I
did not run the right command to generate the report accordingly.

No regressions on arm64, arm, x86_64, and i386.

Dan