linux-stable.git/net, branch v5.4.56

Bluetooth: fix kernel oops in store_pending_adv_report

2020-08-05T07:59:49+00:00

[ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]

Fix kernel oops observed when an ext adv data is larger than 31 bytes.

This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes.  The issue is not sensitive to the advertisement
content.  In particular, this was reproduced with an advertisement of
229 bytes filled with 'A'.  See stack trace below.

This is fixed by not catching ext_adv as legacy adv are only cached to
be able to concatenate a scanable adv with its scan response before
sending it up through mgmt.

With ext_adv, this is no longer necessary.

  general protection fault: 0000 [#1] SMP PTI
  CPU: 6 PID: 205 Comm: kworker/u17:0 Not tainted 5.4.0-37-generic #41-Ubuntu
  Hardware name: Dell Inc. XPS 15 7590/0CF6RR, BIOS 1.7.0 05/11/2020
  Workqueue: hci0 hci_rx_work [bluetooth]
  RIP: 0010:hci_bdaddr_list_lookup+0x1e/0x40 [bluetooth]
  Code: ff ff e9 26 ff ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 39 c7 75 0a eb 24 48 8b 00 48 39 f8 74 1c 44 8b 06 <44> 39 40 10 75 ef 44 0f b7 4e 04 66 44 39 48 14 75 e3 38 50 16 75
  RSP: 0018:ffffbc6a40493c70 EFLAGS: 00010286
  RAX: 4141414141414141 RBX: 000000000000001b RCX: 0000000000000000
  RDX: 0000000000000000 RSI: ffff9903e76c100f RDI: ffff9904289d4b28
  RBP: ffffbc6a40493c70 R08: 0000000093570362 R09: 0000000000000000
  R10: 0000000000000000 R11: ffff9904344eae38 R12: ffff9904289d4000
  R13: 0000000000000000 R14: 00000000ffffffa3 R15: ffff9903e76c100f
  FS: 0000000000000000(0000) GS:ffff990434580000(0000) knlGS:0000000000000000
  CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007feed125a000 CR3: 00000001b860a003 CR4: 00000000003606e0
  Call Trace:
    process_adv_report+0x12e/0x560 [bluetooth]
    hci_le_meta_evt+0x7b2/0xba0 [bluetooth]
    hci_event_packet+0x1c29/0x2a90 [bluetooth]
    hci_rx_work+0x19b/0x360 [bluetooth]
    process_one_work+0x1eb/0x3b0
    worker_thread+0x4d/0x400
    kthread+0x104/0x140

Fixes: c215e9397b00 ("Bluetooth: Process extended ADV report event")
Reported-by: Andy Nguyen 
Reported-by: Linus Torvalds 
Reported-by: Balakrishna Godavarthi 
Signed-off-by: Alain Michaud 
Tested-by: Sonny Sasaka 
Acked-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mac80211: mesh: Free pending skb when destroying a mpath

2020-08-05T07:59:48+00:00

[ Upstream commit 5e43540c2af0a0c0a18e39579b1ad49541f87506 ]

A mpath object can hold reference on a list of skb that are waiting for
mpath resolution to be sent. When destroying a mpath this skb list
should be cleaned up in order to not leak memory.

Fixing that kind of leak:

unreferenced object 0xffff0000181c9300 (size 1088):
  comm "openvpn", pid 1782, jiffies 4295071698 (age 80.416s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 f9 80 36 00 00 00 00 00  ..........6.....
    02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
  backtrace:
    [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
    [<000000002caaef13>] sk_prot_alloc.isra.39+0x34/0x178
    [<00000000ceeaa916>] sk_alloc+0x34/0x228
    [<00000000ca1f1d04>] inet_create+0x198/0x518
    [<0000000035626b1c>] __sock_create+0x134/0x328
    [<00000000a12b3a87>] __sys_socket+0xb0/0x158
    [<00000000ff859f23>] __arm64_sys_socket+0x40/0x58
    [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
    [<0000000005b5157d>] el0_svc+0x8/0xc
unreferenced object 0xffff000012973a40 (size 216):
  comm "openvpn", pid 1782, jiffies 4295082137 (age 38.660s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 c0 06 16 00 00 ff ff 00 93 1c 18 00 00 ff ff  ................
  backtrace:
    [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
    [<0000000023c8c8f9>] __alloc_skb+0xc0/0x2b8
    [<000000007ad950bb>] alloc_skb_with_frags+0x60/0x320
    [<00000000ef90023a>] sock_alloc_send_pskb+0x388/0x3c0
    [<00000000104fb1a3>] sock_alloc_send_skb+0x1c/0x28
    [<000000006919d2dd>] __ip_append_data+0xba4/0x11f0
    [<0000000083477587>] ip_make_skb+0x14c/0x1a8
    [<0000000024f3d592>] udp_sendmsg+0xaf0/0xcf0
    [<000000005aabe255>] inet_sendmsg+0x5c/0x80
    [<000000008651ea08>] __sys_sendto+0x15c/0x218
    [<000000003505c99b>] __arm64_sys_sendto+0x74/0x90
    [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
    [<0000000005b5157d>] el0_svc+0x8/0xc

Fixes: 2bdaf386f99c (mac80211: mesh: move path tables into if_mesh)
Signed-off-by: Remi Pommarel 
Link: https://lore.kernel.org/r/20200704135419.27703-1-repk@triplefau.lt
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: mesh: Free ie data when leaving mesh

2020-08-05T07:59:48+00:00

[ Upstream commit 6a01afcf8468d3ca2bd8bbb27503f60dcf643b20 ]

At ieee80211_join_mesh() some ie data could have been allocated (see
copy_mesh_setup()) and need to be cleaned up when leaving the mesh.

This fixes the following kmemleak report:

unreferenced object 0xffff0000116bc600 (size 128):
  comm "wpa_supplicant", pid 608, jiffies 4294898983 (age 293.484s)
  hex dump (first 32 bytes):
    30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00  0...............
    00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00  .........e@.....
  backtrace:
    [<00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
    [<00000000a349dbe1>] kmemdup+0x28/0x50
    [<0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
    [<00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
    [<0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
    [<0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
    [<00000000b1bd936d>] genl_rcv_msg+0x78/0x108
    [<0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
    [<0000000011af8ec9>] genl_rcv+0x34/0x48
    [<0000000069e41f53>] netlink_unicast+0x268/0x2e8
    [<00000000a7517316>] netlink_sendmsg+0x320/0x4c0
    [<0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
    [<00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
    [<0000000037340728>] __sys_sendmsg+0xa4/0xf8
    [<000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
    [<000000001c1e5647>] el0_svc_handler+0xd0/0x1a0

Fixes: c80d545da3f7 (mac80211: Let userspace enable and configure vendor specific path selection.)
Signed-off-by: Remi Pommarel 
Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.lt
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

xfrm: policy: match with both mark and mask on user interfaces

2020-08-05T07:59:44+00:00

[ Upstream commit 4f47e8ab6ab796b5380f74866fa5287aca4dcc58 ]

In commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
it would take 'priority' to make a policy unique, and allow duplicated
policies with different 'priority' to be added, which is not expected
by userland, as Tobias reported in strongswan.

To fix this duplicated policies issue, and also fix the issue in
commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
when doing add/del/get/update on user interfaces, this patch is to change
to look up a policy with both mark and mask by doing:

  mark.v == pol->mark.v && mark.m == pol->mark.m

and leave the check:

  (mark & pol->mark.m) == pol->mark.v

for tx/rx path only.

As the userland expects an exact mark and mask match to manage policies.

v1->v2:
  - make xfrm_policy_mark_match inline and fix the changelog as
    Tobias suggested.

Fixes: 295fae568885 ("xfrm: Allow user space manipulation of SPD mark")
Fixes: ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list")
Reported-by: Tobias Brunner 
Tested-by: Tobias Brunner 
Signed-off-by: Xin Long 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin

net/x25: Fix null-ptr-deref in x25_disconnect

2020-08-05T07:59:44+00:00

commit 8999dc89497ab1c80d0718828e838c7cd5f6bffe upstream.

We should check null before do x25_neigh_put in x25_disconnect,
otherwise may cause null-ptr-deref like this:

 #include 
 #include 

 int main() {
    int sck_x25;
    sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
    close(sck_x25);
    return 0;
 }

BUG: kernel NULL pointer dereference, address: 00000000000000d8
CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
RIP: 0010:x25_disconnect+0x91/0xe0
Call Trace:
 x25_release+0x18a/0x1b0
 __sock_release+0x3d/0xc0
 sock_close+0x13/0x20
 __fput+0x107/0x270
 ____fput+0x9/0x10
 task_work_run+0x6d/0xb0
 exit_to_usermode_loop+0x102/0x110
 do_syscall_64+0x23c/0x260
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Signed-off-by: YueHaibing 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/x25: Fix x25_neigh refcnt leak when x25 disconnect

2020-08-05T07:59:44+00:00

commit 4becb7ee5b3d2829ed7b9261a245a77d5b7de902 upstream.

x25_connect() invokes x25_get_neigh(), which returns a reference of the
specified x25_neigh object to "x25->neighbour" with increased refcnt.

When x25 connect success and returns, the reference still be hold by
"x25->neighbour", so the refcount should be decreased in
x25_disconnect() to keep refcount balanced.

The reference counting issue happens in x25_disconnect(), which forgets
to decrease the refcnt increased by x25_get_neigh() in x25_connect(),
causing a refcnt leak.

Fix this issue by calling x25_neigh_put() before x25_disconnect()
returns.

Signed-off-by: Xiyu Yang 
Signed-off-by: Xin Tan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rds: Prevent kernel-infoleak in rds_notify_queue_get()

2020-08-05T07:59:44+00:00

commit bbc8a99e952226c585ac17477a85ef1194501762 upstream.

rds_notify_queue_get() is potentially copying uninitialized kernel stack
memory to userspace since the compiler may leave a 4-byte hole at the end
of `cmsg`.

In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which
unfortunately does not always initialize that 4-byte hole. Fix it by using
memset() instead.

Cc: stable@vger.kernel.org
Fixes: f037590fff30 ("rds: fix a leak of kernel memory")
Fixes: bdbe6fbc6a2f ("RDS: recv.c")
Suggested-by: Dan Carpenter 
Signed-off-by: Peilin Ye 
Acked-by: Santosh Shilimkar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work

2020-08-05T07:59:42+00:00

commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29 upstream.

p9_read_work and p9_fd_cancelled may be called concurrently.
In some cases, req->req_list may be deleted by both p9_read_work
and p9_fd_cancelled.

We can fix it by ignoring replies associated with a cancelled
request and ignoring cancelled request if message has been received
before lock.

Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com
Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to "cancelled" function")
Cc:  # v3.12+
Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com
Signed-off-by: Wang Hai 
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

sunrpc: check that domain table is empty at module unload.

2020-08-05T07:59:41+00:00

[ Upstream commit f45db2b909c7e76f35850e78f017221f30282b8e ]

The domain table should be empty at module unload.  If it isn't there is
a bug somewhere.  So check and report.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

udp: Improve load balancing for SO_REUSEPORT.

2020-07-31T16:39:31+00:00

[ Upstream commit efc6b6f6c3113e8b203b9debfb72d81e0f3dcace ]

Currently, SO_REUSEPORT does not work well if connected sockets are in a
UDP reuseport group.

Then reuseport_has_conns() returns true and the result of
reuseport_select_sock() is discarded. Also, unconnected sockets have the
same score, hence only does the first unconnected socket in udp_hslot
always receive all packets sent to unconnected sockets.

So, the result of reuseport_select_sock() should be used for load
balancing.

The noteworthy point is that the unconnected sockets placed after
connected sockets in sock_reuseport.socks will receive more packets than
others because of the algorithm in reuseport_select_sock().

    index | connected | reciprocal_scale | result
    ---------------------------------------------
    0     | no        | 20%              | 40%
    1     | no        | 20%              | 20%
    2     | yes       | 20%              | 0%
    3     | no        | 20%              | 40%
    4     | yes       | 20%              | 0%

If most of the sockets are connected, this can be a problem, but it still
works better than now.

Fixes: acdcecc61285 ("udp: correct reuseport selection with connected sockets")
CC: Willem de Bruijn 
Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Kuniyuki Iwashima 
Acked-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman