- 02 Oct, 2018 40 commits
-
-
Matthew Auld authored
BugLink: https://bugs.launchpad.net/bugs/1792419 commit c11c7bfd upstream. Operating on a zero sized GEM userptr object will lead to explosions. Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Testcase: igt/gem_userptr_blits/input-checking Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Bartosz Golaszewski authored
BugLink: https://bugs.launchpad.net/bugs/1792419 commit 563a53f3 upstream. On non-OF systems spi->controlled_data may be NULL. This causes a NULL pointer derefence on dm365-evm. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1792419 Commit 136f55f6 ("net: lan78xx: fix rx handling before first packet is send") was not correctly backported to 4.4. The call to tasklet_schedule() belongs in lan78xx_link_reset(). Fixes: d1fc12d8 ("net: lan78xx: fix rx handling before first packet is send") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Chirantan Ekbote authored
BugLink: https://bugs.launchpad.net/bugs/1792419 commit d28c756c upstream. The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header. This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value. Tested by running `dd if=/dev/zero of=out bs=4k count=1` inside a virtio-9p mount. Link: http://lkml.kernel.org/r/20180717003529.114368-1-chirantan@chromium.orgSigned-off-by:
Chirantan Ekbote <chirantan@chromium.org> Reviewed-by:
Greg Kurz <groug@kaod.org> Tested-by:
Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by:
-
Alexander Aring authored
BugLink: https://bugs.launchpad.net/bugs/1792419 commit f9c52831 upstream. This patch is necessary if case of AF_PACKET or other socket interface which I am aware of it and didn't allocated the necessary room. Reported-by:
David Palma <david.palma@ntnu.no> Reported-by:
Rabi Narayan Sahoo <rabinarayans0828@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Alexander Aring <aring@mojatatu.com> Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Alexander Aring authored
BugLink: https://bugs.launchpad.net/bugs/1792419 commit ac74f87c upstream. This patch fixes patch add handling to take care tail and headroom for single 6lowpan frames. We need to be sure we have a skb with the right head and tailroom for single frames. This patch do it by using skb_copy_expand() if head and tailroom is not enough allocated by upper layer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059Reported-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1792392Signed-off-by:
-
Scott Bauer authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 8f3fafc9 upstream. Like d88b6d04: "cdrom: information leak in cdrom_ioctl_media_changed()" There is another cast from unsigned long to int which causes a bounds check to fail with specially crafted input. The value is then used as an index in the slot array in cdrom_slot_status(). Signed-off-by:
Scott Bauer <scott.bauer@intel.com> Signed-off-by:
Scott Bauer <sbauer@plzdonthack.me> Cc: stable@vger.kernel.org Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Mike Christie authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 26abc916 upstream. The problem is that iscsi_login_zero_tsih_s1 sets conn->sess early in iscsi_login_set_conn_values. If the function fails later like when we alloc the idr it does kfree(sess) and leaves the conn->sess pointer set. iscsi_login_zero_tsih_s1 then returns -Exyz and we then call iscsi_target_login_sess_out and access the freed memory. This patch has iscsi_login_zero_tsih_s1 either completely setup the session or completely tear it down, so later in iscsi_target_login_sess_out we can just check for it being set to the connection. Cc: stable@vger.kernel.org Fixes: 0957627a ("iscsi-target: Fix sess allocation leak in...") Signed-off-by:
Mike Christie <mchristi@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 0ee223b2 upstream. A long time ago the unfortunate decision was taken to add a self-deletion attribute to the sysfs SCSI device directory. That decision was unfortunate because self-deletion is really tricky. We can't drop that attribute because widely used user space software depends on it, namely the rescan-scsi-bus.sh script. Hence this patch that avoids that writing into that attribute triggers a deadlock. See also commit 7973cbd9 ("[PATCH] add sysfs attributes to scan and delete scsi_devices"). This patch avoids that self-removal triggers the following deadlock: ====================================================== WARNING: possible circular locking dependency detected 4.18.0-rc2-dbg+ #5 Not tainted ------------------------------------------------------ modprobe/6539 is trying to acquire lock: 000000008323c4cd (kn->count#202){++++}, at: kernfs_remove_by_name_ns+0x45/0x90 but task is already holding lock: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&shost->scan_mutex){+.+.}: __mutex_lock+0xfe/0xc70 mutex_lock_nested+0x1b/0x20 scsi_remove_device+0x26/0x40 [scsi_mod] sdev_store_delete+0x27/0x30 [scsi_mod] dev_attr_store+0x3e/0x50 sysfs_kf_write+0x87/0xa0 kernfs_fop_write+0x190/0x230 __vfs_write+0xd2/0x3b0 vfs_write+0x101/0x270 ksys_write+0xab/0x120 __x64_sys_write+0x43/0x50 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (kn->count#202){++++}: lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&shost->scan_mutex); lock(kn->count#202); lock(&shost->scan_mutex); lock(kn->count#202); *** DEADLOCK *** 2 locks held by modprobe/6539: #0: 00000000efaf9298 (&dev->mutex){....}, at: device_release_driver_internal+0x68/0x360 #1: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] stack backtrace: CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xa4/0xf5 print_circular_bug.isra.34+0x213/0x221 __lock_acquire+0x1a7e/0x1b50 lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe See also https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html. Fixes: ac0ece91 ("scsi: use device_remove_file_self() instead of device_schedule_callback()") Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Tejun Heo <tj@kernel.org> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 2afc9166 upstream. Introduce these two functions and export them such that the next patch can add calls to these functions from the SCSI core. Signed-off-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 690d9163 upstream. Some versions of GCC suboptimally generate calls to the __multi3() intrinsic for MIPS64r6 builds, resulting in link failures due to the missing function: LD vmlinux.o MODPOST vmlinux.o kernel/bpf/verifier.o: In function `kmalloc_array': include/linux/slab.h:631: undefined reference to `__multi3' fs/select.o: In function `kmalloc_array': include/linux/slab.h:631: undefined reference to `__multi3' ... We already have a workaround for this in which we provide the instrinsic, but we do so selectively for GCC 7 only. Unfortunately the issue occurs with older GCC versions too - it has been observed with both GCC 5.4.0 & GCC 6.4.0. MIPSr6 support was introduced in GCC 5, so all major GCC versions prior to GCC 8 are affected and we extend our workaround accordingly to all MIPS64r6 builds using GCC versions older than GCC 8. Signed-off-by:
Paul Burton <paul.burton@mips.com> Reported-by:
Vladimir Kondratiev <vladimir.kondratiev@intel.com> Fixes: ebabcf17 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") Patchwork: https://patchwork.linux-mips.org/patch/20297/ Cc: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # 4.15+ Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit f5958b4c upstream. Use the `unsigned long' rather than `__u32' type for DSP accumulator registers, like with the regular MIPS multiply/divide accumulator and general-purpose registers, as all are 64-bit in 64-bit implementations and using a 32-bit data type leads to contents truncation on context saving. Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing casts that are similarly not used with multiply/divide accumulator or general-purpose register accesses. Signed-off-by:
Maciej W. Rozycki <macro@mips.com> Signed-off-by:
-
Masami Hiramatsu authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit f2a3ab36 upstream. Since the blacklist and list files on debugfs indicates a sensitive address information to reader, it should be restricted to the root user. Suggested-by:
Thomas Richter <tmricht@linux.ibm.com> Suggested-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Howells <dhowells@redhat.com> Cc: David S . Miller <davem@davemloft.net> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Jon Medhurst <tixy@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tobin C . Harding <me@tobin.cc> Cc: Will Deacon <will.deacon@arm.com> Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491890171.9916.5183693615601334087.stgit@devboxSigned-off-by:
-
Julian Wiedmann authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 64e03ff7 upstream. When allocating a new AOB fails, handle_outbound() is still capable of transmitting the selected buffer (just without async completion). But if a previous transfer on this queue slot used async completion, its sbal_state flags field is still set to QDIO_OUTBUF_STATE_FLAG_PENDING. So when the upper layer driver sees this stale flag, it expects an async completion that never happens. Fix this by unconditionally clearing the flags field. Fixes: 104ea556 ("qdio: support asynchronous delivery of storage blocks") Cc: <stable@vger.kernel.org> #v3.2+ Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 26f84384 upstream. For machines without the exrl instruction the BFP jit generates code that uses an "br %r1" instruction located in the lowcore page. Unfortunately there is a cut & paste error that puts an additional "larl %r1,.+14" instruction in the code that clobbers the branch target address in %r1. Remove the larl instruction. Cc: <stable@vger.kernel.org> # v4.17+ Fixes: de5cb6eb ("s390: use expoline thunks in the BPF JIT") Signed-off-by:
-
Nick Desaulniers authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 1f59a458 upstream. This should have been marked extern inline in order to pick up the out of line definition in arch/x86/kernel/irqflags.S. Fixes: 208cbb32 ("x86/irqflags: Provide a declaration for native_save_fl") Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Juergen Gross <jgross@suse.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180827214011.55428-1-ndesaulniers@google.comSigned-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 19da44cd upstream. The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It has info->ngroups elements. Thus the > here should be >= to prevent reading one element beyond the end of the array. Cc: stable@vger.kernel.org Fixes: 30612cd9 ("pinctrl: imx1 core driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Uwe Kleine-König <u.kleine-könig@pengutronix.de> Acked-by:
Dong Aisheng <Aisheng.dong@nxp.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Gustavo A. R. Silva authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit ae1c696a upstream. There is a potential execution path in which function platform_get_resource() returns NULL. If this happens, we will end up having a NULL pointer dereference. Fix this by replacing devm_ioremap with devm_ioremap_resource, which has the NULL check and the memory region request. This code was detected with the help of Coccinelle. Cc: stable@vger.kernel.org Fixes: 2bd8d1d5 ("ASoC: sirf: Add audio usp interface driver") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Jerome Brunet authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 4febced1 upstream. When merging codec formats, dpcm_runtime_base_format() should skip the codecs which are not supporting the current stream direction. At the moment, if a BE link has more than one codec, and only one of these codecs has no capture DAI, it becomes impossible to start a capture stream because the merged format would be 0. Skipping invalid codec DAI solves the problem. Fixes: b073ed4e ("ASoC: soc-pcm: DPCM cares BE format") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Mikulas Patocka authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 09a00abe upstream. We must use kzalloc when allocating the fb_deferred_io structure. Otherwise, the field first_io is undefined and it causes a crash. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 542bb978 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udl kms driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by:
-
Mikulas Patocka authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 8456b99c upstream. If we leave urbs around, it causes not only leak, but also memory corruption. This patch fixes the function udl_free_urb_list, so that it always waits for all urbs that are in progress. Signed-off-by:
-
Kirill Tkhai authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 109728cc upstream. The above error path returns with page unlocked, so this place seems also to behave the same. Fixes: f8dbdf81 ("fuse: rework fuse_readpages()") Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit e8f3bd77 upstream. syzbot is hitting NULL pointer dereference at process_init_reply(). This is because deactivate_locked_super() is called before response for initial request is processed. Fix this by aborting and waiting for all requests (including FUSE_INIT) before resetting fc->sb. Original patch by Tetsuo Handa <penguin-kernel@I-love.SKAURA.ne.jp>. Reported-by:
syzbot <syzbot+b62f08f4d5857755e3bc@syzkaller.appspotmail.com> Fixes: e27c9d38 ("fuse: fuse: add time_gran to INIT_OUT") Cc: <stable@vger.kernel.org> # v3.19 Signed-off-by:
-
Miklos Szeredi authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit b8f95e5d upstream. fuse_abort_conn() does not guarantee that all async requests have actually finished aborting (i.e. their ->end() function is called). This could actually result in still used inodes after umount. Add a helper to wait until all requests are fully done. This is done by looking at the "num_waiting" counter. When this counter drops to zero, we can be sure that no more requests are outstanding. Fixes: 0d8e84b0 ("fuse: simplify request abort") Cc: <stable@vger.kernel.org> # v4.2 Signed-off-by:
-
Miklos Szeredi authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 45ff350b upstream. fuse_dev_release() assumes that it's the only one referencing the fpq->processing list, but that's not true, since fuse_abort_conn() can be doing the same without any serialization between the two. Fixes: c3696046 ("fuse: separate pqueue for clones") Cc: <stable@vger.kernel.org> # v4.2 Signed-off-by:
-
Miklos Szeredi authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 87114373 upstream. Refcounting of request is broken when fuse_abort_conn() is called and request is on the fpq->io list: - ref is taken too late - then it is not dropped Fixes: 0d8e84b0 ("fuse: simplify request abort") Cc: <stable@vger.kernel.org> # v4.2 Signed-off-by:
-
Andrey Ryabinin authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit a2477b0e upstream. fuse_dev_splice_write() reads pipe->buffers to determine the size of 'bufs' array before taking the pipe_lock(). This is not safe as another thread might change the 'pipe->buffers' between the allocation and taking the pipe_lock(). So we end up with too small 'bufs' array. Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this. Fixes: dd3bb14f ("fuse: support splice() writing to fuse device") Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> # v2.6.35 Signed-off-by:
-
Rian Hunter authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit dc76803e upstream. The consolidation of the start_thread() functions removed the export unintentionally. This breaks binfmt handlers built as a module. Add it back. Fixes: e634d8fc ("x86-64: merge the standard and compat start_thread() functions") Signed-off-by:
Rian Hunter <rian@alum.mit.edu> Signed-off-by:
-
Vlastimil Babka authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 6a012288 upstream. Two users have reported [1] that they have an "extremely unlikely" system with more than MAX_PA/2 memory and L1TF mitigation is not effective. Make the warning more helpful by suggesting the proper mem=X kernel boot parameter to make it effective and a link to the L1TF document to help decide if the mitigation is worth the unusable RAM. [1] https://bugzilla.suse.com/show_bug.cgi?id=1105536Suggested-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Acked-by:
-
Punit Agrawal authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 86658b81 upstream. Contention on updating a PMD entry by a large number of vcpus can lead to duplicate work when handling stage 2 page faults. As the page table update follows the break-before-make requirement of the architecture, it can lead to repeated refaults due to clearing the entry and flushing the tlbs. This problem is more likely when - * there are large number of vcpus * the mapping is large block mapping such as when using PMD hugepages (512MB) with 64k pages. Fix this by skipping the page table update if there is no change in the entry being updated. Cc: stable@vger.kernel.org Fixes: ad361f09 ("KVM: ARM: Support hugetlbfs backed huge pages") Reviewed-by:
Suzuki Poulose <suzuki.poulose@arm.com> Acked-by:
Christoffer Dall <christoffer.dall@arm.com> Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Punit Agrawal authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 976d34e2 upstream. When there is contention on faulting in a particular page table entry at stage 2, the break-before-make requirement of the architecture can lead to additional refaulting due to TLB invalidation. Avoid this by skipping a page table update if the new value of the PTE matches the previous value. Cc: stable@vger.kernel.org Fixes: d5d8184d ("KVM: ARM: Memory virtualization setup") Reviewed-by:
-
Greg Hackmann authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 5ad356ea upstream. ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input before seeing if the PFN is valid. This leads to false positives when some of the upper bits are set, but the lower bits match a valid PFN. For example, the following userspace code looks up a bogus entry in /proc/kpageflags: int pagemap = open("/proc/self/pagemap", O_RDONLY); int pageflags = open("/proc/kpageflags", O_RDONLY); uint64_t pfn, val; lseek64(pagemap, [...], SEEK_SET); read(pagemap, &pfn, sizeof(pfn)); if (pfn & (1UL << 63)) { /* valid PFN */ pfn &= ((1UL << 55) - 1); /* clear flag bits */ pfn |= (1UL << 55); lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET); read(pageflags, &val, sizeof(val)); } On ARM64 this causes the userspace process to crash with SIGSEGV rather than reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Fixes: c1cc1552 ("arm64: MMU initialisation") Cc: stable@vger.kernel.org Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Eric Sandeen authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit f39b3f45 upstream. When ext4_find_entry() falls back to "searching the old fashioned way" due to a corrupt dx dir, it needs to reset the error code to NULL so that the nonstandard ERR_BAD_DX_DIR code isn't returned to userspace. https://bugzilla.kernel.org/show_bug.cgi?id=199947Reported-by:
Anatoly Trosinenko <anatoly.trosinenko@yandex.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit a4d2aadc upstream. While working on extended rand for last_error/first_error timestamps, I noticed that the endianess is wrong; we access the little-endian fields in struct ext4_super_block as native-endian when we print them. This adds a special case in ext4_attr_show() and ext4_attr_store() to byteswap the superblock fields if needed. In older kernels, this code was part of super.c, it got moved to sysfs.c in linux-4.4. Cc: stable@vger.kernel.org Fixes: 52c198c6 ("ext4: add sysfs entry showing whether the fs contains errors") Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Theodore Ts'o authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 7d95178c upstream. Extended attribute names are defined to be NUL-terminated, so the name must not contain a NUL character. This is important because there are places when remove extended attribute, the code uses strlen to determine the length of the entry. That should probably be fixed at some point, but code is currently really messy, so the simplest fix for now is to simply validate that the extended attributes are sane. https://bugzilla.kernel.org/show_bug.cgi?id=200401Reported-by:
Wen Xu <wen.xu@gatech.edu> Signed-off-by:
-
Claudio Imbrenda authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 306d6c49 upstream. When the oom killer kills a userspace process in the page fault handler while in guest context, the fault handler fails to release the mm_sem if the FAULT_FLAG_RETRY_NOWAIT option is set. This leads to a deadlock when tearing down the mm when the process terminates. This bug can only happen when pfault is enabled, so only KVM clients are affected. The problem arises in the rare cases in which handle_mm_fault does not release the mm_sem. This patch fixes the issue by manually releasing the mm_sem when needed. Fixes: 24eb3a82 ("KVM: s390: Add FAULT_FLAG_RETRY_NOWAIT for guest fault") Cc: <stable@vger.kernel.org> # 3.15+ Signed-off-by:
Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by:
-
Josef Bacik authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 4559b0a7 upstream. If we're trying to make a data reservation and we have to allocate a data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if it allocated a chunk. Since the end of the function is the success path just return 0. CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Steve French authored
BugLink: https://bugs.launchpad.net/bugs/1792392 commit 22783155 upstream. Fixes problem pointed out by Pavel in discussions about commit 729c0c9dSigned-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> CC: Stable <stable@vger.kernel.org> # 3.18.x+ Signed-off-by:
-
