- Aug 11, 2020
-
-
Kees Cook authored
commit e12145cf upstream. Har har, after I moved the slab freelist pointer into the middle of the slab, now it looks like the contents are getting poisoned. Adjust the test to avoid the freelist pointer again. Fixes: 3202fa62 ("slub: relocate freelist pointer to middle of object") Cc: stable@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200625203704.317097-3-keescook@chromium.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthias Maennich authored
commit 55c75498 upstream. When running `make coccicheck` in report mode using the add_namespace.cocci file, it will fail for files that contain MODULE_LICENSE. Those match the replacement precondition, but spatch errors out as virtual.ns is not set. In order to fix that, add the virtual rule nsdeps and only do search and replace if that rule has been explicitly requested. In order to make spatch happy in report mode, we also need a dummy rule, as otherwise it errors out with "No rules apply". Using a script:python rule appears unrelated and odd, but this is the shortest I could come up with. Adjust scripts/nsdeps accordingly to set the nsdeps rule when run trough `make nsdeps`. Suggested-by:
Julia Lawall <julia.lawall@inria.fr> Fixes: c7c4e29f ("scripts: add_namespace: Fix coccicheck failed") Cc: YueHaibing <yuehaibing@huawei.com> Cc: jeyu@kernel.org Cc: cocci@systeme.lip6.fr Cc: stable@vger.kernel.org Signed-off-by:
Matthias Maennich <maennich@google.com> Reported-by:
Shuah Khan <skhan@linuxfoundation.org> Acked-by:
Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/20200604164145.173925-1-maennich@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Biggers authored
commit beb4ee67 upstream. smk_write_relabel_self() frees memory from the task's credentials with no locking, which can easily cause a use-after-free because multiple tasks can share the same credentials structure. Fix this by using prepare_creds() and commit_creds() to correctly modify the task's credentials. Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self": #include <fcntl.h> #include <pthread.h> #include <unistd.h> static void *thrproc(void *arg) { int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY); for (;;) write(fd, "foo", 3); } int main() { pthread_t t; pthread_create(&t, NULL, thrproc, NULL); thrproc(NULL); } Reported-by:
<syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com> Fixes: 38416e53 ("Smack: limited capability for changing process label") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jann Horn authored
commit 4b836a14 upstream. Binder is designed such that a binder_proc never has references to itself. If this rule is violated, memory corruption can occur when a process sends a transaction to itself; see e.g. <https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>. There is a remaining edgecase through which such a transaction-to-self can still occur from the context of a task with BINDER_SET_CONTEXT_MGR access: - task A opens /dev/binder twice, creating binder_proc instances P1 and P2 - P1 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its handle table - P1 dies (by closing the /dev/binder fd and waiting a bit) - P2 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its handle table [this triggers a warning: "binder: 1974:1974 tried to acquire reference to desc 0, got 1 instead"] - task B opens /dev/binder once, creating binder_proc instance P3 - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way transaction) - P2 receives the handle and uses it to call P3 (two-way transaction) - P3 calls P2 (via magic handle 0) (two-way transaction) - P2 calls P2 (via handle 1) (two-way transaction) And then, if P2 does *NOT* accept the incoming transaction work, but instead closes the binder fd, we get a crash. Solve it by preventing the context manager from using ACQUIRE on ref 0. There shouldn't be any legitimate reason for the context manager to do that. Additionally, print a warning if someone manages to find another way to trigger a transaction-to-self bug in the future. Cc: stable@vger.kernel.org Fixes: 457b9a6f ("Staging: android: add binder driver") Acked-by:
Todd Kjos <tkjos@google.com> Signed-off-by:
Jann Horn <jannh@google.com> Reviewed-by:
Martijn Coenen <maco@android.com> Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Adam Ford authored
commit 254503a2 upstream. The drm/omap driver was fixed to correct an issue where using a divider of 32 breaks the DSS despite the TRM stating 32 is a valid number. Through experimentation, it appears that 31 works, and it is consistent with the value used by the drm/omap driver. This patch fixes the divider for fbdev driver instead of the drm. Fixes: f76ee892 ("omapfb: copy omapdss & displays for omapfb") Cc: <stable@vger.kernel.org> #4.5+ Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Rob Clark <robdclark@gmail.com> [b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)] Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peilin Ye authored
commit 629b49c8 upstream. Check `num_rsp` before using it as for-loop counter. Add `unlock` label. Cc: stable@vger.kernel.org Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peilin Ye authored
commit 75bbd2ea upstream. Check `num_rsp` before using it as for-loop counter. Cc: stable@vger.kernel.org Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peilin Ye authored
commit 51c19bf3 upstream. Check upon `num_rsp` is insufficient. A malformed event packet with a large `num_rsp` number makes hci_extended_inquiry_result_evt() go out of bounds. Fix it. This patch fixes the following syzbot bug: https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2 Reported-by:
<syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dinghao Liu authored
commit 11536442 upstream. The variable authmode can be uninitialized. The danger would be if it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid this by setting it to zero instead. This is the approach that was used in the rtl8723bs driver. Fixes: 7b464c9f ("staging: r8188eu: Add files for new driver - part 4") Co-developed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200728072153.9202-1-dinghao.liu@zju.edu.cn Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rustam Kovhaev authored
commit b4383c97 upstream. when firmware fails to load we should not call unregister_netdev() this patch fixes a race condition between rtl871x_load_fw_cb() and r871xu_dev_remove() and fixes the bug reported by syzbot Reported-by:
<syzbot+80899a8a8efe8968cde7@syzkaller.appspotmail.com> Link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7 Signed-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200716151324.1036204-1-rkovhaev@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Suren Baghdasaryan authored
commit 3e338d3c upstream. syzbot report [1] describes a deadlock when write operation against an ashmem fd executed at the time when ashmem is shrinking its cache results in the following lock sequence: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); kswapd takes fs_reclaim and then inode_lock while generic_perform_write takes inode_lock and then fs_reclaim. However ashmem does not support writing into backing shmem with a write syscall. The only way to change its content is to mmap it and operate on mapped memory. Therefore the race that lockdep is warning about is not valid. Resolve this by introducing a separate lockdep class for the backing shmem inodes. [1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/ Reported-by:
<syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com> Signed-off-by:
Suren Baghdasaryan <surenb@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Takashi Iwai authored
commit 80982c7e upstream. Some ioctls via OSS sequencer API may race and lead to UAF when the port create and delete are performed concurrently, as spotted by a couple of syzkaller cases. This patch is an attempt to address it by serializing the ioctls with the existing register_mutex. Basically OSS sequencer API is an obsoleted interface and was designed without much consideration of the concurrency. There are very few applications with it, and the concurrent performance isn't asked, hence this "big hammer" approach should be good enough. Reported-by:
<syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com> Reported-by:
<syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com> Suggested-by:
Hillf Danton <hdanton@sina.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Connor McAdams authored
commit 7fe35304 upstream. The ca0113 command had the wrong group_id, 0x48 when it should've been 0x30. The front microphone selection should now work. Signed-off-by:
Connor McAdams <conmanx360@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200803002928.8638-3-conmanx360@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Connor McAdams authored
commit a00dc409 upstream. When the ZxR headphone gain control was added, the ca0132_switch_get function was not updated, which meant that the changes to the control state were not saved when entering/exiting alsamixer. Signed-off-by:
Connor McAdams <conmanx360@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200803002928.8638-1-conmanx360@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Connor McAdams authored
commit cc5edb1b upstream. Add a new quirk ID for the Recon3D, as tested by me. Signed-off-by:
Connor McAdams <conmanx360@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200803002928.8638-2-conmanx360@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huacai Chen authored
commit f1ec5be1 upstream. There are several Loongson-3 based laptops produced by CZC or Lemote, they use alc269/alc662 codecs and need specific pin-tables, this patch add their pin-tables. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1596360400-32425-1-git-send-email-chenhc@lemote.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hui Wang authored
commit 07c9983b upstream. This reverts commit 9a641848 ("ALSA: hda: call runtime_allow() for all hda controllers"). The reverted patch already introduced some regressions on some machines: - on gemini-lake machines, the error of "azx_get_response timeout" happens in the hda driver. - on the machines with alc662 codec, the audio jack detection doesn't work anymore. Fixes: 9a641848 ("ALSA: hda: call runtime_allow() for all hda controllers") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208511 Cc: <stable@vger.kernel.org> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20200803064638.6139-1-hui.wang@canonical.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Forest Crossman authored
commit ec37198a upstream. I've confirmed that the ASMedia ASM1142 has the same problem as the ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA addresses when in fact it does not. As with the ASM2142/ASM3142, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Forest Crossman authored
commit 1841cb25 upstream. Not all ASMedia host controllers have a device ID that matches its part number. #define some of these IDs to make it clearer at a glance which chips require what quirks. Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Forest Crossman <cyrozap@gmail.com> Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
commit 17a82716 upstream. In previous patches that added support for new iowarrior devices, the handling of the report size was not done correct. Fix that up and update the copyright date for the driver Reworked from an original patch written by Christoph Jung. Fixes: bab5417f ("USB: misc: iowarrior: add support for the 100 device") Fixes: 5f6f8da2 ("USB: misc: iowarrior: add support for the 28 and 28L devices") Fixes: 461d8deb ("USB: misc: iowarrior: add support for 2 OEMed devices") Cc: stable <stable@kernel.org> Reported-by:
Christoph Jung <jung@codemercs.com> Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Erik Ekman authored
commit d2a4309c upstream. When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba laptop, it changed product ID to 0x9062 when entering QDL mode: usb 2-4: new high-speed USB device number 78 using xhci_hcd usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00 usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-4: Product: EM7305 usb 2-4: Manufacturer: Sierra Wireless, Incorporated The upgrade could complete after running # echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id qcserial 2-4:1.0: Qualcomm USB modem converter detected usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0 Signed-off-by:
Erik Ekman <erik@kryo.se> Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stanley Chu authored
commit 6edfdcfe upstream. Add missing setup_xfer_req() call in ufshcd_issue_devman_upiu_cmd() in ufs-bsg path. Relocate existing setup_xfer_req() calls to a common place, i.e., ufshcd_send_command(), to simplify the driver. Link: https://lore.kernel.org/r/20200706060707.32608-3-stanley.chu@mediatek.com Acked-by:
Avri Altman <Avri.Altman@wdc.com> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Aug 07, 2020
-
-
Greg Kroah-Hartman authored
Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit 58552408 upstream. This is hopefully the final piece of the crazy puzzle with random.h dependencies. And by "hopefully" I obviously mean "Linus is a hopeless optimist". Reported-and-tested-by:
Daniel Díaz <daniel.diaz@linaro.org> Acked-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marc Zyngier authored
With the backport of f227e3ec ("random32: update the net random state on interrupt and activity") and its associated fixes, the arm64 build explodes early: In file included from ../include/linux/smp.h:67, from ../include/linux/percpu.h:7, from ../include/linux/prandom.h:12, from ../include/linux/random.h:118, from ../arch/arm64/include/asm/pointer_auth.h:6, from ../arch/arm64/include/asm/processor.h:39, from ../include/linux/mutex.h:19, from ../include/linux/kernfs.h:12, from ../include/linux/sysfs.h:16, from ../include/linux/kobject.h:20, from ../include/linux/of.h:17, from ../include/linux/irqdomain.h:35, from ../include/linux/acpi.h:13, from ../include/acpi/apei.h:9, from ../include/acpi/ghes.h:5, from ../include/linux/arm_sdei.h:8, from ../arch/arm64/kernel/asm-offsets.c:10: ../arch/arm64/include/asm/smp.h:100:29: error: field ‘ptrauth_key’ has incomplete type This is due to struct ptrauth_keys_kernel not being defined before we transitively include asm/smp.h from linux/random.h. Paper over it by moving the inclusion of linux/random.h *after* the type has been defined. Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit c0842fbc upstream. The addition of percpu.h to the list of includes in random.h revealed some circular dependencies on arm64 and possibly other platforms. This include was added solely for the pseudo-random definitions, which have nothing to do with the rest of the definitions in this file but are still there for legacy reasons. This patch moves the pseudo-random parts to linux/prandom.h and the percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and protected against recursive inclusion. A further cleanup step would be to remove this from <linux/random.h> entirely, and make people who use the prandom infrastructure include just the new header file. That's a bit of a churn patch, but grepping for "prandom_" and "next_pseudo_random32" "struct rnd_state" should catch most users. But it turns out that that nice cleanup step is fairly painful, because a _lot_ of code currently seems to depend on the implicit include of <linux/random.h>, which can currently come in a lot of ways, including such fairly core headfers as <linux/net.h>. So the "nice cleanup" part may or may never happen. Fixes: 1c9df907 ("random: fix circular include dependency on arm64 after addition of percpu.h") Tested-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit 83bdc727 upstream. It turns out that the plugin right now ends up being really unhappy about the change from 'static' to 'extern' storage that happened in commit f227e3ec ("random32: update the net random state on interrupt and activity"). This is probably a trivial fix for the latent_entropy plugin, but for now, just remove net_rand_state from the list of things the plugin worries about. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Emese Revfy <re.emese@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Willy Tarreau authored
commit 1c9df907 upstream. Daniel Díaz and Kees Cook independently reported that commit f227e3ec ("random32: update the net random state on interrupt and activity") broke arm64 due to a circular dependency on include files since the addition of percpu.h in random.h. The correct fix would definitely be to move all the prandom32 stuff out of random.h but for backporting, a smaller solution is preferred. This one replaces linux/percpu.h with asm/percpu.h, and this fixes the problem on x86_64, arm64, arm, and mips. Note that moving percpu.h around didn't change anything and that removing it entirely broke differently. When backporting, such options might still be considered if this patch fails to help. [ It turns out that an alternate fix seems to be to just remove the troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h> that causes the circular dependency. But we might as well do the whole belt-and-suspenders thing, and minimize inclusion in <linux/random.h> too. Either will fix the problem, and both are good changes. - Linus ] Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Reported-by:
Kees Cook <keescook@chromium.org> Tested-by:
Marc Zyngier <maz@kernel.org> Fixes: f227e3ec Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Grygorii Strashko authored
commit aa54ea90 upstream. Fix build error for the case: defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6) config: keystone_defconfig CC arch/arm/kernel/signal.o In file included from ../include/linux/random.h:14, from ../arch/arm/kernel/signal.c:8: ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’: ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’? : "Q" (*(const unsigned long *)current_stack_pointer)); ^~~~~~~~~~~~~~~~~~~~~ user_stack_pointer Fixes: f227e3ec ("random32: update the net random state on interrupt and activity") Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Willy Tarreau authored
commit f227e3ec upstream. This modifies the first 32 bits out of the 128 bits of a random CPU's net_rand_state on interrupt or CPU activity to complicate remote observations that could lead to guessing the network RNG's internal state. Note that depending on some network devices' interrupt rate moderation or binding, this re-seeding might happen on every packet or even almost never. In addition, with NOHZ some CPUs might not even get timer interrupts, leaving their local state rarely updated, while they are running networked processes making use of the random state. For this reason, we also perform this update in update_process_times() in order to at least update the state when there is user or system activity, since it's the only case we care about. Reported-by:
Amit Klein <aksecurity@gmail.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Eric Dumazet <edumazet@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Aug 05, 2020
-
-
Greg Kroah-Hartman authored
Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Gleixner authored
commit bdd65589 upstream. 0day reported a possible circular locking dependency: Chain exists of: &irq_desc_lock_class --> console_owner --> &port_lock_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&port_lock_key); lock(console_owner); lock(&port_lock_key); lock(&irq_desc_lock_class); The reason for this is a printk() in the i8259 interrupt chip driver which is invoked with the irq descriptor lock held, which reverses the lock operations vs. printk() from arbitrary contexts. Switch the printk() to printk_deferred() to avoid that. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wanpeng Li authored
commit 830f01b0 upstream. 'Commit 8566ac8b ("KVM: SVM: Implement pause loop exit logic in SVM")' drops disable pause loop exit/pause filtering capability completely, I guess it is a merge fault by Radim since disable vmexits capabilities and pause loop exit for SVM patchsets are merged at the same time. This patch reintroduces the disable pause loop exit/pause filtering capability support. Reported-by:
Haiwei Li <lihaiwei@tencent.com> Tested-by:
Haiwei Li <lihaiwei@tencent.com> Fixes: 8566ac8b ("KVM: SVM: Implement pause loop exit logic in SVM") Signed-off-by:
Wanpeng Li <wanpengli@tencent.com> Message-Id: <1596165141-28874-3-git-send-email-wanpengli@tencent.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wanpeng Li authored
commit d2286ba7 upstream. Prevent setting the tscdeadline timer if the lapic is hw disabled. Fixes: bce87cce (KVM: x86: consolidate different ways to test for in-kernel LAPIC) Cc: <stable@vger.kernel.org> Signed-off-by:
Wanpeng Li <wanpengli@tencent.com> Message-Id: <1596165141-28874-1-git-send-email-wanpengli@tencent.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit b757b47a upstream. If a stage-2 page-table contains an executable, read-only mapping at the pte level (e.g. due to dirty logging being enabled), a subsequent write fault to the same page which tries to install a larger block mapping (e.g. due to dirty logging having been disabled) will erroneously inherit the exec permission and consequently skip I-cache invalidation for the rest of the block. Ensure that exec permission is only inherited by write faults when the new mapping is of the same size as the existing one. A subsequent instruction abort will result in I-cache invalidation for the entire block mapping. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Marc Zyngier <maz@kernel.org> Tested-by:
Quentin Perret <qperret@google.com> Reviewed-by:
Quentin Perret <qperret@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200723101714.15873-1-will@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Atish Patra authored
[ Upstream commit fa5a1983 ] Currently, maximum physical memory allowed is equal to -PAGE_OFFSET. That's why we remove any memory blocks spanning beyond that size. However, it is done only for memblock containing linux kernel which will not work if there are multiple memblocks. Process all memory blocks to figure out how much memory needs to be removed and remove at the end instead of updating the memblock list in place. Signed-off-by:
Atish Patra <atish.patra@wdc.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Xie He authored
[ Upstream commit 8754e137 ] This patch fixed 2 issues with the usage of skb_cow in LAPB drivers "lapbether" and "hdlc_x25": 1) After skb_cow fails, kfree_skb should be called to drop a reference to the skb. But in both drivers, kfree_skb is not called. 2) skb_cow should be called before skb_push so that is can ensure the safety of skb_push. But in "lapbether", it is incorrectly called after skb_push. More details about these 2 issues: 1) The behavior of calling kfree_skb on failure is also the behavior of netif_rx, which is called by this function with "return netif_rx(skb);". So this function should follow this behavior, too. 2) In "lapbether", skb_cow is called after skb_push. This results in 2 logical issues: a) skb_push is not protected by skb_cow; b) An extra headroom of 1 byte is ensured after skb_push. This extra headroom has no use in this function. It also has no use in the upper-layer function that this function passes the skb to (x25_lapb_receive_frame in net/x25/x25_dev.c). So logically skb_cow should instead be called before skb_push. Cc: Eric Dumazet <edumazet@google.com> Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Atish Patra authored
[ Upstream commit d0d8aae6 ] Currently, maximum number of mapper pages are set to the pfn calculated from the memblock size of the memblock containing kernel. This will work until that memblock spans the entire memory. However, it will be set to a wrong value if there are multiple memblocks defined in kernel (e.g. with efi runtime services). Set the the maximum value to the pfn calculated from dram size. Signed-off-by:
Atish Patra <atish.patra@wdc.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrea Righi authored
[ Upstream commit c2c63310 ] There's a potential race in xennet_remove(); this is what the driver is doing upon unregistering a network device: 1. state = read bus state 2. if state is not "Closed": 3. request to set state to "Closing" 4. wait for state to be set to "Closing" 5. request to set state to "Closed" 6. wait for state to be set to "Closed" If the state changes to "Closed" immediately after step 1 we are stuck forever in step 4, because the state will never go back from "Closed" to "Closing". Make sure to check also for state == "Closed" in step 4 to prevent the deadlock. Also add a 5 sec timeout any time we wait for the bus state to change, to avoid getting stuck forever in wait_event(). Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Navid Emamdoost authored
[ Upstream commit e6827d1a ] In the implementation of uld_send(), the skb is consumed on all execution paths except one. Release skb when returning NET_XMIT_DROP. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-