- 07 May, 2019 6 commits
-
-
Dave Hansen authored
Use the new model number macros instead of spelling things out in the comments. Note that this is missing a Nehalem model that is mentioned in intel_idle which is fixed up in a later patch. The resulting binary (arch/x86/events/intel/core.o) is exactly the same with and without this patch modulo some harmless changes to restoring %esi in the return path of functions, even those untouched by this patch. Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: jacob.jun.pan@intel.com Link: http://lkml.kernel.org/r/20160603001929.C5F1C079@viggo.jf.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 (backported from commit ef5f9f47) [juergh: Adjusted context.] Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Andi Kleen authored
Everything the same as Skylake, just new model numbers. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1461977748-17616-1-git-send-email-andi@firstfloor.orgSigned-off-by:
-
Andi Kleen authored
Everything the same as base Skylake, just a new model number. Signed-off-by:
-
Salvatore Bonaccorso authored
Fix small typo (wiil -> will) in the "3.4. Nested virtual machines" section. Fixes: 5b76a3cf ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry") Cc: linux-kernel@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-doc@vger.kernel.org Cc: trivial@kernel.org Signed-off-by:
Salvatore Bonaccorso <carnil@debian.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 (cherry picked from commit 60ca05c3) Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by: -
Stefan Bader authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
- 23 Apr, 2019 32 commits
-
-
Connor Kuehl authored
Signed-off-by:Connor Kuehl <connor.kuehl@canonical.com>
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1826036Signed-off-by:
-
Connor Kuehl authored
Ignore: yes Signed-off-by: -
Connor Kuehl authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1820872 This reverts commit 6cfb521a. Turns out distros do not want to make retpoline as part of their "ABI", so this patch should not have been merged. Sorry Andi, this was my fault, I suggested it when your original patch was the "correct" way of doing this instead. Reported-by:
Jiri Kosina <jikos@kernel.org> Fixes: 6cfb521a ("module: Add retpoline tag to VERMAGIC") Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (backported from commit 5132ede0) [juergh: Adjusted context.] Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1820872 Trivial changes to reduce the delta between Xenial 4.4 and upstream stable 4.9 so that future cherry-picking results in fewer conflicts. Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1820872 Fixes: bb807b84 ("UBUNTU: SAUCE: x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation") Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1820872 Add 'nosmt' which was omitted in the original backport. Fixes: df8ddbcb ("cpu/hotplug: Provide knobs to control SMT") Signed-off-by:
-
Gustavo A. R. Silva authored
dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> CVE-2017-5753 (cherry picked from commit c709f14f) Signed-off-by:
-
Gustavo A. R. Silva authored
info->stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap) Fix this by sanitizing info->stream before using it to index rmidi->streams. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by:
-
Johannes Berg authored
It's possible that the caller of cfg80211_classify8021d() uses the value to index an array, like mac80211 in ieee80211_downgrade_queue(). Prevent speculation on the return value. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Breno Leitao authored
'regno' is directly controlled by user space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the register number that would be read or written. This register number is called 'regno' which is part of the 'addr' syscall parameter. This 'regno' value is checked against the maximum pt_regs structure size, and then used to dereference it, which matches the initial part of a Spectre v1 (and Spectre v1.1) attack. The dereferenced value, then, is returned to userspace in the GETREGS case. This patch sanitizes 'regno' before using it to dereference pt_reg. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by:
Breno Leitao <leitao@debian.org> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> CVE-2017-5753 (backported from commit ebb0e13e) [juergh: Adjusted context.] Signed-off-by:
-
Gustavo A. R. Silva authored
channel and addr->channel are indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. These issues were detected with the help of Smatch: drivers/char/ipmi/ipmi_msghandler.c:1381 ipmi_set_my_address() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap) drivers/char/ipmi/ipmi_msghandler.c:1401 ipmi_get_my_address() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap) drivers/char/ipmi/ipmi_msghandler.c:1421 ipmi_set_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap) drivers/char/ipmi/ipmi_msghandler.c:1441 ipmi_get_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap) drivers/char/ipmi/ipmi_msghandler.c:2260 check_addr() warn: potential spectre issue 'intf->addrinfo' [r] (local cap) Fix this by sanitizing channel and addr->channel before using them to index user->intf->addrinfo and intf->addrinfo, correspondingly. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by:
Corey Minyard <cminyard@mvista.com> CVE-2017-5753 (backported from commit a7102c74) [juergh: Adjused context.] Signed-off-by:
-
Masashi Honma authored
Use array_index_nospec() to sanitize ridx with respect to speculation. Signed-off-by:
Masashi Honma <masashi.honma@gmail.com> Signed-off-by:
-
Jinbum Park authored
User controls @idx which to be used as index of hwsim_world_regdom_custom. So, It can be exploited via Spectre-like attack. (speculative execution) This kind of attack leaks address of hwsim_world_regdom_custom, It leads an attacker to bypass security mechanism such as KASLR. So sanitize @idx before using it to prevent attack. I leveraged strategy [1] to find and exploit this gadget. [1] https://github.com/jinb-park/linux-exploit/tree/master/exploit-remaining-spectre-gadget/Signed-off-by:
Jinbum Park <jinb.park7@gmail.com> [johannes: unwrap URL] Signed-off-by:
-
Gustavo A. R. Silva authored
val can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: vers/hwmon/nct6775.c:2698 store_pwm_weight_temp_sel() warn: potential spectre issue 'data->temp_src' [r] Fix this by sanitizing val before using it to index data->temp_src Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by:
Guenter Roeck <linux@roeck-us.net> CVE-2017-5753 (backported from commit d49dbfad) [juergh: Adjusted context.] Signed-off-by:
-
Jeremy Cline authored
req->sdiag_family is a user-controlled value that's used as an array index. Sanitize it after the bounds check to avoid speculative out-of-bounds array access. This also protects the sock_is_registered() call, so this removes the sanitize call there. Fixes: e978de7a ("net: socket: Fix potential spectre v1 gadget in sock_is_registered") Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: konrad.wilk@oracle.com Cc: jamie.iles@oracle.com Cc: liran.alon@oracle.com Cc: stable@vger.kernel.org Signed-off-by:
Jeremy Cline <jcline@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> CVE-2017-5753 (backported from commit 66b51b0a) [juergh: Adjusted for missing sock_is_registered().] Signed-off-by:
-
Jeremy Cline authored
'family' can be a user-controlled value, so sanitize it after the bounds check to avoid speculative out-of-bounds access. Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jinbum Park authored
User controls @dev_minor which to be used as index of pkt_devs. So, It can be exploited via Spectre-like attack. (speculative execution) This kind of attack leaks address of pkt_devs, [1] It leads an attacker to bypass security mechanism such as KASLR. So sanitize @dev_minor before using it to prevent attack. [1] https://github.com/jinb-park/linux-exploit/ tree/master/exploit-remaining-spectre-gadget/leak_pkt_devs.c Signed-off-by:
Jens Axboe <axboe@kernel.dk> CVE-2017-5753 (backported from commit 55690c07) [juergh: Adjusted context.] Signed-off-by:
-
Mark Rutland authored
It's possible for userspace to control idx. Sanitize idx when using it as an array index, to inhibit the potential spectre-v1 write gadget. Found by smatch. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> CVE-2017-5753 (cherry picked from commit 14d6e289) Signed-off-by:
-
Martin Schwidefsky authored
The kbd_ioctl uses two user controlled indexes for KDGKBENT/KDSKBENT. Use array_index_nospec to prevent any out of bounds speculation. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> CVE-2017-5753 (cherry picked from commit 05473283) Signed-off-by:
-
Mauro Carvalho Chehab authored
slot can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability, as warned by smatch: drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap) Acked-by:
"Jasmin J." <jasmin@anw.at> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> CVE-2017-5753 (backported from commit 4f5ab5d7) [juergh: - Adjusted context. - Folded in a24e6348 ("media: dvb_ca_en50221: sanity check slot number from userspace").] Signed-off-by:
-
Peter Zijlstra authored
> kernel/sched/autogroup.c:230 proc_sched_autogroup_set_nice() warn: potential spectre issue 'sched_prio_to_weight' Userspace controls @nice, sanitize the array index. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mark Rutland authored
It's possible for userspace to control idx. Sanitize idx when using it as an array index. Found by smatch. Signed-off-by:
-
Thomas Gleixner authored
The clockid argument of clockid_to_kclock() comes straight from user space via various syscalls and is used as index into the posix_clocks array. Protect it against spectre v1 array out of bounds speculation. Remove the redundant check for !posix_clock[id] as this is another source for speculation and does not provide any advantage over the return posix_clock[id] path which returns NULL in that case anyway. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Dan Williams <dan.j.williams@intel.com> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1802151718320.1296@nanos.tec.linutronix.de CVE-2017-5753 (backported from commit 19b558db) [juergh: Context adjustments.] Signed-off-by:
-
Xin Long authored
sk_forward_alloc's updating is also done on rx path, but to be consistent we change to use sk_mem_charge() in sctp_skb_set_owner_r(). In sctp_eat_data(), it's not enough to check sctp_memory_pressure only, which doesn't work for mem_cgroup_sockets_enabled, so we change to use sk_under_memory_pressure(). When it's under memory pressure, sk_mem_reclaim() and sk_rmem_schedule() should be called on both RENEGE or CHUNK DELIVERY path exit the memory pressure status as soon as possible. Note that sk_rmem_schedule() is using datalen to make things easy there. Reported-by:
Matteo Croce <mcroce@redhat.com> Tested-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to check if the allocated should be raised, and call sk_mem_reclaim() to check if the allocated should be reduced when it's under memory pressure. If sk_wmem_schedule() returns false, which means no memory is allowed to allocate, it will block and wait for memory to become available. Note different from tcp, sctp wait_for_buf happens before allocating any skb, so memory accounting check is done with the whole msg_len before it too. Reported-by:
-
Xin Long authored
sk->sk_wmem_queued is used to count the size of chunks in out queue while sk->sk_wmem_alloc is for counting the size of chunks has been sent. sctp is increasing both of them before enqueuing the chunks, and using sk->sk_wmem_alloc to check for writable space. However, sk_wmem_alloc is also increased by 1 for the skb allocked for sending in sctp_packet_transmit() but it will not wake up the waiters when sk_wmem_alloc is decreased in this skb's destructor. If msg size is equal to sk_sndbuf and sendmsg is waiting for sndbuf, the check 'msg_len <= sctp_wspace(asoc)' in sctp_wait_for_sndbuf() will keep waiting if there's a skb allocked in sctp_packet_transmit, and later even if this skb got freed, the waiting thread will never get waked up. This issue has been there since very beginning, so we change to use sk->sk_wmem_queued to check for writable space as sk_wmem_queued is not increased for the skb allocked for sending, also as TCP does. SOCK_SNDBUF_LOCK check is also removed here as it's for tx buf auto tuning which I will add in another patch. Signed-off-by:
-
Xin Long authored
Now when reneging events in sctp_ulpq_renege(), the variable freed could be increased by a __u16 value twice while freed is of __u16 type. It means freed may overflow at the second addition. This patch is to fix it by using __u32 type for 'freed', while at it, also to remove 'if (chunk)' check, as all renege commands are generated in sctp_eat_data and it can't be NULL. Reported-by:
-
Naveen N. Rao authored
BugLink: https://bugs.launchpad.net/bugs/1812809 Add powerpc support for the recently added kprobe args tests. Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> (cherry picked from commit 9855c462) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
-
Alex Williamson authored
Memory backed DMA mappings are accounted against a user's locked memory limit, including multiple mappings of the same memory. This accounting bounds the number of such mappings that a user can create. However, DMA mappings that are not backed by memory, such as DMA mappings of device MMIO via mmaps, do not make use of page pinning and therefore do not count against the user's locked memory limit. These mappings still consume memory, but the memory is not well associated to the process for the purpose of oom killing a task. To add bounding on this use case, we introduce a limit to the total number of concurrent DMA mappings that a user is allowed to create. This limit is exposed as a tunable module option where the default value of 64K is expected to be well in excess of any reasonable use case (a large virtual machine configuration would typically only make use of tens of concurrent mappings). This fixes CVE-2019-3882. Reviewed-by:
Eric Auger <eric.auger@redhat.com> Tested-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> CVE-2019-3882 (backported from commit 49285593) [tyhicks: Backport to 4.4: - Minor context differences due to missing blocking notifier from commit c086de81 ("vfio iommu: Add blocking notifier to notify DMA_UNMAP") - vfio_dma_do_map() doesn't yet have an out_unlock label which was added in commit 8f0d5bb9 ("vfio iommu type1: Add task structure to vfio_dma")] Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Arvind Sankar authored
BugLink: https://bugs.launchpad.net/bugs/1818490 The runtime_suspend device callbacks are not supposed to save configuration state or change the power state. Commit fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") changed the driver to not save configuration state during runtime suspend, however the driver callback still put the device into a low-power state. This causes a warning in the pci pm core and results in pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend. Fix this by not changing the power state either, leaving that to pci pm core, and make the same change for suspend callback as well. Also move a couple of defines into the appropriate header file instead of inline in the .c file. Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") Signed-off-by:
Arvind Sankar <niveditas98@gmail.com> Reviewed-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit dabb8338) Signed-off-by:
You-Sheng Yang <vicamo.yang@canonical.com> Acked-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
- 15 Apr, 2019 2 commits
-
-
Peng Hao authored
BugLink: https://bugs.launchpad.net/bugs/1822821 Inside a nested guest, access to hardware can be slow enough that tsc_read_refs always return ULLONG_MAX, causing tsc_refine_calibration_work to be called periodically and the nested guest to spend a lot of time reading the ACPI timer. However, if the TSC frequency is available from the pvclock page, we can just set X86_FEATURE_TSC_KNOWN_FREQ and avoid the recalibration. 'refine' operation. Suggested-by:
Peng Hao <peng.hao2@zte.com.cn> [Commit message rewritten. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit e10f7805) Signed-off-by:
Heitor R. Alves de Siqueira <halves@canonical.com> Acked-by:
-
Bin Gao authored
BugLink: https://bugs.launchpad.net/bugs/1822821 The X86_FEATURE_TSC_RELIABLE flag in Linux kernel implies both reliable (at runtime) and trustable (at calibration). But reliable running and trustable calibration independent of each other. Add a new flag X86_FEATURE_TSC_KNOWN_FREQ, which denotes that the frequency is known (via MSR/CPUID). This flag is only meant to skip the long term calibration on systems which have a known frequency. Add X86_FEATURE_TSC_KNOWN_FREQ to the skip the delayed calibration and leave X86_FEATURE_TSC_RELIABLE in place. After converting the existing users of X86_FEATURE_TSC_RELIABLE to use either both flags or just X86_FEATURE_TSC_KNOWN_FREQ we can seperate the functionality. Suggested-by:
Bin Gao <bin.gao@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1479241644-234277-2-git-send-email-bin.gao@linux.intel.comSigned-off-by:
-
