commit cfb41ef9deb1e6572ac218ddfcec9567e5d1c101 Author: Greg Kroah-Hartman Date: Wed Jun 16 11:53:05 2021 +0200 Linux 4.14.237 Link: https://lore.kernel.org/r/20210614102641.857724541@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c4eec37de4d7bc26659bc9633b05c1b51a1b3607 Author: Linus Torvalds Date: Tue Jun 15 09:26:19 2021 -0700 proc: only require mm_struct for writing commit 94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 upstream. Commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") we started using __mem_open() to track the mm_struct at open-time, so that we could then check it for writes. But that also ended up making the permission checks at open time much stricter - and not just for writes, but for reads too. And that in turn caused a regression for at least Fedora 29, where NIC interfaces fail to start when using NetworkManager. Since only the write side wanted the mm_struct test, ignore any failures by __mem_open() at open time, leaving reads unaffected. The write() time verification of the mm_struct pointer will then catch the failure case because a NULL pointer will not match a valid 'current->mm'. Link: https://lore.kernel.org/netdev/YMjTlp2FSJYvoyFa@unreal/ Fixes: 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") Reported-and-tested-by: Leon Romanovsky Cc: Kees Cook Cc: Christian Brauner Cc: Andrea Righi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2d598902799886d67947406f26ee8e5fd2ca097f Author: Liangyan Date: Mon Jun 7 20:57:34 2021 +0800 tracing: Correct the length check which causes memory corruption commit 3e08a9f9760f4a70d633c328a76408e62d6f80a3 upstream. We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. Link: https://lkml.kernel.org/r/20210607125734.1770447-1-liangyan.peng@linux.alibaba.com Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Xunlei Pang Cc: Greg Kroah-Hartman Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer") Reviewed-by: Xunlei Pang Reviewed-by: yinbinbin Reviewed-by: Wetp Zhang Tested-by: James Wang Signed-off-by: Liangyan Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit acf671ba79c1feccc3ec7cfdcffead4efcec49e7 Author: Steven Rostedt (VMware) Date: Mon Jun 7 21:39:08 2021 -0400 ftrace: Do not blindly read the ip address in ftrace_bug() commit 6c14133d2d3f768e0a35128faac8aa6ed4815051 upstream. It was reported that a bug on arm64 caused a bad ip address to be used for updating into a nop in ftrace_init(), but the error path (rightfully) returned -EINVAL and not -EFAULT, as the bug caused more than one error to occur. But because -EINVAL was returned, the ftrace_bug() tried to report what was at the location of the ip address, and read it directly. This caused the machine to panic, as the ip was not pointing to a valid memory address. Instead, read the ip address with copy_from_kernel_nofault() to safely access the memory, and if it faults, report that the address faulted, otherwise report what was in that location. Link: https://lore.kernel.org/lkml/20210607032329.28671-1-mark-pk.tsai@mediatek.com/ Cc: stable@vger.kernel.org Fixes: 05736a427f7e1 ("ftrace: warn on failure to disable mcount callers") Reported-by: Mark-PK Tsai Tested-by: Mark-PK Tsai Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 07cc88bc484c4e4e5ce3b7b2f22a65f776da4b72 Author: Ming Lei Date: Wed Jun 2 21:30:29 2021 +0800 scsi: core: Only put parent device if host state differs from SHOST_CREATED commit 1e0d4e6225996f05271de1ebcb1a7c9381af0b27 upstream. get_device(shost->shost_gendev.parent) is called after host state has switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the parent device if host state is still SHOST_CREATED. Link: https://lore.kernel.org/r/20210602133029.2864069-5-ming.lei@redhat.com Cc: Bart Van Assche Cc: John Garry Cc: Hannes Reinecke Tested-by: John Garry Reviewed-by: John Garry Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c5711c21f9d2e6284d8f75f860a7df3c4cc9d9fe Author: Ming Lei Date: Wed Jun 2 21:30:28 2021 +0800 scsi: core: Put .shost_dev in failure path if host state changes to RUNNING commit 11714026c02d613c30a149c3f4c4a15047744529 upstream. scsi_host_dev_release() only frees dev_name when host state is SHOST_CREATED. After host state has changed to SHOST_RUNNING, scsi_host_dev_release() no longer cleans up. Fix this by doing a put_device(&shost->shost_dev) in the failure path when host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put on this reference. Link: https://lore.kernel.org/r/20210602133029.2864069-4-ming.lei@redhat.com Cc: Bart Van Assche Cc: Hannes Reinecke Reported-by: John Garry Tested-by: John Garry Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit db08ce595dd64ea9859f7d088b51cbfc8e685c66 Author: Ming Lei Date: Wed Jun 2 21:30:26 2021 +0800 scsi: core: Fix error handling of scsi_host_alloc() commit 66a834d092930cf41d809c0e989b13cd6f9ca006 upstream. After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well. Link: https://lore.kernel.org/r/20210602133029.2864069-2-ming.lei@redhat.com Cc: Bart Van Assche Cc: John Garry Cc: Hannes Reinecke Tested-by: John Garry Reviewed-by: Bart Van Assche Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bc2b500da4d1d7e7da5b3b758f9773125ad0aeaf Author: Dai Ngo Date: Wed May 19 17:15:10 2021 -0400 NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error. commit f8849e206ef52b584cd9227255f4724f0cc900bb upstream. Currently if __nfs4_proc_set_acl fails with NFS4ERR_BADOWNER it re-enables the idmapper by clearing NFS_CAP_UIDGID_NOMAP before retrying again. The NFS_CAP_UIDGID_NOMAP remains cleared even if the retry fails. This causes problem for subsequent setattr requests for v4 server that does not have idmapping configured. This patch modifies nfs4_proc_set_acl to detect NFS4ERR_BADOWNER and NFS4ERR_BADNAME and skips the retry, since the kernel isn't involved in encoding the ACEs, and return -EINVAL. Steps to reproduce the problem: # mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt # touch /tmp/mnt/file1 # chown 99 /tmp/mnt/file1 # nfs4_setfacl -a A::unknown.user@xyz.com:wrtncy /tmp/mnt/file1 Failed setxattr operation: Invalid argument # chown 99 /tmp/mnt/file1 chown: changing ownership of ‘/tmp/mnt/file1’: Invalid argument # umount /tmp/mnt # mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt # chown 99 /tmp/mnt/file1 # v2: detect NFS4ERR_BADOWNER and NFS4ERR_BADNAME and skip retry in nfs4_proc_set_acl. Signed-off-by: Dai Ngo Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c7eab9e2d7b4e983ce280276fb920af649955897 Author: Anna Schumaker Date: Wed Jun 2 14:31:20 2021 -0400 NFS: Fix use-after-free in nfs4_init_client() commit 476bdb04c501fc64bf3b8464ffddefc8dbe01577 upstream. KASAN reports a use-after-free when attempting to mount two different exports through two different NICs that belong to the same server. Olga was able to hit this with kernels starting somewhere between 5.7 and 5.10, but I traced the patch that introduced the clear_bit() call to 4.13. So something must have changed in the refcounting of the clp pointer to make this call to nfs_put_client() the very last one. Fixes: 8dcbec6d20 ("NFSv41: Handle EXCHID4_FLAG_CONFIRMED_R during NFSv4.1 migration") Cc: stable@vger.kernel.org # 4.13+ Signed-off-by: Anna Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 5d10b598e695be25f919fd6a80d77adf71070096 Author: Paolo Bonzini Date: Wed Jun 9 01:49:13 2021 -0400 kvm: fix previous commit for 32-bit builds commit 4422829e8053068e0225e4d0ef42dc41ea7c9ef5 upstream. array_index_nospec does not work for uint64_t on 32-bit builds. However, the size of a memory slot must be less than 20 bits wide on those system, since the memory slot must fit in the user address space. So just store it in an unsigned long. Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f80aa52ef6a762845832648015e875695dcbf440 Author: Leo Yan Date: Sat Jun 5 13:29:57 2021 +0800 perf session: Correct buffer copying when peeking events [ Upstream commit 197eecb6ecae0b04bd694432f640ff75597fed9c ] When peeking an event, it has a short path and a long path. The short path uses the session pointer "one_mmap_addr" to directly fetch the event; and the long path needs to read out the event header and the following event data from file and fill into the buffer pointer passed through the argument "buf". The issue is in the long path that it copies the event header and event data into the same destination address which pointer "buf", this means the event header is overwritten. We are just lucky to run into the short path in most cases, so we don't hit the issue in the long path. This patch adds the offset "hdr_sz" to the pointer "buf" when copying the event data, so that it can reserve the event header which can be used properly by its caller. Fixes: 5a52f33adf02 ("perf session: Add perf_session__peek_event()") Signed-off-by: Leo Yan Acked-by: Adrian Hunter Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210605052957.1070720-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 634f17ff1d59905eb3b4bbbc00805961d08beaee Author: Dan Carpenter Date: Thu Jun 3 15:37:53 2021 +0300 NFS: Fix a potential NULL dereference in nfs_get_client() [ Upstream commit 09226e8303beeec10f2ff844d2e46d1371dc58e0 ] None of the callers are expecting NULL returns from nfs_get_client() so this code will lead to an Oops. It's better to return an error pointer. I expect that this is dead code so hopefully no one is affected. Fixes: 31434f496abb ("nfs: check hostname in nfs_get_client") Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit e0e5c5ea305d21a4f8a3f8ac0b1a47fc7591d492 Author: Marco Elver Date: Thu May 27 12:47:11 2021 +0200 perf: Fix data race between pin_count increment/decrement commit 6c605f8371159432ec61cbb1488dcf7ad24ad19a upstream. KCSAN reports a data race between increment and decrement of pin_count: write to 0xffff888237c2d4e0 of 4 bytes by task 15740 on cpu 1: find_get_context kernel/events/core.c:4617 __do_sys_perf_event_open kernel/events/core.c:12097 [inline] __se_sys_perf_event_open kernel/events/core.c:11933 ... read to 0xffff888237c2d4e0 of 4 bytes by task 15743 on cpu 0: perf_unpin_context kernel/events/core.c:1525 [inline] __do_sys_perf_event_open kernel/events/core.c:12328 [inline] __se_sys_perf_event_open kernel/events/core.c:11933 ... Because neither read-modify-write here is atomic, this can lead to one of the operations being lost, resulting in an inconsistent pin_count. Fix it by adding the missing locking in the CPU-event case. Fixes: fe4b04fa31a6 ("perf: Cure task_oncpu_function_call() races") Reported-by: syzbot+142c9018f5962db69c7e@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210527104711.2671610-1-elver@google.com Signed-off-by: Greg Kroah-Hartman commit df223b0da87a2f530d280286ec3ab2209528f1dc Author: Dmitry Osipenko Date: Mon May 24 01:42:42 2021 +0300 regulator: max77620: Use device_set_of_node_from_dev() commit 6f55c5dd1118b3076d11d9cb17f5c5f4bc3a1162 upstream. The MAX77620 driver fails to re-probe on deferred probe because driver core tries to claim resources that are already claimed by the PINCTRL device. Use device_set_of_node_from_dev() helper which marks OF node as reused, skipping erroneous execution of pinctrl_bind_pins() for the PMIC device on the re-probe. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210523224243.13219-2-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dd01a63547d8be96b2a300c282983716c0186f65 Author: Dmitry Baryshkov Date: Thu May 20 01:12:23 2021 +0300 regulator: core: resolve supply for boot-on/always-on regulators commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 70cd19cb5bd94bbb5bacfc9c1e4ee0071699a604 Author: Maciej Żenczykowski Date: Tue Jun 8 19:44:59 2021 -0700 usb: fix various gadget panics on 10gbps cabling commit 032e288097a553db5653af552dd8035cd2a0ba96 upstream. usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). Cc: Felipe Balbi Cc: Greg Kroah-Hartman Signed-off-by: Maciej Żenczykowski Cc: stable Link: https://lore.kernel.org/r/20210609024459.1126080-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8cd5f45c1b769e3e9e0f4325dd08b6c3749dc7ee Author: Maciej Żenczykowski Date: Mon Jun 7 21:41:41 2021 -0700 usb: fix various gadgets null ptr deref on 10gbps cabling. commit 90c4d05780d47e14a50e11a7f17373104cd47d25 upstream. This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps. Fixes: eaef50c76057 ("usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus") Cc: Christophe JAILLET Cc: Felipe Balbi Cc: Gustavo A. R. Silva Cc: Lorenzo Colitti Cc: Martin K. Petersen Cc: Michael R Sweet Cc: Mike Christie Cc: Pawel Laszczak Cc: Peter Chen Cc: Sudhakar Panneerselvam Cc: Wei Ming Chen Cc: Will McVicker Cc: Zqiang Reviewed-By: Lorenzo Colitti Cc: stable Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210608044141.3898496-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit 29f13b2f28a6ab721aadb126878ed842ce278462 Author: Linyu Yuan Date: Wed Jun 9 07:35:47 2021 +0800 usb: gadget: eem: fix wrong eem header operation commit 305f670846a31a261462577dd0b967c4fa796871 upstream. when skb_clone() or skb_copy_expand() fail, it should pull skb with lengh indicated by header, or not it will read network data and check it as header. Cc: Signed-off-by: Linyu Yuan Link: https://lore.kernel.org/r/20210608233547.3767-1-linyyuan@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit dbb7504e7e9ed1cfc50cf7176b1df66f635d2fec Author: Johan Hovold Date: Mon May 24 11:17:05 2021 +0200 USB: serial: quatech2: fix control-request directions commit eb8dbe80326c3d44c1e38ee4f40e0d8d3e06f2d0 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the three requests which erroneously used usb_rcvctrlpipe(). Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5a1652ac6d631a4f1df07915fcd5368b11e43fc9 Author: Alexandre GRIVEAUX Date: Sun May 23 18:35:21 2021 +0200 USB: serial: omninet: add device id for Zyxel Omni 56K Plus commit fc0b3dc9a11771c3919eaaaf9d649138b095aa0f upstream. Add device id for Zyxel Omni 56K Plus modem, this modem include: USB chip: NetChip NET2888 Main chip: 901041A F721501APGF Another modem using the same chips is the Zyxel Omni 56K DUO/NEO, could be added with the right USB ID. Signed-off-by: Alexandre GRIVEAUX Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 676309e2f56d9fd4a4a0987c084e9c097f0d3e03 Author: George McCollister Date: Thu Jun 3 19:32:08 2021 -0500 USB: serial: ftdi_sio: add NovaTech OrionMX product ID commit bc96c72df33ee81b24d87eab953c73f7bcc04f29 upstream. Add PID for the NovaTech OrionMX so it can be automatically detected. Signed-off-by: George McCollister Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d06e7f8f564ce09e4a1c62c677b165e6f19217ef Author: Wesley Cheng Date: Fri May 21 17:44:21 2021 -0700 usb: gadget: f_fs: Ensure io_completion_wq is idle during unbind commit 6fc1db5e6211e30fbb1cee8d7925d79d4ed2ae14 upstream. During unbind, ffs_func_eps_disable() will be executed, resulting in completion callbacks for any pending USB requests. When using AIO, irrespective of the completion status, io_data work is queued to io_completion_wq to evaluate and handle the completed requests. Since work runs asynchronously to the unbind() routine, there can be a scenario where the work runs after the USB gadget has been fully removed, resulting in accessing of a resource which has been already freed. (i.e. usb_ep_free_request() accessing the USB ep structure) Explicitly drain the io_completion_wq, instead of relying on the destroy_workqueue() (in ffs_data_put()) to make sure no pending completion work items are running. Signed-off-by: Wesley Cheng Cc: stable Link: https://lore.kernel.org/r/1621644261-1236-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 47d655b4e9ba454927e8345f03bf26a6d8c1e837 Author: Mayank Rana Date: Wed Jun 9 00:35:35 2021 -0700 usb: typec: ucsi: Clear PPM capability data in ucsi_init() error path commit f247f0a82a4f8c3bfed178d8fd9e069d1424ee4e upstream. If ucsi_init() fails for some reason (e.g. ucsi_register_port() fails or general communication failure to the PPM), particularly at any point after the GET_CAPABILITY command had been issued, this results in unwinding the initialization and returning an error. However the ucsi structure's ucsi_capability member retains its current value, including likely a non-zero num_connectors. And because ucsi_init() itself is done in a workqueue a UCSI interface driver will be unaware that it failed and may think the ucsi_register() call was completely successful. Later, if ucsi_unregister() is called, due to this stale ucsi->cap value it would try to access the items in the ucsi->connector array which might not be in a proper state or not even allocated at all and results in NULL or invalid pointer dereference. Fix this by clearing the ucsi->cap value to 0 during the error path of ucsi_init() in order to prevent a later ucsi_unregister() from entering the connector cleanup loop. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus Signed-off-by: Mayank Rana Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210609073535.5094-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 990dc90750772622d44ca2ea6652c521e6f67e16 Author: Marian-Cristian Rotariu Date: Tue Jun 8 19:26:50 2021 +0300 usb: dwc3: ep0: fix NULL pointer exception commit d00889080ab60051627dab1d85831cd9db750e2a upstream. There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing. By adding this validation from the patch we can actually report a wrong index back to the caller. In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation. [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]--- Signed-off-by: Marian-Cristian Rotariu Cc: stable Link: https://lore.kernel.org/r/20210608162650.58426-1-marian.c.rotariu@gmail.com Signed-off-by: Greg Kroah-Hartman commit 988f0fd8809f0abf6050de6632d51897b06d69ec Author: Maciej Żenczykowski Date: Mon Jun 7 17:53:44 2021 -0700 USB: f_ncm: ncm_bitrate (speed) is unsigned commit 3370139745853f7826895293e8ac3aec1430508e upstream. [ 190.544755] configfs-gadget gadget: notify speed -44967296 This is because 4250000000 - 2**32 is -44967296. Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Cc: Brooke Basile Cc: Bryan O'Donoghue Cc: Felipe Balbi Cc: Lorenzo Colitti Cc: Yauheni Kaliuta Cc: Linux USB Mailing List Acked-By: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Cc: stable Link: https://lore.kernel.org/r/20210608005344.3762668-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit d2625eba1e9653e3333c12158b4e8958ffdc0fe4 Author: Alexander Kuznetsov Date: Wed Jun 9 10:17:19 2021 +0300 cgroup1: don't allow '\n' in renaming commit b7e24eb1caa5f8da20d405d262dba67943aedc42 upstream. cgroup_mkdir() have restriction on newline usage in names: $ mkdir $'/sys/fs/cgroup/cpu/test\ntest2' mkdir: cannot create directory '/sys/fs/cgroup/cpu/test\ntest2': Invalid argument But in cgroup1_rename() such check is missed. This allows us to make /proc//cgroup unparsable: $ mkdir /sys/fs/cgroup/cpu/test $ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2' $ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2' $ cat /proc/self/cgroup 11:pids:/ 10:freezer:/ 9:hugetlb:/ 8:cpuset:/ 7:blkio:/user.slice 6:memory:/user.slice 5:net_cls,net_prio:/ 4:perf_event:/ 3:devices:/user.slice 2:cpu,cpuacct:/test test2 1:name=systemd:/ 0::/ Signed-off-by: Alexander Kuznetsov Reported-by: Andrey Krasichkov Acked-by: Dmitry Yakunin Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 97f56d0b433bf7861d11749fc6bcc409b0a91217 Author: Ritesh Harjani Date: Sun May 30 20:24:05 2021 +0530 btrfs: return value from btrfs_mark_extent_written() in case of error commit e7b2ec3d3d4ebeb4cff7ae45cf430182fa6a49fb upstream. We always return 0 even in case of an error in btrfs_mark_extent_written(). Fix it to return proper error value in case of a failure. All callers handle it. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Ritesh Harjani Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8d9d475bb17e7b9ce0690de6a71d6c0b7785db34 Author: Wenli Looi Date: Mon Jun 7 23:46:20 2021 -0700 staging: rtl8723bs: Fix uninitialized variables commit 43c85d770db80cb135f576f8fde6ff1a08e707a4 upstream. The sinfo.pertid and sinfo.generation variables are not initialized and it causes a crash when we use this as a wireless access point. [ 456.873025] ------------[ cut here ]------------ [ 456.878198] kernel BUG at mm/slub.c:3968! [ 456.882680] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ snip ] [ 457.271004] Backtrace: [ 457.273733] [] (kfree) from [] (nl80211_send_station+0x954/0xfc4) [ 457.282481] r9:eccca0c0 r8:e8edfec0 r7:00000000 r6:00000011 r5:e80a9480 r4:e8edfe00 [ 457.291132] [] (nl80211_send_station) from [] (cfg80211_new_sta+0x90/0x1cc) [ 457.300850] r10:e80a9480 r9:e8edfe00 r8:ea678cca r7:00000a20 r6:00000000 r5:ec46d000 [ 457.309586] r4:ec46d9e0 [ 457.312433] [] (cfg80211_new_sta) from [] (rtw_cfg80211_indicate_sta_assoc+0x80/0x9c [r8723bs]) [ 457.324095] r10:00009930 r9:e85b9d80 r8:bf091050 r7:00000000 r6:00000000 r5:0000001c [ 457.332831] r4:c1606788 [ 457.335692] [] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [] (rtw_stassoc_event_callback+0x1c8/0x1d4 [r8723bs]) [ 457.349489] r7:ea678cc0 r6:000000a1 r5:f1225f84 r4:f086b000 [ 457.355845] [] (rtw_stassoc_event_callback [r8723bs]) from [] (mlme_evt_hdl+0x8c/0xb4 [r8723bs]) [ 457.367601] r7:c1604900 r6:f086c4b8 r5:00000000 r4:f086c000 [ 457.373959] [] (mlme_evt_hdl [r8723bs]) from [] (rtw_cmd_thread+0x198/0x3d8 [r8723bs]) [ 457.384744] r5:f086e000 r4:f086c000 [ 457.388754] [] (rtw_cmd_thread [r8723bs]) from [] (kthread+0x170/0x174) [ 457.398083] r10:ed7a57e8 r9:bf0367a4 r8:f086b000 r7:e8ede000 r6:00000000 r5:e9975200 [ 457.406828] r4:e8369900 [ 457.409653] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 457.417718] Exception stack(0xe8edffb0 to 0xe8edfff8) [ 457.423356] ffa0: 00000000 00000000 00000000 00000000 [ 457.432492] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 457.441618] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 457.449006] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a0a4 [ 457.457750] r4:e9975200 [ 457.460574] Code: 1a000003 e5953004 e3130001 1a000000 (e7f001f2) [ 457.467381] ---[ end trace 4acbc8c15e9e6aa7 ]--- Link: https://forum.armbian.com/topic/14727-wifi-ap-kernel-bug-in-kernel-5444/ Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info") Fixes: f5ea9120be2e ("nl80211: add generation number to all dumps") Signed-off-by: Wenli Looi Reviewed-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/20210608064620.74059-1-wlooi@ucalgary.ca Signed-off-by: Greg Kroah-Hartman commit 361ce3b917aff93123e9e966d8608655c967f438 Author: Paolo Bonzini Date: Tue Jun 8 15:31:42 2021 -0400 kvm: avoid speculation-based attacks from out-of-range memslot accesses commit da27a83fd6cc7780fea190e1f5c19e87019da65c upstream. KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses. Reported-by: Artemiy Margaritov Co-developed-by: Artemiy Margaritov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b235f1037c0f9253ae45ff440a33a93e964ad2ec Author: Desmond Cheong Zhi Xi Date: Wed Jun 9 17:21:19 2021 +0800 drm: Lock pointer access in drm_master_release() commit c336a5ee984708db4826ef9e47d184e638e29717 upstream. This patch eliminates the following smatch warning: drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access 'master' (line 318) expected lock '&dev->master_mutex' The 'file_priv->master' field should be protected by the mutex lock to '&dev->master_mutex'. This is because other processes can concurrently modify this field and free the current 'file_priv->master' pointer. This could result in a use-after-free error when 'master' is dereferenced in subsequent function calls to 'drm_legacy_lock_master_cleanup()' or to 'drm_lease_revoke()'. An example of a scenario that would produce this error can be seen from a similar bug in 'drm_getunique()' that was reported by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the Syzbot report, another process concurrently acquired the device's master mutex in 'drm_setmaster_ioctl()', then overwrote 'fpriv->master' in 'drm_new_set_master()'. The old value of 'fpriv->master' was subsequently freed before the mutex was unlocked. Reported-by: Dan Carpenter Signed-off-by: Desmond Cheong Zhi Xi Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210609092119.173590-1-desmondcheongzx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 17dab9326ff263c62dab1dbac4492e2938a049e4 Author: Desmond Cheong Zhi Xi Date: Tue Jun 8 19:04:36 2021 +0800 drm: Fix use-after-free read in drm_getunique() commit b436acd1cf7fac0ba987abd22955d98025c80c2b upstream. There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report of the use-after-free error found by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master pointer was used after being freed. This is because another process had acquired the device's master mutex in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot reproducer test. Reported-by: syzbot+c3a706cec1ea99e1c693@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210608110436.239583-1-desmondcheongzx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 652f36079f84e80b81e45cf7da4f7a1890387805 Author: Chris Packham Date: Wed May 12 09:20:52 2021 +1200 i2c: mpc: implement erratum A-004447 workaround [ Upstream commit 8f0cdec8b5fd94135d643662506ee94ae9e98785 ] The P2040/P2041 has an erratum where the normal i2c recovery mechanism does not work. Implement the alternative recovery mechanism documented in the P2040 Chip Errata Rev Q. Signed-off-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ba900685ad6a32a7f986e1e6a0dc5c21f5f04593 Author: Chris Packham Date: Mon Mar 29 14:52:03 2021 +1300 i2c: mpc: Make use of i2c_recover_bus() [ Upstream commit 65171b2df15eb7545431d75c2729b5062da89b43 ] Move the existing calls of mpc_i2c_fixup() to a recovery function registered via bus_recovery_info. This makes it more obvious that recovery is supported and allows for a future where recovery is triggered by the i2c core. Signed-off-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit e49b75dc946ca71acbfa44d94cd0fac7115ab4fa Author: Chris Packham Date: Wed May 12 09:20:51 2021 +1200 powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers [ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ] The i2c controllers on the P1010 have an erratum where the documented scheme for i2c bus recovery will not work (A-004447). A different mechanism is needed which is documented in the P1010 Chip Errata Rev L. Signed-off-by: Chris Packham Acked-by: Michael Ellerman Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6da7f019db235464b4ed72ab4a92ee1bb1429d0c Author: Chris Packham Date: Wed May 12 09:20:50 2021 +1200 powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers [ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ] The i2c controllers on the P2040/P2041 have an erratum where the documented scheme for i2c bus recovery will not work (A-004447). A different mechanism is needed which is documented in the P2040 Chip Errata Rev Q (latest available at the time of writing). Signed-off-by: Chris Packham Acked-by: Michael Ellerman Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit e862f6000a3ac0e7454d0f43861327274e4d16bc Author: Jiapeng Chong Date: Tue May 25 19:00:12 2021 +0800 bnx2x: Fix missing error code in bnx2x_iov_init_one() [ Upstream commit 65161c35554f7135e6656b3df1ce2c500ca0bdcf ] Eliminate the follow smatch warning: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1227 bnx2x_iov_init_one() warn: missing error code 'err'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 93f5035182d1d93ea39e48b85dcdbdfbc6932c1a Author: Tiezhu Yang Date: Sat May 15 19:02:01 2021 +0800 MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACER [ Upstream commit 78cf0eb926cb1abeff2106bae67752e032fe5f3e ] When update the latest mainline kernel with the following three configs, the kernel hangs during startup: (1) CONFIG_FUNCTION_GRAPH_TRACER=y (2) CONFIG_PREEMPT_TRACER=y (3) CONFIG_FTRACE_STARTUP_TEST=y When update the latest mainline kernel with the above two configs (1) and (2), the kernel starts normally, but it still hangs when execute the following command: echo "function_graph" > /sys/kernel/debug/tracing/current_tracer Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences with function_graph tracer at the first glance. I use ejtag to find out the epc address is related with preempt_enable() in the file arch/mips/lib/mips-atomic.c, because function tracing can trace the preempt_{enable,disable} calls that are traced, replace them with preempt_{enable,disable}_notrace to prevent function tracing from going into an infinite loop, and then it can fix the kernel hang issue. By the way, it seems that this commit is a complement and improvement of commit f93a1a00f2bd ("MIPS: Fix crash that occurs when function tracing is enabled"). Signed-off-by: Tiezhu Yang Cc: Steven Rostedt Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1ca867fb122f1d8b1e4449c382d58c975fe403a3 Author: Saubhik Mukherjee Date: Mon May 24 19:07:12 2021 +0530 net: appletalk: cops: Fix data race in cops_probe1 [ Upstream commit a4dd4fc6105e54393d637450a11d4cddb5fabc4f ] In cops_probe1(), there is a write to dev->base_addr after requesting an interrupt line and registering the interrupt handler cops_interrupt(). The handler might be called in parallel to handle an interrupt. cops_interrupt() tries to read dev->base_addr leading to a potential data race. So write to dev->base_addr before calling request_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Saubhik Mukherjee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4df0fc29401a142cad9a23b373316267fc636e74 Author: Zong Li Date: Sat May 22 17:16:11 2021 +0800 net: macb: ensure the device is available before accessing GEMGXL control registers [ Upstream commit 5eff1461a6dec84f04fafa9128548bad51d96147 ] If runtime power menagement is enabled, the gigabit ethernet PLL would be disabled after macb_probe(). During this period of time, the system would hang up if we try to access GEMGXL control registers. We can't put runtime_pm_get/runtime_pm_put/ there due to the issue of sleep inside atomic section (7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context"). Add netif_running checking to ensure the device is available before accessing GEMGXL device. Changed in v2: - Use netif_running instead of its own flag Signed-off-by: Zong Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 81d3e4935d80d6d572b93234f7fe38d0f06a7160 Author: Dmitry Bogdanov Date: Thu Apr 15 23:35:54 2021 +0300 scsi: target: qla2xxx: Wait for stop_phase1 at WWN removal [ Upstream commit 2ef7665dfd88830f15415ba007c7c9a46be7acd8 ] Target de-configuration panics at high CPU load because TPGT and WWPN can be removed on separate threads. TPGT removal requests a reset HBA on a separate thread and waits for reset complete (phase1). Due to high CPU load that HBA reset can be delayed for some time. WWPN removal does qlt_stop_phase2(). There it is believed that phase1 has already completed and thus tgt.tgt_ops is subsequently cleared. However, tgt.tgt_ops is needed to process incoming traffic and therefore this will cause one of the following panics: NIP qlt_reset+0x7c/0x220 [qla2xxx] LR qlt_reset+0x68/0x220 [qla2xxx] Call Trace: 0xc000003ffff63a78 (unreliable) qlt_handle_imm_notify+0x800/0x10c0 [qla2xxx] qlt_24xx_atio_pkt+0x208/0x590 [qla2xxx] qlt_24xx_process_atio_queue+0x33c/0x7a0 [qla2xxx] qla83xx_msix_atio_q+0x54/0x90 [qla2xxx] or NIP qlt_24xx_handle_abts+0xd0/0x2a0 [qla2xxx] LR qlt_24xx_handle_abts+0xb4/0x2a0 [qla2xxx] Call Trace: qlt_24xx_handle_abts+0x90/0x2a0 [qla2xxx] (unreliable) qlt_24xx_process_atio_queue+0x500/0x7a0 [qla2xxx] qla83xx_msix_atio_q+0x54/0x90 [qla2xxx] or NIP qlt_create_sess+0x90/0x4e0 [qla2xxx] LR qla24xx_do_nack_work+0xa8/0x180 [qla2xxx] Call Trace: 0xc0000000348fba30 (unreliable) qla24xx_do_nack_work+0xa8/0x180 [qla2xxx] qla2x00_do_work+0x674/0xbf0 [qla2xxx] qla2x00_iocb_work_fn The patch fixes the issue by serializing qlt_stop_phase1() and qlt_stop_phase2() functions to make WWPN removal wait for phase1 completion. Link: https://lore.kernel.org/r/20210415203554.27890-1-d.bogdanov@yadro.com Reviewed-by: Roman Bolshakov Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 976894b5cc9ea79e4682020771c8fa205341e09e Author: Matt Wang Date: Wed May 19 09:49:32 2021 +0000 scsi: vmw_pvscsi: Set correct residual data length [ Upstream commit e662502b3a782d479e67736a5a1c169a703d853a ] Some commands (such as INQUIRY) may return less data than the initiator requested. To avoid conducting useless information, set the right residual count to make upper layer aware of this. Before (INQUIRY PAGE 0xB0 with 128B buffer): $ sg_raw -r 128 /dev/sda 12 01 B0 00 80 00 SCSI Status: Good Received 128 bytes of data: 00 00 b0 00 3c 01 00 00 00 00 00 00 00 00 00 00 00 ...<............ 10 00 00 00 00 00 01 00 00 00 00 00 40 00 00 08 00 ...........@.... 20 80 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 .......... ..... 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ After: $ sg_raw -r 128 /dev/sda 12 01 B0 00 80 00 SCSI Status: Good Received 64 bytes of data: 00 00 b0 00 3c 01 00 00 00 00 00 00 00 00 00 00 00 ...<............ 10 00 00 00 00 00 01 00 00 00 00 00 40 00 00 08 00 ...........@.... 20 80 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 .......... ..... 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [mkp: clarified description] Link: https://lore.kernel.org/r/03C41093-B62E-43A2-913E-CFC92F1C70C3@vmware.com Signed-off-by: Matt Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b0b447bcdeda85fa66782ee8ea1758d55eeec224 Author: Zheyu Ma Date: Thu May 20 12:32:36 2021 +0000 net/qla3xxx: fix schedule while atomic in ql_sem_spinlock [ Upstream commit 13a6f3153922391e90036ba2267d34eed63196fc ] When calling the 'ql_sem_spinlock', the driver has already acquired the spin lock, so the driver should not call 'ssleep' in atomic context. This bug can be fixed by using 'mdelay' instead of 'ssleep'. The KASAN's log reveals it: [ 3.238124 ] BUG: scheduling while atomic: swapper/0/1/0x00000002 [ 3.238748 ] 2 locks held by swapper/0/1: [ 3.239151 ] #0: ffff88810177b240 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x41/0x60 [ 3.240026 ] #1: ffff888107c60e28 (&qdev->hw_lock){....}-{2:2}, at: ql3xxx_probe+0x2aa/0xea0 [ 3.240873 ] Modules linked in: [ 3.241187 ] irq event stamp: 460854 [ 3.241541 ] hardirqs last enabled at (460853): [] _raw_spin_unlock_irqrestore+0x4f/0x70 [ 3.242245 ] hardirqs last disabled at (460854): [] _raw_spin_lock_irqsave+0x2a/0x70 [ 3.242245 ] softirqs last enabled at (446076): [] __do_softirq+0x2e4/0x4b1 [ 3.242245 ] softirqs last disabled at (446069): [] irq_exit_rcu+0x100/0x110 [ 3.242245 ] Preemption disabled at: [ 3.242245 ] [] ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] Kernel panic - not syncing: scheduling while atomic [ 3.242245 ] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00145 -gee7dc339169-dirty #16 [ 3.242245 ] Call Trace: [ 3.242245 ] dump_stack+0xba/0xf5 [ 3.242245 ] ? ql3xxx_probe+0x1f0/0xea0 [ 3.242245 ] panic+0x15a/0x3f2 [ 3.242245 ] ? vprintk+0x76/0x150 [ 3.242245 ] ? ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] __schedule_bug+0xae/0xe0 [ 3.242245 ] __schedule+0x72e/0xa00 [ 3.242245 ] schedule+0x43/0xf0 [ 3.242245 ] schedule_timeout+0x28b/0x500 [ 3.242245 ] ? del_timer_sync+0xf0/0xf0 [ 3.242245 ] ? msleep+0x2f/0x70 [ 3.242245 ] msleep+0x59/0x70 [ 3.242245 ] ql3xxx_probe+0x307/0xea0 [ 3.242245 ] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [ 3.242245 ] ? pci_device_remove+0x110/0x110 [ 3.242245 ] local_pci_probe+0x45/0xa0 [ 3.242245 ] pci_device_probe+0x12b/0x1d0 [ 3.242245 ] really_probe+0x2a9/0x610 [ 3.242245 ] driver_probe_device+0x90/0x1d0 [ 3.242245 ] ? mutex_lock_nested+0x1b/0x20 [ 3.242245 ] device_driver_attach+0x68/0x70 [ 3.242245 ] __driver_attach+0x124/0x1b0 [ 3.242245 ] ? device_driver_attach+0x70/0x70 [ 3.242245 ] bus_for_each_dev+0xbb/0x110 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] driver_attach+0x27/0x30 [ 3.242245 ] bus_add_driver+0x1eb/0x2a0 [ 3.242245 ] driver_register+0xa9/0x180 [ 3.242245 ] __pci_register_driver+0x82/0x90 [ 3.242245 ] ? yellowfin_init+0x25/0x25 [ 3.242245 ] ql3xxx_driver_init+0x23/0x25 [ 3.242245 ] do_one_initcall+0x7f/0x3d0 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.242245 ] kernel_init_freeable+0x2aa/0x301 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] kernel_init+0x18/0x190 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ret_from_fork+0x1f/0x30 [ 3.242245 ] Dumping ftrace buffer: [ 3.242245 ] (ftrace buffer empty) [ 3.242245 ] Kernel Offset: disabled [ 3.242245 ] Rebooting in 1 seconds. Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ec32c8aee92a2750557c504eed3a04fe0500a725 Author: Sergey Senozhatsky Date: Thu May 20 19:14:22 2021 +0900 wq: handle VM suspension in stall detection [ Upstream commit 940d71c6462e8151c78f28e4919aa8882ff2054e ] If VCPU is suspended (VM suspend) in wq_watchdog_timer_fn() then once this VCPU resumes it will see the new jiffies value, while it may take a while before IRQ detects PVCLOCK_GUEST_STOPPED on this VCPU and updates all the watchdogs via pvclock_touch_watchdogs(). There is a small chance of misreported WQ stalls in the meantime, because new jiffies is time_after() old 'ts + thresh'. wq_watchdog_timer_fn() { for_each_pool(pool, pi) { if (time_after(jiffies, ts + thresh)) { pr_emerg("BUG: workqueue lockup - pool"); } } } Save jiffies at the beginning of this function and use that value for stall detection. If VM gets suspended then we continue using "old" jiffies value and old WQ touch timestamps. If IRQ at some point restarts the stall detection cycle (pvclock_touch_watchdogs()) then old jiffies will always be before new 'ts + thresh'. Signed-off-by: Sergey Senozhatsky Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 455c38eb8b351d11602836791a7c44f84f4f758f Author: Shakeel Butt Date: Wed May 12 13:19:46 2021 -0700 cgroup: disable controllers at parse time [ Upstream commit 45e1ba40837ac2f6f4d4716bddb8d44bd7e4a251 ] This patch effectively reverts the commit a3e72739b7a7 ("cgroup: fix too early usage of static_branch_disable()"). The commit 6041186a3258 ("init: initialize jump labels before command line option parsing") has moved the jump_label_init() before parse_args() which has made the commit a3e72739b7a7 unnecessary. On the other hand there are consequences of disabling the controllers later as there are subsystems doing the controller checks for different decisions. One such incident is reported [1] regarding the memory controller and its impact on memory reclaim code. [1] https://lore.kernel.org/linux-mm/921e53f3-4b13-aab8-4a9e-e83ff15371e4@nec.com Signed-off-by: Shakeel Butt Reported-by: NOMURA JUNICHI(野村　淳一) Signed-off-by: Tejun Heo Tested-by: Jun'ichi Nomura Signed-off-by: Sasha Levin commit c3a362beb86bcbd82792c824c8d5c8296d573999 Author: Dan Carpenter Date: Mon May 17 12:04:13 2021 +0300 net: mdiobus: get rid of a BUG_ON() [ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ] We spotted a bug recently during a review where a driver was unregistering a bus that wasn't registered, which would trigger this BUG_ON(). Let's handle that situation more gracefully, and just print a warning and return. Reported-by: Russell King (Oracle) Signed-off-by: Dan Carpenter Reviewed-by: Russell King (Oracle) Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 82b2ea5f904b3826934df4a00f3b8806272185f6 Author: Johannes Berg Date: Mon May 17 16:38:09 2021 +0200 netlink: disable IRQs for netlink_lock_table() [ Upstream commit 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d ] Syzbot reports that in mac80211 we have a potential deadlock between our "local->stop_queue_reasons_lock" (spinlock) and netlink's nl_table_lock (rwlock). This is because there's at least one situation in which we might try to send a netlink message with this spinlock held while it is also possible to take the spinlock from a hardirq context, resulting in the following deadlock scenario reported by lockdep: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); This seems valid, we can take the queue_stop_reason_lock in any kind of context ("CPU0"), and call ieee80211_report_ack_skb() with the spinlock held and IRQs disabled ("CPU1") in some code path (ieee80211_do_stop() via ieee80211_free_txskb()). Short of disallowing netlink use in scenarios like these (which would be rather complex in mac80211's case due to the deep callchain), it seems the only fix for this is to disable IRQs while nl_table_lock is held to avoid hitting this scenario, this disallows the "CPU0" portion of the reported deadlock. Note that the writer side (netlink_table_grab()) already disables IRQs for this lock. Unfortunately though, this seems like a huge hammer, and maybe the whole netlink table locking should be reworked. Reported-by: syzbot+69ff9dff50dcfe14ddd4@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1fb72dd4bcbce6eca085f7c1403e5b03d4e70f83 Author: Johannes Berg Date: Mon May 17 16:13:35 2021 +0200 bonding: init notify_work earlier to avoid uninitialized use [ Upstream commit 35d96e631860226d5dc4de0fad0a415362ec2457 ] If bond_kobj_init() or later kzalloc() in bond_alloc_slave() fail, then we call kobject_put() on the slave->kobj. This in turn calls the release function slave_kobj_release() which will always try to cancel_delayed_work_sync(&slave->notify_work), which shouldn't be done on an uninitialized work struct. Always initialize the work struct earlier to avoid problems here. Syzbot bisected this down to a completely pointless commit, some fault injection may have been at work here that caused the alloc failure in the first place, which may interact badly with bisect. Reported-by: syzbot+bfda097c12a00c8cae67@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a0a37e4454ca1c0b424edc2c9c2487c2c46a1be6 Author: Zheyu Ma Date: Sun May 16 07:11:40 2021 +0000 isdn: mISDN: netjet: Fix crash in nj_probe: [ Upstream commit 9f6f852550d0e1b7735651228116ae9d300f69b3 ] 'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested. Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'. The KASAN's log reveals it: [ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ... [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.362175 ] Call Trace: [ 3.362175 ] dump_stack+0xba/0xf5 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] panic+0x15a/0x3f2 [ 3.362175 ] ? __warn+0xf2/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] __warn+0x108/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] asm_exc_invalid_op+0x12/0x20 [ 3.362175 ] RIP: 0010:free_irq+0x100/0x480 [ 3.362175 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.362175 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.362175 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.362175 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.362175 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.362175 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.362175 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.362175 ] ? vprintk+0x76/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Dumping ftrace buffer: [ 3.362175 ] (ftrace buffer empty) [ 3.362175 ] Kernel Offset: disabled [ 3.362175 ] Rebooting in 1 seconds.. Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit db228da662ad923b1ec989ea5946ccdaedca005f Author: Zou Wei Date: Wed May 12 11:12:25 2021 +0800 ASoC: sti-sas: add missing MODULE_DEVICE_TABLE [ Upstream commit e072b2671606c77538d6a4dd5dda80b508cb4816 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Link: https://lore.kernel.org/r/1620789145-14936-1-git-send-email-zou_wei@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 38cb2e23188af29c43966acee9dbb18b62e26cfe Author: Jeimon Date: Sat May 8 11:52:30 2021 +0800 net/nfc/rawsock.c: fix a permission check bug [ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ] The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable(). Signed-off-by: Jeimon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e6d9c496384d480f373116b25de57b764d38e5c Author: Kees Cook Date: Tue Jun 8 10:12:21 2021 -0700 proc: Track /proc/$pid/attr/ opener mm_struct commit 591a22c14d3f45cc38bd1931c593c221df2f1881 upstream. Commit bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener") tried to make sure that there could not be a confusion between the opener of a /proc/$pid/attr/ file and the writer. It used struct cred to make sure the privileges didn't change. However, there were existing cases where a more privileged thread was passing the opened fd to a differently privileged thread (during container setup). Instead, use mm_struct to track whether the opener and writer are still the same process. (This is what several other proc files already do, though for different reasons.) Reported-by: Christian Brauner Reported-by: Andrea Righi Tested-by: Andrea Righi Fixes: bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman