- 06 Feb, 2019 40 commits
-
-
Fred Herard authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 5db6dd14 ] This commit addresses NULL pointer dereference in iscsi_eh_session_reset. Reference should not be made to session->leadconn when session->state is set to ISCSI_STATE_TERMINATE. Signed-off-by:
Fred Herard <fred.herard@oracle.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Alexey Khoroshilov authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 05cc09de ] There is no unregister netlink notifier and family on error paths in init_mac80211_hwsim(). Also there is an error path where hwsim_class is not destroyed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Fixes: 62759361 ("mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Ilan Peer authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 911a2648 ] Commit c470bdc1 ("mac80211: don't WARN on bad WMM parameters from buggy APs") handled cases where an AP reports a zeroed WMM IE. However, the condition that checks the validity accessed the wrong index in the ieee80211_tx_queue_params array, thus wrongly deducing that the parameters are invalid. Fix it. Fixes: c470bdc1 ("mac80211: don't WARN on bad WMM parameters from buggy APs") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit c470bdc1 ] Apparently, some APs are buggy enough to send a zeroed WMM IE. Don't WARN on this since this is not caused by a bug on the client's system. This aligns the condition of the WARNING in drv_conf_tx with the validity check in ieee80211_sta_wmm_params. We will now pick the default values whenever we get a zeroed WMM IE. This has been reported here: https://bugzilla.kernel.org/show_bug.cgi?id=199161 Fixes: f409079b ("mac80211: sanity check CW_min/CW_max towards driver") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Yunlei He authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit d4fdf8ba upstream. Mount fs with option noflush_merge, boot failed for illegal address fcc in function f2fs_issue_flush: if (!test_opt(sbi, FLUSH_MERGE)) { ret = submit_flush_wait(sbi); atomic_inc(&fcc->issued_flush); -> Here, fcc illegal return ret; } Signed-off-by:
Yunlei He <heyunlei@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> [bwh: Backported to 4.9: adjust context] Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Brian Norris authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit 63238173 upstream. This reverts commit 7f3ef5de. It causes new warnings [1] on shutdown when running the Google Kevin or Scarlet (RK3399) boards under Chrome OS. Presumably our usage of DRM is different than what Marc and Heiko test. We're looking at a different approach (e.g., [2]) to replace this, but IMO the revert should be taken first, as it already propagated to -stable. [1] Report here: http://lkml.kernel.org/lkml/20181205030127.GA200921@google.com WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x294 ... Call trace: drm_mode_config_cleanup+0x1c4/0x294 rockchip_drm_unbind+0x4c/0x8c component_master_del+0x88/0xb8 rockchip_drm_platform_remove+0x2c/0x44 rockchip_drm_platform_shutdown+0x20/0x2c platform_drv_shutdown+0x2c/0x38 device_shutdown+0x164/0x1b8 kernel_restart_prepare+0x40/0x48 kernel_restart+0x20/0x68 ... Memory manager not clean during takedown. WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x34/0x44 ... drm_mm_takedown+0x34/0x44 rockchip_drm_unbind+0x64/0x8c component_master_del+0x88/0xb8 rockchip_drm_platform_remove+0x2c/0x44 rockchip_drm_platform_shutdown+0x20/0x2c platform_drv_shutdown+0x2c/0x38 device_shutdown+0x164/0x1b8 kernel_restart_prepare+0x40/0x48 kernel_restart+0x20/0x68 ... [2] https://patchwork.kernel.org/patch/10556151/ https://www.spinics.net/lists/linux-rockchip/msg21342.html [PATCH] drm/rockchip: shutdown drm subsystem on shutdown Fixes: 7f3ef5de ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Vicente Bergas <vicencb@gmail.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: stable@vger.kernel.org Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181205181657.177703-1-briannorris@chromium.orgSigned-off-by:
-
Radu Rendec authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit 78e7b15e upstream. The arch_teardown_msi_irqs() function assumes that controller ops pointers were already checked in arch_setup_msi_irqs(), but this assumption is wrong: arch_teardown_msi_irqs() can be called even when arch_setup_msi_irqs() returns an error (-ENOSYS). This can happen in the following scenario: - msi_capability_init() calls pci_msi_setup_msi_irqs() - pci_msi_setup_msi_irqs() returns -ENOSYS - msi_capability_init() notices the error and calls free_msi_irqs() - free_msi_irqs() calls pci_msi_teardown_msi_irqs() This is easier to see when CONFIG_PCI_MSI_IRQ_DOMAIN is not set and pci_msi_setup_msi_irqs() and pci_msi_teardown_msi_irqs() are just aliases to arch_setup_msi_irqs() and arch_teardown_msi_irqs(). The call to free_msi_irqs() upon pci_msi_setup_msi_irqs() failure seems legit, as it does additional cleanup; e.g. list_del(&entry->list) and kfree(entry) inside free_msi_irqs() do happen (MSI descriptors are allocated before pci_msi_setup_msi_irqs() is called and need to be cleaned up if that fails). Fixes: 6b2fd7ef ("PCI/MSI/PPC: Remove arch_msi_check_device()") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by:
Radu Rendec <radu.rendec@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit 2840f84f upstream. The following commands will cause a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo schedule > instance/foo/set_ftrace_filter # rmdir instances/foo The reason is that the hashes that hold the filters to set_ftrace_filter and set_ftrace_notrace are not freed if they contain any data on the instance and the instance is removed. Found by kmemleak detector. Cc: stable@vger.kernel.org Fixes: 591dffda ("ftrace: Allow for function tracing instance to filter functions") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit 3cec638b upstream. When create_event_filter() fails in set_trigger_filter(), the filter may still be allocated and needs to be freed. The caller expects the data->filter to be updated with the new filter, even if the new filter failed (we could add an error message by setting set_str parameter of create_event_filter(), but that's another update). But because the error would just exit, filter was left hanging and nothing could free it. Found by kmemleak detector. Cc: stable@vger.kernel.org Fixes: bac5fb97 ("tracing: Add and use generic set_trigger_filter() implementation") Reviewed-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by:
-
Aaro Koskinen authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit e8cde625 upstream. Since v2.6.22 or so there has been reports [1] about OMAP MMC being broken on OMAP15XX based hardware (OMAP5910 and OMAP310). The breakage seems to have been caused by commit 46a6730e ("mmc-omap: Fix omap to use MMC_POWER_ON") that changed clock enabling to be done on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX the hardware doesn't seem to like it and the MMC just stops responding. Fix by memorizing the power mode and do the init only when necessary. Before the patch (on Palm TE): mmc0: new SD card at address b368 mmcblk0: mmc0:b368 SDC 977 MiB mmci-omap mmci-omap.0: command timeout (CMD18) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD12) [x 6] mmci-omap mmci-omap.0: command timeout (CMD13) [x 6] mmcblk0: error -110 requesting status mmci-omap mmci-omap.0: command timeout (CMD8) mmci-omap mmci-omap.0: command timeout (CMD18) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD12) [x 6] mmci-omap mmci-omap.0: command timeout (CMD13) [x 6] mmcblk0: error -110 requesting status mmcblk0: recovery failed! print_req_error: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table After the patch: mmc0: new SD card at address b368 mmcblk0: mmc0:b368 SDC 977 MiB mmcblk0: p1 The patch is based on a fix and analysis done by Ladislav Michl. Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770) and OMAP2420 (Nokia N810). [1] https://marc.info/?t=123175197000003&r=1&w=2 Fixes: 46a6730e ("mmc-omap: Fix omap to use MMC_POWER_ON") Reported-by:
Ladislav Michl <ladis@linux-mips.org> Reported-by:
Andrzej Zaborowski <balrogg@gmail.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Jeff Moyer authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit a538e3ff upstream. Matthew pointed out that the ioctx_table is susceptible to spectre v1, because the index can be controlled by an attacker. The below patch should mitigate the attack for all of the aio system calls. Cc: stable@vger.kernel.org Reported-by:
Matthew Wilcox <willy@infradead.org> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: https://bugs.launchpad.net/bugs/1811252 commit 478b6767 upstream. Pin PH11 is used on various A83T board to detect a change in the OTG port's ID pin, as in when an OTG host cable is plugged in. The incorrect offset meant the gpiochip/irqchip was activating the wrong pin for interrupts. Fixes: 4730f33f ("pinctrl: sunxi: add allwinner A83T PIO controller support") Cc: <stable@vger.kernel.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Guenter Roeck authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 64c3f648 ] Once in a while I see build errors similar to the following when building images from a clean tree. Building powerpc:virtex-ml507:44x/virtex5_defconfig ... failed ------------ Error log: arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error: libfdt.h: No such file or directory Building powerpc:bamboo:smpdev:44x/bamboo_defconfig ... failed ------------ Error log: arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error: libfdt.h: No such file or directory arch/powerpc/boot/treeboot-currituck.c:35:20: fatal error: libfdt.h: No such file or directory Rebuilds will succeed. Turns out that several source files in arch/powerpc/boot/ include libfdt.h, but Makefile dependencies are incomplete. Let's fix that. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Ingo Molnar authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 8e7df2b5 ] While it uses %pK, there's still few reasons to read this file as non-root. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Davidlohr Bueso authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit a8ec14d4 ] Add a 'max_endpoint' parameter such that users may easily limit the size of the intervals that are randomly generated. Link: http://lkml.kernel.org/r/20170518174936.20265-4-dave@stgolabs.netSigned-off-by:
Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Davidlohr Bueso authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 0b548e33 ] Fengguang reported soft lockups while running the rbtree and interval tree test modules. The logic for these tests all occur in init phase, and we currently are pounding with the default values for number of nodes and number of iterations of each test. Reduce the latter by two orders of magnitude. This does not influence the value of the tests in that one thousand times by default is enough to get the picture. Link: http://lkml.kernel.org/r/20171109161715.xai2dtwqw2frhkcm@linux-n805Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Davidlohr Bueso authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit 223f8911 ] Allows for more flexible debugging. Link: http://lkml.kernel.org/r/20170719014603.19029-5-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit c46ecce4 ] ... such that a user can specify visiting all the nodes in the tree (intersects with the world). This is a nice opposite from the very basic default query which is a single point. Link: http://lkml.kernel.org/r/20170518174936.20265-5-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
BugLink: https://bugs.launchpad.net/bugs/1811252 [ Upstream commit a54dae03 ] Allows for more flexible debugging. Link: http://lkml.kernel.org/r/20170518174936.20265-3-dave@stgolabs.netSigned-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811080Signed-off-by:
-
Shuah Khan authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 3d2c86e3 upstream. Remove networking from Documentation Makefile to move the test to selftests. Update networking/timestamping Makefile to work under selftests. These tests will not be run as part of selftests suite and will not be included in install targets. They can be built and run separately for now. This is part of the effort to move runnable code from Documentation. Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> [ added to 4.4.y stable to remove a build warning - gregkh] Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 6098d7dd upstream. Inlining these functions creates lots of stack variables that each take 64 bytes when KASAN is enabled, leading to this warning about potential stack overflow: drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add': drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] gcc-8 can now consolidate the stack slots itself, but on older versions we get the same behavior by using a temporary variable that holds a copy of the inline function argument. Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Guenter Roeck authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit fd29edc7 upstream. gcc 8.1.0 generates the following warnings. drivers/staging/speakup/kobjects.c: In function 'punc_store': drivers/staging/speakup/kobjects.c:522:2: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length drivers/staging/speakup/kobjects.c:504:6: note: length computed here drivers/staging/speakup/kobjects.c: In function 'synth_store': drivers/staging/speakup/kobjects.c:391:2: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length drivers/staging/speakup/kobjects.c:388:8: note: length computed here Using strncpy() is indeed less than perfect since the length of data to be copied has already been determined with strlen(). Replace strncpy() with memcpy() to address the warning and optimize the code a little. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by:
-
Sudip Mukherjee authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 59921b23 upstream. hw->DACreg has a size of 80 bytes and MGADACbpp32 has 21. So when memcpy copies MGADACbpp32 to hw->DACreg it copies 80 bytes but only 21 bytes are valid. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 3cd890db upstream. A typical code fragment was copied across many dvb-frontend drivers and causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7: drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] gcc-8 now solves this by consolidating the stack slots for the argument variables, but on older compilers we can get the same behavior by taking the pointer of a local variable rather than the inline function argument. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Cc: stable@vger.kernel.org Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Willy Tarreau authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 7f7ccc2c upstream. proc_pid_cmdline_read() and environ_read() directly access the target process' VM to retrieve the command line and environment. If this process remaps these areas onto a file via mmap(), the requesting process may experience various issues such as extra delays if the underlying device is slow to respond. Let's simply refuse to access file-backed areas in these functions. For this we add a new FOLL_ANON gup flag that is passed to all calls to access_remote_vm(). The code already takes care of such failures (including unmapped areas). Accesses via /proc/pid/mem were not changed though. This was assigned CVE-2018-1120. Note for stable backports: the patch may apply to kernels prior to 4.11 but silently miss one location; it must be checked that no call to access_remote_vm() keeps zero as the last argument. Reported-by:
Qualys Security Advisory <qsa@qualys.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 272ddc8b upstream. Now that Lorenzo cleaned things up and made the FOLL_FORCE users explicit, it becomes obvious how some of them don't really need FOLL_FORCE at all. So remove FOLL_FORCE from the proc code that reads the command line and arguments from user space. The mem_rw() function actually does want FOLL_FORCE, because gdd (and possibly many other debuggers) use it as a much more convenient version of PTRACE_PEEKDATA, but we should consider making the FOLL_FORCE part conditional on actually being a ptracer. This does not actually do that, just moves adds a comment to that effect and moves the gup_flags settings next to each other. Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 6347e8d5 upstream. This removes the 'write' argument from access_remote_vm() and replaces it with 'gup_flags' as use of this function previously silently implied FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
Lorenzo Stoakes <lstoakes@gmail.com> Acked-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 442486ec upstream. This removes the 'write' argument from __access_remote_vm() and replaces it with 'gup_flags' as use of this function previously silently implied FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 768ae309 upstream. This removes the 'write' and 'force' from get_user_pages() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 7f23b350 upstream. This removes the 'write' and 'force' from get_vaddr_frames() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 3b913179 upstream. This removes the 'write' and 'force' use from get_user_pages_locked() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit c164154f upstream. This removes the 'write' and 'force' use from get_user_pages_unlocked() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1811080 Extracted from commit cde70140 "mm/gup: Overload get_user_pages() functions". This is needed before picking commit 768ae309 "mm: replace get_user_pages() write/force parameters with gup_flags". Signed-off-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit d4944b0e upstream. This removes the redundant 'write' and 'force' parameters from __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
-
Lorenzo Stoakes authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 859110d7 upstream. This removes the redundant 'write' and 'force' parameters from __get_user_pages_locked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by:
-
Jens Axboe authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit f7068114 upstream. We're casting the CDROM layer request_sense to the SCSI sense buffer, but the former is 64 bytes and the latter is 96 bytes. As we generally allocate these on the stack, we end up blowing up the stack. Fix this by wrapping the scsi_execute() call with a properly sized sense buffer, and copying back the bits for the CDROM layer. Reported-by:
Piotr Gabriel Kosinski <pg.kosinski@gmail.com> Reported-by:
Daniel Shapira <daniel@twistlock.com> Tested-by:
Kees Cook <keescook@chromium.org> Fixes: 82ed4db4 ("block: split scsi_request out of struct request") Signed-off-by:
-
Kees Cook authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 7d63fb3a upstream. This removes needless use of '%p', and refactors the printk calls to use pr_*() helpers instead. Signed-off-by:
Christoph Hellwig <hch@lst.de> [bwh: Backported to 4.4: - Adjust filename - Remove "swiotlb: " prefix from an additional log message] Signed-off-by:
-
Mike Kravetz authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 5df63c2a upstream. This is a fix for a regression in 32 bit kernels caused by an invalid check for pgoff overflow in hugetlbfs mmap setup. The check incorrectly specified that the size of a loff_t was the same as the size of a long. The regression prevents mapping hugetlbfs files at offsets greater than 4GB on 32 bit kernels. On 32 bit kernels conversion from a page based unsigned long can not overflow a loff_t byte offset. Therefore, skip this check if sizeof(unsigned long) != sizeof(loff_t). Link: http://lkml.kernel.org/r/20180330145402.5053-1-mike.kravetz@oracle.com Fixes: 63489f8e ("hugetlbfs: check for pgoff value overflow") Reported-by:
Dan Rue <dan.rue@linaro.org> Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Tested-by:
Anders Roxell <anders.roxell@linaro.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Yisheng Xie <xieyisheng1@huawei.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Nic Losby <blurbdust@gmail.com> Signed-off-by:
-
Mike Kravetz authored
BugLink: https://bugs.launchpad.net/bugs/1811080 commit 63489f8e upstream. A vma with vm_pgoff large enough to overflow a loff_t type when converted to a byte offset can be passed via the remap_file_pages system call. The hugetlbfs mmap routine uses the byte offset to calculate reservations and file size. A sequence such as: mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0); remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0); will result in the following when task exits/file closed, kernel BUG at mm/hugetlb.c:749! Call Trace: hugetlbfs_evict_inode+0x2f/0x40 evict+0xcb/0x190 __dentry_kill+0xcb/0x150 __fput+0x164/0x1e0 task_work_run+0x84/0xa0 exit_to_usermode_loop+0x7d/0x80 do_syscall_64+0x18b/0x190 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 The overflowed pgoff value causes hugetlbfs to try to set up a mapping with a negative range (end < start) that leaves invalid state which causes the BUG. The previous overflow fix to this code was incomplete and did not take the remap_file_pages system call into account. [mike.kravetz@oracle.com: v3] Link: http://lkml.kernel.org/r/20180309002726.7248-1-mike.kravetz@oracle.com [akpm@linux-foundation.org: include mmdebug.h] [akpm@linux-foundation.org: fix -ve left shift count on sh] Link: http://lkml.kernel.org/r/20180308210502.15952-1-mike.kravetz@oracle.com Fixes: 045c7a3f ("hugetlbfs: fix offset overflow in hugetlbfs mmap") Signed-off-by:
Nic Losby <blurbdust@gmail.com> Acked-by:
-
