--- /dev/null
+From d07a9a4f66e944fcc900812cbc2f6817bde6a43d Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Thu, 4 Jul 2019 16:02:10 +0800
+Subject: ALSA: hda/realtek - Headphone Mic can't record after S3
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit d07a9a4f66e944fcc900812cbc2f6817bde6a43d upstream.
+
+Dell headset mode platform with ALC236.
+It doesn't recording after system resume from S3.
+S3 mode was deep. s2idle was not has this issue.
+S3 deep will cut of codec power. So, the register will back to default
+after resume back.
+This patch will solve this issue.
+
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -3255,6 +3255,7 @@ static void alc256_init(struct hda_codec
+ alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
++ alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/
+ }
+
+ static void alc256_shutup(struct hda_codec *codec)
+@@ -7825,7 +7826,6 @@ static int patch_alc269(struct hda_codec
+ spec->shutup = alc256_shutup;
+ spec->init_hook = alc256_init;
+ spec->gen.mixer_nid = 0; /* ALC256 does not have any loopback mixer path */
+- alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/
+ break;
+ case 0x10ec0257:
+ spec->codec_variant = ALC269_TYPE_ALC257;
--- /dev/null
+From ca95c7bf3d29716916baccdc77c3c2284b703069 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 4 Jul 2019 16:31:12 +0200
+Subject: ALSA: usb-audio: Fix parse of UAC2 Extension Units
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit ca95c7bf3d29716916baccdc77c3c2284b703069 upstream.
+
+Extension Unit (XU) is used to have a compatible layout with
+Processing Unit (PU) on UAC1, and the usb-audio driver code assumed it
+for parsing the descriptors. Meanwhile, on UAC2, XU became slightly
+incompatible with PU; namely, XU has a one-byte bmControls bitmap
+while PU has two bytes bmControls bitmap. This incompatibility
+results in the read of a wrong address for the last iExtension field,
+which ended up with an incorrect string for the mixer element name, as
+recently reported for Focusrite Scarlett 18i20 device.
+
+This patch corrects this misalignment by introducing a couple of new
+macros and calling them depending on the descriptor type.
+
+Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
+Reported-by: Stefan Sauer <ensonic@hora-obscura.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/uapi/linux/usb/audio.h | 37 +++++++++++++++++++++++++++++++++++++
+ sound/usb/mixer.c | 16 ++++++++++------
+ 2 files changed, 47 insertions(+), 6 deletions(-)
+
+--- a/include/uapi/linux/usb/audio.h
++++ b/include/uapi/linux/usb/audio.h
+@@ -450,6 +450,43 @@ static inline __u8 *uac_processing_unit_
+ }
+ }
+
++/*
++ * Extension Unit (XU) has almost compatible layout with Processing Unit, but
++ * on UAC2, it has a different bmControls size (bControlSize); it's 1 byte for
++ * XU while 2 bytes for PU. The last iExtension field is a one-byte index as
++ * well as iProcessing field of PU.
++ */
++static inline __u8 uac_extension_unit_bControlSize(struct uac_processing_unit_descriptor *desc,
++ int protocol)
++{
++ switch (protocol) {
++ case UAC_VERSION_1:
++ return desc->baSourceID[desc->bNrInPins + 4];
++ case UAC_VERSION_2:
++ return 1; /* in UAC2, this value is constant */
++ case UAC_VERSION_3:
++ return 4; /* in UAC3, this value is constant */
++ default:
++ return 1;
++ }
++}
++
++static inline __u8 uac_extension_unit_iExtension(struct uac_processing_unit_descriptor *desc,
++ int protocol)
++{
++ __u8 control_size = uac_extension_unit_bControlSize(desc, protocol);
++
++ switch (protocol) {
++ case UAC_VERSION_1:
++ case UAC_VERSION_2:
++ default:
++ return *(uac_processing_unit_bmControls(desc, protocol)
++ + control_size);
++ case UAC_VERSION_3:
++ return 0; /* UAC3 does not have this field */
++ }
++}
++
+ /* 4.5.2 Class-Specific AS Interface Descriptor */
+ struct uac1_as_header_descriptor {
+ __u8 bLength; /* in bytes: 7 */
+--- a/sound/usb/mixer.c
++++ b/sound/usb/mixer.c
+@@ -2303,7 +2303,7 @@ static struct procunit_info extunits[] =
+ */
+ static int build_audio_procunit(struct mixer_build *state, int unitid,
+ void *raw_desc, struct procunit_info *list,
+- char *name)
++ bool extension_unit)
+ {
+ struct uac_processing_unit_descriptor *desc = raw_desc;
+ int num_ins;
+@@ -2320,6 +2320,8 @@ static int build_audio_procunit(struct m
+ static struct procunit_info default_info = {
+ 0, NULL, default_value_info
+ };
++ const char *name = extension_unit ?
++ "Extension Unit" : "Processing Unit";
+
+ if (desc->bLength < 13) {
+ usb_audio_err(state->chip, "invalid %s descriptor (id %d)\n", name, unitid);
+@@ -2433,7 +2435,10 @@ static int build_audio_procunit(struct m
+ } else if (info->name) {
+ strlcpy(kctl->id.name, info->name, sizeof(kctl->id.name));
+ } else {
+- nameid = uac_processing_unit_iProcessing(desc, state->mixer->protocol);
++ if (extension_unit)
++ nameid = uac_extension_unit_iExtension(desc, state->mixer->protocol);
++ else
++ nameid = uac_processing_unit_iProcessing(desc, state->mixer->protocol);
+ len = 0;
+ if (nameid)
+ len = snd_usb_copy_string_desc(state->chip,
+@@ -2466,10 +2471,10 @@ static int parse_audio_processing_unit(s
+ case UAC_VERSION_2:
+ default:
+ return build_audio_procunit(state, unitid, raw_desc,
+- procunits, "Processing Unit");
++ procunits, false);
+ case UAC_VERSION_3:
+ return build_audio_procunit(state, unitid, raw_desc,
+- uac3_procunits, "Processing Unit");
++ uac3_procunits, false);
+ }
+ }
+
+@@ -2480,8 +2485,7 @@ static int parse_audio_extension_unit(st
+ * Note that we parse extension units with processing unit descriptors.
+ * That's ok as the layout is the same.
+ */
+- return build_audio_procunit(state, unitid, raw_desc,
+- extunits, "Extension Unit");
++ return build_audio_procunit(state, unitid, raw_desc, extunits, true);
+ }
+
+ /*
--- /dev/null
+From dbc3117d4ca9e17819ac73501e914b8422686750 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Thu, 27 Jun 2019 21:44:09 -0700
+Subject: block, bfq: NULL out the bic when it's no longer valid
+
+From: Douglas Anderson <dianders@chromium.org>
+
+commit dbc3117d4ca9e17819ac73501e914b8422686750 upstream.
+
+In reboot tests on several devices we were seeing a "use after free"
+when slub_debug or KASAN was enabled. The kernel complained about:
+
+ Unable to handle kernel paging request at virtual address 6b6b6c2b
+
+...which is a classic sign of use after free under slub_debug. The
+stack crawl in kgdb looked like:
+
+ 0 test_bit (addr=<optimized out>, nr=<optimized out>)
+ 1 bfq_bfqq_busy (bfqq=<optimized out>)
+ 2 bfq_select_queue (bfqd=<optimized out>)
+ 3 __bfq_dispatch_request (hctx=<optimized out>)
+ 4 bfq_dispatch_request (hctx=<optimized out>)
+ 5 0xc056ef00 in blk_mq_do_dispatch_sched (hctx=0xed249440)
+ 6 0xc056f728 in blk_mq_sched_dispatch_requests (hctx=0xed249440)
+ 7 0xc0568d24 in __blk_mq_run_hw_queue (hctx=0xed249440)
+ 8 0xc0568d94 in blk_mq_run_work_fn (work=<optimized out>)
+ 9 0xc024c5c4 in process_one_work (worker=0xec6d4640, work=0xed249480)
+ 10 0xc024cff4 in worker_thread (__worker=0xec6d4640)
+
+Digging in kgdb, it could be found that, though bfqq looked fine,
+bfqq->bic had been freed.
+
+Through further digging, I postulated that perhaps it is illegal to
+access a "bic" (AKA an "icq") after bfq_exit_icq() had been called
+because the "bic" can be freed at some point in time after this call
+is made. I confirmed that there certainly were cases where the exact
+crashing code path would access the "bic" after bfq_exit_icq() had
+been called. Sspecifically I set the "bfqq->bic" to (void *)0x7 and
+saw that the bic was 0x7 at the time of the crash.
+
+To understand a bit more about why this crash was fairly uncommon (I
+saw it only once in a few hundred reboots), you can see that much of
+the time bfq_exit_icq_fbqq() fully frees the bfqq and thus it can't
+access the ->bic anymore. The only case it doesn't is if
+bfq_put_queue() sees a reference still held.
+
+However, even in the case when bfqq isn't freed, the crash is still
+rare. Why? I tracked what happened to the "bic" after the exit
+routine. It doesn't get freed right away. Rather,
+put_io_context_active() eventually called put_io_context() which
+queued up freeing on a workqueue. The freeing then actually happened
+later than that through call_rcu(). Despite all these delays, some
+extra debugging showed that all the hoops could be jumped through in
+time and the memory could be freed causing the original crash. Phew!
+
+To make a long story short, assuming it truly is illegal to access an
+icq after the "exit_icq" callback is finished, this patch is needed.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/bfq-iosched.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -4584,6 +4584,7 @@ static void bfq_exit_icq_bfqq(struct bfq
+ unsigned long flags;
+
+ spin_lock_irqsave(&bfqd->lock, flags);
++ bfqq->bic = NULL;
+ bfq_exit_bfqq(bfqd, bfqq);
+ bic_set_bfqq(bic, NULL, is_sync);
+ spin_unlock_irqrestore(&bfqd->lock, flags);
--- /dev/null
+From 79d08f89bb1b5c2c1ff90d9bb95497ab9e8aa7e0 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Mon, 1 Jul 2019 15:14:46 +0800
+Subject: block: fix .bi_size overflow
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit 79d08f89bb1b5c2c1ff90d9bb95497ab9e8aa7e0 upstream.
+
+'bio->bi_iter.bi_size' is 'unsigned int', which at most hold 4G - 1
+bytes.
+
+Before 07173c3ec276 ("block: enable multipage bvecs"), one bio can
+include very limited pages, and usually at most 256, so the fs bio
+size won't be bigger than 1M bytes most of times.
+
+Since we support multi-page bvec, in theory one fs bio really can
+be added > 1M pages, especially in case of hugepage, or big writeback
+with too many dirty pages. Then there is chance in which .bi_size
+is overflowed.
+
+Fixes this issue by using bio_full() to check if the added segment may
+overflow .bi_size.
+
+Cc: Liu Yiding <liuyd.fnst@cn.fujitsu.com>
+Cc: kernel test robot <rong.a.chen@intel.com>
+Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
+Cc: linux-xfs@vger.kernel.org
+Cc: linux-fsdevel@vger.kernel.org
+Cc: stable@vger.kernel.org
+Fixes: 07173c3ec276 ("block: enable multipage bvecs")
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/bio.c | 10 +++++-----
+ fs/iomap.c | 2 +-
+ fs/xfs/xfs_aops.c | 2 +-
+ include/linux/bio.h | 18 ++++++++++++++++--
+ 4 files changed, 23 insertions(+), 9 deletions(-)
+
+--- a/block/bio.c
++++ b/block/bio.c
+@@ -731,7 +731,7 @@ static int __bio_add_pc_page(struct requ
+ }
+ }
+
+- if (bio_full(bio))
++ if (bio_full(bio, len))
+ return 0;
+
+ if (bio->bi_phys_segments >= queue_max_segments(q))
+@@ -807,7 +807,7 @@ void __bio_add_page(struct bio *bio, str
+ struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt];
+
+ WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED));
+- WARN_ON_ONCE(bio_full(bio));
++ WARN_ON_ONCE(bio_full(bio, len));
+
+ bv->bv_page = page;
+ bv->bv_offset = off;
+@@ -834,7 +834,7 @@ int bio_add_page(struct bio *bio, struct
+ bool same_page = false;
+
+ if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) {
+- if (bio_full(bio))
++ if (bio_full(bio, len))
+ return 0;
+ __bio_add_page(bio, page, len, offset);
+ }
+@@ -922,7 +922,7 @@ static int __bio_iov_iter_get_pages(stru
+ if (same_page)
+ put_page(page);
+ } else {
+- if (WARN_ON_ONCE(bio_full(bio)))
++ if (WARN_ON_ONCE(bio_full(bio, len)))
+ return -EINVAL;
+ __bio_add_page(bio, page, len, offset);
+ }
+@@ -966,7 +966,7 @@ int bio_iov_iter_get_pages(struct bio *b
+ ret = __bio_iov_bvec_add_pages(bio, iter);
+ else
+ ret = __bio_iov_iter_get_pages(bio, iter);
+- } while (!ret && iov_iter_count(iter) && !bio_full(bio));
++ } while (!ret && iov_iter_count(iter) && !bio_full(bio, 0));
+
+ if (iov_iter_bvec_no_ref(iter))
+ bio_set_flag(bio, BIO_NO_PAGE_REF);
+--- a/fs/iomap.c
++++ b/fs/iomap.c
+@@ -333,7 +333,7 @@ iomap_readpage_actor(struct inode *inode
+ if (iop)
+ atomic_inc(&iop->read_count);
+
+- if (!ctx->bio || !is_contig || bio_full(ctx->bio)) {
++ if (!ctx->bio || !is_contig || bio_full(ctx->bio, plen)) {
+ gfp_t gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
+ int nr_vecs = (length + PAGE_SIZE - 1) >> PAGE_SHIFT;
+
+--- a/fs/xfs/xfs_aops.c
++++ b/fs/xfs/xfs_aops.c
+@@ -782,7 +782,7 @@ xfs_add_to_ioend(
+ atomic_inc(&iop->write_count);
+
+ if (!merged) {
+- if (bio_full(wpc->ioend->io_bio))
++ if (bio_full(wpc->ioend->io_bio, len))
+ xfs_chain_bio(wpc->ioend, wbc, bdev, sector);
+ bio_add_page(wpc->ioend->io_bio, page, len, poff);
+ }
+--- a/include/linux/bio.h
++++ b/include/linux/bio.h
+@@ -102,9 +102,23 @@ static inline void *bio_data(struct bio
+ return NULL;
+ }
+
+-static inline bool bio_full(struct bio *bio)
++/**
++ * bio_full - check if the bio is full
++ * @bio: bio to check
++ * @len: length of one segment to be added
++ *
++ * Return true if @bio is full and one segment with @len bytes can't be
++ * added to the bio, otherwise return false
++ */
++static inline bool bio_full(struct bio *bio, unsigned len)
+ {
+- return bio->bi_vcnt >= bio->bi_max_vecs;
++ if (bio->bi_vcnt >= bio->bi_max_vecs)
++ return true;
++
++ if (bio->bi_iter.bi_size > UINT_MAX - len)
++ return true;
++
++ return false;
+ }
+
+ static inline bool bio_next_segment(const struct bio *bio,
--- /dev/null
+From 6e88559470f581741bcd0f2794f9054814ac9740 Mon Sep 17 00:00:00 2001
+From: Tim Chen <tim.c.chen@linux.intel.com>
+Date: Thu, 20 Jun 2019 16:10:50 -0700
+Subject: Documentation: Add section about CPU vulnerabilities for Spectre
+
+From: Tim Chen <tim.c.chen@linux.intel.com>
+
+commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream.
+
+Add documentation for Spectre vulnerability and the mitigation mechanisms:
+
+- Explain the problem and risks
+- Document the mitigation mechanisms
+- Document the command line controls
+- Document the sysfs files
+
+Co-developed-by: Andi Kleen <ak@linux.intel.com>
+Signed-off-by: Andi Kleen <ak@linux.intel.com>
+Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com>
+Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
+Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jonathan Corbet <corbet@lwn.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/admin-guide/hw-vuln/index.rst | 1
+ Documentation/admin-guide/hw-vuln/spectre.rst | 697 ++++++++++++++++++++++++++
+ Documentation/userspace-api/spec_ctrl.rst | 2
+ 3 files changed, 700 insertions(+)
+
+--- a/Documentation/admin-guide/hw-vuln/index.rst
++++ b/Documentation/admin-guide/hw-vuln/index.rst
+@@ -9,5 +9,6 @@ are configurable at compile, boot or run
+ .. toctree::
+ :maxdepth: 1
+
++ spectre
+ l1tf
+ mds
+--- /dev/null
++++ b/Documentation/admin-guide/hw-vuln/spectre.rst
+@@ -0,0 +1,697 @@
++.. SPDX-License-Identifier: GPL-2.0
++
++Spectre Side Channels
++=====================
++
++Spectre is a class of side channel attacks that exploit branch prediction
++and speculative execution on modern CPUs to read memory, possibly
++bypassing access controls. Speculative execution side channel exploits
++do not modify memory but attempt to infer privileged data in the memory.
++
++This document covers Spectre variant 1 and Spectre variant 2.
++
++Affected processors
++-------------------
++
++Speculative execution side channel methods affect a wide range of modern
++high performance processors, since most modern high speed processors
++use branch prediction and speculative execution.
++
++The following CPUs are vulnerable:
++
++ - Intel Core, Atom, Pentium, and Xeon processors
++
++ - AMD Phenom, EPYC, and Zen processors
++
++ - IBM POWER and zSeries processors
++
++ - Higher end ARM processors
++
++ - Apple CPUs
++
++ - Higher end MIPS CPUs
++
++ - Likely most other high performance CPUs. Contact your CPU vendor for details.
++
++Whether a processor is affected or not can be read out from the Spectre
++vulnerability files in sysfs. See :ref:`spectre_sys_info`.
++
++Related CVEs
++------------
++
++The following CVE entries describe Spectre variants:
++
++ ============= ======================= =================
++ CVE-2017-5753 Bounds check bypass Spectre variant 1
++ CVE-2017-5715 Branch target injection Spectre variant 2
++ ============= ======================= =================
++
++Problem
++-------
++
++CPUs use speculative operations to improve performance. That may leave
++traces of memory accesses or computations in the processor's caches,
++buffers, and branch predictors. Malicious software may be able to
++influence the speculative execution paths, and then use the side effects
++of the speculative execution in the CPUs' caches and buffers to infer
++privileged data touched during the speculative execution.
++
++Spectre variant 1 attacks take advantage of speculative execution of
++conditional branches, while Spectre variant 2 attacks use speculative
++execution of indirect branches to leak privileged memory.
++See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
++:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
++
++Spectre variant 1 (Bounds Check Bypass)
++---------------------------------------
++
++The bounds check bypass attack :ref:`[2] <spec_ref2>` takes advantage
++of speculative execution that bypasses conditional branch instructions
++used for memory access bounds check (e.g. checking if the index of an
++array results in memory access within a valid range). This results in
++memory accesses to invalid memory (with out-of-bound index) that are
++done speculatively before validation checks resolve. Such speculative
++memory accesses can leave side effects, creating side channels which
++leak information to the attacker.
++
++There are some extensions of Spectre variant 1 attacks for reading data
++over the network, see :ref:`[12] <spec_ref12>`. However such attacks
++are difficult, low bandwidth, fragile, and are considered low risk.
++
++Spectre variant 2 (Branch Target Injection)
++-------------------------------------------
++
++The branch target injection attack takes advantage of speculative
++execution of indirect branches :ref:`[3] <spec_ref3>`. The indirect
++branch predictors inside the processor used to guess the target of
++indirect branches can be influenced by an attacker, causing gadget code
++to be speculatively executed, thus exposing sensitive data touched by
++the victim. The side effects left in the CPU's caches during speculative
++execution can be measured to infer data values.
++
++.. _poison_btb:
++
++In Spectre variant 2 attacks, the attacker can steer speculative indirect
++branches in the victim to gadget code by poisoning the branch target
++buffer of a CPU used for predicting indirect branch addresses. Such
++poisoning could be done by indirect branching into existing code,
++with the address offset of the indirect branch under the attacker's
++control. Since the branch prediction on impacted hardware does not
++fully disambiguate branch address and uses the offset for prediction,
++this could cause privileged code's indirect branch to jump to a gadget
++code with the same offset.
++
++The most useful gadgets take an attacker-controlled input parameter (such
++as a register value) so that the memory read can be controlled. Gadgets
++without input parameters might be possible, but the attacker would have
++very little control over what memory can be read, reducing the risk of
++the attack revealing useful data.
++
++One other variant 2 attack vector is for the attacker to poison the
++return stack buffer (RSB) :ref:`[13] <spec_ref13>` to cause speculative
++subroutine return instruction execution to go to a gadget. An attacker's
++imbalanced subroutine call instructions might "poison" entries in the
++return stack buffer which are later consumed by a victim's subroutine
++return instructions. This attack can be mitigated by flushing the return
++stack buffer on context switch, or virtual machine (VM) exit.
++
++On systems with simultaneous multi-threading (SMT), attacks are possible
++from the sibling thread, as level 1 cache and branch target buffer
++(BTB) may be shared between hardware threads in a CPU core. A malicious
++program running on the sibling thread may influence its peer's BTB to
++steer its indirect branch speculations to gadget code, and measure the
++speculative execution's side effects left in level 1 cache to infer the
++victim's data.
++
++Attack scenarios
++----------------
++
++The following list of attack scenarios have been anticipated, but may
++not cover all possible attack vectors.
++
++1. A user process attacking the kernel
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ The attacker passes a parameter to the kernel via a register or
++ via a known address in memory during a syscall. Such parameter may
++ be used later by the kernel as an index to an array or to derive
++ a pointer for a Spectre variant 1 attack. The index or pointer
++ is invalid, but bound checks are bypassed in the code branch taken
++ for speculative execution. This could cause privileged memory to be
++ accessed and leaked.
++
++ For kernel code that has been identified where data pointers could
++ potentially be influenced for Spectre attacks, new "nospec" accessor
++ macros are used to prevent speculative loading of data.
++
++ Spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
++ target buffer (BTB) before issuing syscall to launch an attack.
++ After entering the kernel, the kernel could use the poisoned branch
++ target buffer on indirect jump and jump to gadget code in speculative
++ execution.
++
++ If an attacker tries to control the memory addresses leaked during
++ speculative execution, he would also need to pass a parameter to the
++ gadget, either through a register or a known address in memory. After
++ the gadget has executed, he can measure the side effect.
++
++ The kernel can protect itself against consuming poisoned branch
++ target buffer entries by using return trampolines (also known as
++ "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all
++ indirect branches. Return trampolines trap speculative execution paths
++ to prevent jumping to gadget code during speculative execution.
++ x86 CPUs with Enhanced Indirect Branch Restricted Speculation
++ (Enhanced IBRS) available in hardware should use the feature to
++ mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is
++ more efficient than retpoline.
++
++ There may be gadget code in firmware which could be exploited with
++ Spectre variant 2 attack by a rogue user process. To mitigate such
++ attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature
++ is turned on before the kernel invokes any firmware code.
++
++2. A user process attacking another user process
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ A malicious user process can try to attack another user process,
++ either via a context switch on the same hardware thread, or from the
++ sibling hyperthread sharing a physical processor core on simultaneous
++ multi-threading (SMT) system.
++
++ Spectre variant 1 attacks generally require passing parameters
++ between the processes, which needs a data passing relationship, such
++ as remote procedure calls (RPC). Those parameters are used in gadget
++ code to derive invalid data pointers accessing privileged memory in
++ the attacked process.
++
++ Spectre variant 2 attacks can be launched from a rogue process by
++ :ref:`poisoning <poison_btb>` the branch target buffer. This can
++ influence the indirect branch targets for a victim process that either
++ runs later on the same hardware thread, or running concurrently on
++ a sibling hardware thread sharing the same physical core.
++
++ A user process can protect itself against Spectre variant 2 attacks
++ by using the prctl() syscall to disable indirect branch speculation
++ for itself. An administrator can also cordon off an unsafe process
++ from polluting the branch target buffer by disabling the process's
++ indirect branch speculation. This comes with a performance cost
++ from not using indirect branch speculation and clearing the branch
++ target buffer. When SMT is enabled on x86, for a process that has
++ indirect branch speculation disabled, Single Threaded Indirect Branch
++ Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the
++ sibling thread from controlling branch target buffer. In addition,
++ the Indirect Branch Prediction Barrier (IBPB) is issued to clear the
++ branch target buffer when context switching to and from such process.
++
++ On x86, the return stack buffer is stuffed on context switch.
++ This prevents the branch target buffer from being used for branch
++ prediction when the return stack buffer underflows while switching to
++ a deeper call stack. Any poisoned entries in the return stack buffer
++ left by the previous process will also be cleared.
++
++ User programs should use address space randomization to make attacks
++ more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).
++
++3. A virtualized guest attacking the host
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ The attack mechanism is similar to how user processes attack the
++ kernel. The kernel is entered via hyper-calls or other virtualization
++ exit paths.
++
++ For Spectre variant 1 attacks, rogue guests can pass parameters
++ (e.g. in registers) via hyper-calls to derive invalid pointers to
++ speculate into privileged memory after entering the kernel. For places
++ where such kernel code has been identified, nospec accessor macros
++ are used to stop speculative memory access.
++
++ For Spectre variant 2 attacks, rogue guests can :ref:`poison
++ <poison_btb>` the branch target buffer or return stack buffer, causing
++ the kernel to jump to gadget code in the speculative execution paths.
++
++ To mitigate variant 2, the host kernel can use return trampolines
++ for indirect branches to bypass the poisoned branch target buffer,
++ and flushing the return stack buffer on VM exit. This prevents rogue
++ guests from affecting indirect branching in the host kernel.
++
++ To protect host processes from rogue guests, host processes can have
++ indirect branch speculation disabled via prctl(). The branch target
++ buffer is cleared before context switching to such processes.
++
++4. A virtualized guest attacking other guest
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ A rogue guest may attack another guest to get data accessible by the
++ other guest.
++
++ Spectre variant 1 attacks are possible if parameters can be passed
++ between guests. This may be done via mechanisms such as shared memory
++ or message passing. Such parameters could be used to derive data
++ pointers to privileged data in guest. The privileged data could be
++ accessed by gadget code in the victim's speculation paths.
++
++ Spectre variant 2 attacks can be launched from a rogue guest by
++ :ref:`poisoning <poison_btb>` the branch target buffer or the return
++ stack buffer. Such poisoned entries could be used to influence
++ speculation execution paths in the victim guest.
++
++ Linux kernel mitigates attacks to other guests running in the same
++ CPU hardware thread by flushing the return stack buffer on VM exit,
++ and clearing the branch target buffer before switching to a new guest.
++
++ If SMT is used, Spectre variant 2 attacks from an untrusted guest
++ in the sibling hyperthread can be mitigated by the administrator,
++ by turning off the unsafe guest's indirect branch speculation via
++ prctl(). A guest can also protect itself by turning on microcode
++ based mitigations (such as IBPB or STIBP on x86) within the guest.
++
++.. _spectre_sys_info:
++
++Spectre system information
++--------------------------
++
++The Linux kernel provides a sysfs interface to enumerate the current
++mitigation status of the system for Spectre: whether the system is
++vulnerable, and which mitigations are active.
++
++The sysfs file showing Spectre variant 1 mitigation status is:
++
++ /sys/devices/system/cpu/vulnerabilities/spectre_v1
++
++The possible values in this file are:
++
++ ======================================= =================================
++ 'Mitigation: __user pointer sanitation' Protection in kernel on a case by
++ case base with explicit pointer
++ sanitation.
++ ======================================= =================================
++
++However, the protections are put in place on a case by case basis,
++and there is no guarantee that all possible attack vectors for Spectre
++variant 1 are covered.
++
++The spectre_v2 kernel file reports if the kernel has been compiled with
++retpoline mitigation or if the CPU has hardware mitigation, and if the
++CPU has support for additional process-specific mitigation.
++
++This file also reports CPU features enabled by microcode to mitigate
++attack between user processes:
++
++1. Indirect Branch Prediction Barrier (IBPB) to add additional
++ isolation between processes of different users.
++2. Single Thread Indirect Branch Predictors (STIBP) to add additional
++ isolation between CPU threads running on the same core.
++
++These CPU features may impact performance when used and can be enabled
++per process on a case-by-case base.
++
++The sysfs file showing Spectre variant 2 mitigation status is:
++
++ /sys/devices/system/cpu/vulnerabilities/spectre_v2
++
++The possible values in this file are:
++
++ - Kernel status:
++
++ ==================================== =================================
++ 'Not affected' The processor is not vulnerable
++ 'Vulnerable' Vulnerable, no mitigation
++ 'Mitigation: Full generic retpoline' Software-focused mitigation
++ 'Mitigation: Full AMD retpoline' AMD-specific software mitigation
++ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
++ ==================================== =================================
++
++ - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
++ used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
++
++ ========== =============================================================
++ 'IBRS_FW' Protection against user program attacks when calling firmware
++ ========== =============================================================
++
++ - Indirect branch prediction barrier (IBPB) status for protection between
++ processes of different users. This feature can be controlled through
++ prctl() per process, or through kernel command line options. This is
++ an x86 only feature. For more details see below.
++
++ =================== ========================================================
++ 'IBPB: disabled' IBPB unused
++ 'IBPB: always-on' Use IBPB on all tasks
++ 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks
++ =================== ========================================================
++
++ - Single threaded indirect branch prediction (STIBP) status for protection
++ between different hyper threads. This feature can be controlled through
++ prctl per process, or through kernel command line options. This is x86
++ only feature. For more details see below.
++
++ ==================== ========================================================
++ 'STIBP: disabled' STIBP unused
++ 'STIBP: forced' Use STIBP on all tasks
++ 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks
++ ==================== ========================================================
++
++ - Return stack buffer (RSB) protection status:
++
++ ============= ===========================================
++ 'RSB filling' Protection of RSB on context switch enabled
++ ============= ===========================================
++
++Full mitigation might require a microcode update from the CPU
++vendor. When the necessary microcode is not available, the kernel will
++report vulnerability.
++
++Turning on mitigation for Spectre variant 1 and Spectre variant 2
++-----------------------------------------------------------------
++
++1. Kernel mitigation
++^^^^^^^^^^^^^^^^^^^^
++
++ For the Spectre variant 1, vulnerable kernel code (as determined
++ by code audit or scanning tools) is annotated on a case by case
++ basis to use nospec accessor macros for bounds clipping :ref:`[2]
++ <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
++ not cover all attack vectors for Spectre variant 1.
++
++ For Spectre variant 2 mitigation, the compiler turns indirect calls or
++ jumps in the kernel into equivalent return trampolines (retpolines)
++ :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
++ addresses. Speculative execution paths under retpolines are trapped
++ in an infinite loop to prevent any speculative execution jumping to
++ a gadget.
++
++ To turn on retpoline mitigation on a vulnerable CPU, the kernel
++ needs to be compiled with a gcc compiler that supports the
++ -mindirect-branch=thunk-extern -mindirect-branch-register options.
++ If the kernel is compiled with a Clang compiler, the compiler needs
++ to support -mretpoline-external-thunk option. The kernel config
++ CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
++ the latest updated microcode.
++
++ On Intel Skylake-era systems the mitigation covers most, but not all,
++ cases. See :ref:`[3] <spec_ref3>` for more details.
++
++ On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
++ IBRS on x86), retpoline is automatically disabled at run time.
++
++ The retpoline mitigation is turned on by default on vulnerable
++ CPUs. It can be forced on or off by the administrator
++ via the kernel command line and sysfs control files. See
++ :ref:`spectre_mitigation_control_command_line`.
++
++ On x86, indirect branch restricted speculation is turned on by default
++ before invoking any firmware code to prevent Spectre variant 2 exploits
++ using the firmware.
++
++ Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y
++ and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
++ attacks on the kernel generally more difficult.
++
++2. User program mitigation
++^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ User programs can mitigate Spectre variant 1 using LFENCE or "bounds
++ clipping". For more details see :ref:`[2] <spec_ref2>`.
++
++ For Spectre variant 2 mitigation, individual user programs
++ can be compiled with return trampolines for indirect branches.
++ This protects them from consuming poisoned entries in the branch
++ target buffer left by malicious software. Alternatively, the
++ programs can disable their indirect branch speculation via prctl()
++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
++ On x86, this will turn on STIBP to guard against attacks from the
++ sibling thread when the user program is running, and use IBPB to
++ flush the branch target buffer when switching to/from the program.
++
++ Restricting indirect branch speculation on a user program will
++ also prevent the program from launching a variant 2 attack
++ on x86. All sand-boxed SECCOMP programs have indirect branch
++ speculation restricted by default. Administrators can change
++ that behavior via the kernel command line and sysfs control files.
++ See :ref:`spectre_mitigation_control_command_line`.
++
++ Programs that disable their indirect branch speculation will have
++ more overhead and run slower.
++
++ User programs should use address space randomization
++ (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more
++ difficult.
++
++3. VM mitigation
++^^^^^^^^^^^^^^^^
++
++ Within the kernel, Spectre variant 1 attacks from rogue guests are
++ mitigated on a case by case basis in VM exit paths. Vulnerable code
++ uses nospec accessor macros for "bounds clipping", to avoid any
++ usable disclosure gadgets. However, this may not cover all variant
++ 1 attack vectors.
++
++ For Spectre variant 2 attacks from rogue guests to the kernel, the
++ Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of
++ poisoned entries in branch target buffer left by rogue guests. It also
++ flushes the return stack buffer on every VM exit to prevent a return
++ stack buffer underflow so poisoned branch target buffer could be used,
++ or attacker guests leaving poisoned entries in the return stack buffer.
++
++ To mitigate guest-to-guest attacks in the same CPU hardware thread,
++ the branch target buffer is sanitized by flushing before switching
++ to a new guest on a CPU.
++
++ The above mitigations are turned on by default on vulnerable CPUs.
++
++ To mitigate guest-to-guest attacks from sibling thread when SMT is
++ in use, an untrusted guest running in the sibling thread can have
++ its indirect branch speculation disabled by administrator via prctl().
++
++ The kernel also allows guests to use any microcode based mitigation
++ they choose to use (such as IBPB or STIBP on x86) to protect themselves.
++
++.. _spectre_mitigation_control_command_line:
++
++Mitigation control on the kernel command line
++---------------------------------------------
++
++Spectre variant 2 mitigation can be disabled or force enabled at the
++kernel command line.
++
++ nospectre_v2
++
++ [X86] Disable all mitigations for the Spectre variant 2
++ (indirect branch prediction) vulnerability. System may
++ allow data leaks with this option, which is equivalent
++ to spectre_v2=off.
++
++
++ spectre_v2=
++
++ [X86] Control mitigation of Spectre variant 2
++ (indirect branch speculation) vulnerability.
++ The default operation protects the kernel from
++ user space attacks.
++
++ on
++ unconditionally enable, implies
++ spectre_v2_user=on
++ off
++ unconditionally disable, implies
++ spectre_v2_user=off
++ auto
++ kernel detects whether your CPU model is
++ vulnerable
++
++ Selecting 'on' will, and 'auto' may, choose a
++ mitigation method at run time according to the
++ CPU, the available microcode, the setting of the
++ CONFIG_RETPOLINE configuration option, and the
++ compiler with which the kernel was built.
++
++ Selecting 'on' will also enable the mitigation
++ against user space to user space task attacks.
++
++ Selecting 'off' will disable both the kernel and
++ the user space protections.
++
++ Specific mitigations can also be selected manually:
++
++ retpoline
++ replace indirect branches
++ retpoline,generic
++ google's original retpoline
++ retpoline,amd
++ AMD-specific minimal thunk
++
++ Not specifying this option is equivalent to
++ spectre_v2=auto.
++
++For user space mitigation:
++
++ spectre_v2_user=
++
++ [X86] Control mitigation of Spectre variant 2
++ (indirect branch speculation) vulnerability between
++ user space tasks
++
++ on
++ Unconditionally enable mitigations. Is
++ enforced by spectre_v2=on
++
++ off
++ Unconditionally disable mitigations. Is
++ enforced by spectre_v2=off
++
++ prctl
++ Indirect branch speculation is enabled,
++ but mitigation can be enabled via prctl
++ per thread. The mitigation control state
++ is inherited on fork.
++
++ prctl,ibpb
++ Like "prctl" above, but only STIBP is
++ controlled per thread. IBPB is issued
++ always when switching between different user
++ space processes.
++
++ seccomp
++ Same as "prctl" above, but all seccomp
++ threads will enable the mitigation unless
++ they explicitly opt out.
++
++ seccomp,ibpb
++ Like "seccomp" above, but only STIBP is
++ controlled per thread. IBPB is issued
++ always when switching between different
++ user space processes.
++
++ auto
++ Kernel selects the mitigation depending on
++ the available CPU features and vulnerability.
++
++ Default mitigation:
++ If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
++
++ Not specifying this option is equivalent to
++ spectre_v2_user=auto.
++
++ In general the kernel by default selects
++ reasonable mitigations for the current CPU. To
++ disable Spectre variant 2 mitigations, boot with
++ spectre_v2=off. Spectre variant 1 mitigations
++ cannot be disabled.
++
++Mitigation selection guide
++--------------------------
++
++1. Trusted userspace
++^^^^^^^^^^^^^^^^^^^^
++
++ If all userspace applications are from trusted sources and do not
++ execute externally supplied untrusted code, then the mitigations can
++ be disabled.
++
++2. Protect sensitive programs
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ For security-sensitive programs that have secrets (e.g. crypto
++ keys), protection against Spectre variant 2 can be put in place by
++ disabling indirect branch speculation when the program is running
++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
++
++3. Sandbox untrusted programs
++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ Untrusted programs that could be a source of attacks can be cordoned
++ off by disabling their indirect branch speculation when they are run
++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
++ This prevents untrusted programs from polluting the branch target
++ buffer. All programs running in SECCOMP sandboxes have indirect
++ branch speculation restricted by default. This behavior can be
++ changed via the kernel command line and sysfs control files. See
++ :ref:`spectre_mitigation_control_command_line`.
++
++3. High security mode
++^^^^^^^^^^^^^^^^^^^^^
++
++ All Spectre variant 2 mitigations can be forced on
++ at boot time for all programs (See the "on" option in
++ :ref:`spectre_mitigation_control_command_line`). This will add
++ overhead as indirect branch speculations for all programs will be
++ restricted.
++
++ On x86, branch target buffer will be flushed with IBPB when switching
++ to a new program. STIBP is left on all the time to protect programs
++ against variant 2 attacks originating from programs running on
++ sibling threads.
++
++ Alternatively, STIBP can be used only when running programs
++ whose indirect branch speculation is explicitly disabled,
++ while IBPB is still used all the time when switching to a new
++ program to clear the branch target buffer (See "ibpb" option in
++ :ref:`spectre_mitigation_control_command_line`). This "ibpb" option
++ has less performance cost than the "on" option, which leaves STIBP
++ on all the time.
++
++References on Spectre
++---------------------
++
++Intel white papers:
++
++.. _spec_ref1:
++
++[1] `Intel analysis of speculative execution side channels <https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf>`_.
++
++.. _spec_ref2:
++
++[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.
++
++.. _spec_ref3:
++
++[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.
++
++.. _spec_ref4:
++
++[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.
++
++AMD white papers:
++
++.. _spec_ref5:
++
++[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
++
++.. _spec_ref6:
++
++[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
++
++ARM white papers:
++
++.. _spec_ref7:
++
++[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.
++
++.. _spec_ref8:
++
++[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.
++
++Google white paper:
++
++.. _spec_ref9:
++
++[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.
++
++MIPS white paper:
++
++.. _spec_ref10:
++
++[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
++
++Academic papers:
++
++.. _spec_ref11:
++
++[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.
++
++.. _spec_ref12:
++
++[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.
++
++.. _spec_ref13:
++
++[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.
+--- a/Documentation/userspace-api/spec_ctrl.rst
++++ b/Documentation/userspace-api/spec_ctrl.rst
+@@ -49,6 +49,8 @@ If PR_SPEC_PRCTL is set, then the per-ta
+ available. If not set, prctl(PR_SET_SPECULATION_CTRL) for the speculation
+ misfeature will fail.
+
++.. _set_spec_ctrl:
++
+ PR_SET_SPECULATION_CTRL
+ -----------------------
+
--- /dev/null
+From d974ffcfb7447db5f29a4b662a3eaf99a4e1109e Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Wed, 26 Jun 2019 21:45:02 -0700
+Subject: Documentation/admin: Remove the vsyscall=native documentation
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit d974ffcfb7447db5f29a4b662a3eaf99a4e1109e upstream.
+
+The vsyscall=native feature is gone -- remove the docs.
+
+Fixes: 076ca272a14c ("x86/vsyscall/64: Drop "native" vsyscalls")
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Kees Cook <keescook@chromium.org>
+Cc: Florian Weimer <fweimer@redhat.com>
+Cc: Jann Horn <jannh@google.com>
+Cc: stable@vger.kernel.org
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/d77c7105eb4c57c1a95a95b6a5b8ba194a18e764.1561610354.git.luto@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/admin-guide/kernel-parameters.txt | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/Documentation/admin-guide/kernel-parameters.txt
++++ b/Documentation/admin-guide/kernel-parameters.txt
+@@ -5102,12 +5102,6 @@
+ emulate [default] Vsyscalls turn into traps and are
+ emulated reasonably safely.
+
+- native Vsyscalls are native syscall instructions.
+- This is a little bit faster than trapping
+- and makes a few dynamic recompilers work
+- better than they would in emulation mode.
+- It also makes exploits much easier to write.
+-
+ none Vsyscalls don't work at all. This makes
+ them quite hard to use for exploits but
+ might break your system.
--- /dev/null
+From 5858bdad4d0d0fc18bf29f34c3ac836e0b59441f Mon Sep 17 00:00:00 2001
+From: Hongjie Fang <hongjiefang@asrmicro.com>
+Date: Wed, 22 May 2019 10:02:53 +0800
+Subject: fscrypt: don't set policy for a dead directory
+
+From: Hongjie Fang <hongjiefang@asrmicro.com>
+
+commit 5858bdad4d0d0fc18bf29f34c3ac836e0b59441f upstream.
+
+The directory may have been removed when entering
+fscrypt_ioctl_set_policy(). If so, the empty_dir() check will return
+error for ext4 file system.
+
+ext4_rmdir() sets i_size = 0, then ext4_empty_dir() reports an error
+because 'inode->i_size < EXT4_DIR_REC_LEN(1) + EXT4_DIR_REC_LEN(2)'. If
+the fs is mounted with errors=panic, it will trigger a panic issue.
+
+Add the check IS_DEADDIR() to fix this problem.
+
+Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
+Cc: <stable@vger.kernel.org> # v4.1+
+Signed-off-by: Hongjie Fang <hongjiefang@asrmicro.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/crypto/policy.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/crypto/policy.c
++++ b/fs/crypto/policy.c
+@@ -81,6 +81,8 @@ int fscrypt_ioctl_set_policy(struct file
+ if (ret == -ENODATA) {
+ if (!S_ISDIR(inode->i_mode))
+ ret = -ENOTDIR;
++ else if (IS_DEADDIR(inode))
++ ret = -ENOENT;
+ else if (!inode->i_sb->s_cop->empty_dir(inode))
+ ret = -ENOTEMPTY;
+ else
--- /dev/null
+From b09a2ab2baeb36bf7ef7780405ad172281741c7c Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Date: Tue, 25 Jun 2019 06:45:20 -0400
+Subject: media: stv0297: fix frequency range limit
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+
+commit b09a2ab2baeb36bf7ef7780405ad172281741c7c upstream.
+
+There was a typo at the lower frequency limit for a DVB-C
+card, causing the driver to fail while tuning channels at the
+VHF range.
+
+https://bugzilla.kernel.org/show_bug.cgi?id=202083
+
+Fixes: f1b1eabff0eb ("media: dvb: represent min/max/step/tolerance freqs in Hz")
+Reported-by: Ari Kohtamäki <ari.kohtamaki@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/dvb-frontends/stv0297.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/dvb-frontends/stv0297.c
++++ b/drivers/media/dvb-frontends/stv0297.c
+@@ -682,7 +682,7 @@ static const struct dvb_frontend_ops stv
+ .delsys = { SYS_DVBC_ANNEX_A },
+ .info = {
+ .name = "ST STV0297 DVB-C",
+- .frequency_min_hz = 470 * MHz,
++ .frequency_min_hz = 47 * MHz,
+ .frequency_max_hz = 862 * MHz,
+ .frequency_stepsize_hz = 62500,
+ .symbol_rate_min = 870000,
--- /dev/null
+From 355200e0f6a9ce14771625014aa469f5ecbd8977 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 20 May 2019 14:37:08 +0300
+Subject: perf auxtrace: Fix itrace defaults for perf script
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 355200e0f6a9ce14771625014aa469f5ecbd8977 upstream.
+
+Commit 4eb068157121 ("perf script: Make itrace script default to all
+calls") does not work for the case when '--itrace' only is used, because
+default_no_sample is not being passed.
+
+Example:
+
+ Before:
+
+ $ perf record -e intel_pt/cyc/u ls
+ $ perf script --itrace > cmp1.txt
+ $ perf script --itrace=cepwx > cmp2.txt
+ $ diff -sq cmp1.txt cmp2.txt
+ Files cmp1.txt and cmp2.txt differ
+
+ After:
+
+ $ perf script --itrace > cmp1.txt
+ $ perf script --itrace=cepwx > cmp2.txt
+ $ diff -sq cmp1.txt cmp2.txt
+ Files cmp1.txt and cmp2.txt are identical
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 4eb068157121 ("perf script: Make itrace script default to all calls")
+Link: http://lkml.kernel.org/r/20190520113728.14389-3-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/auxtrace.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/util/auxtrace.c
++++ b/tools/perf/util/auxtrace.c
+@@ -1001,7 +1001,8 @@ int itrace_parse_synth_opts(const struct
+ }
+
+ if (!str) {
+- itrace_synth_opts__set_default(synth_opts, false);
++ itrace_synth_opts__set_default(synth_opts,
++ synth_opts->default_no_sample);
+ return 0;
+ }
+
--- /dev/null
+From c952b35f4b15dd1b83e952718dec3307256383ef Mon Sep 17 00:00:00 2001
+From: Song Liu <songliubraving@fb.com>
+Date: Wed, 19 Jun 2019 18:04:53 -0700
+Subject: perf header: Assign proper ff->ph in perf_event__synthesize_features()
+
+From: Song Liu <songliubraving@fb.com>
+
+commit c952b35f4b15dd1b83e952718dec3307256383ef upstream.
+
+bpf/btf write_* functions need ff->ph->env.
+
+With this missing, pipe-mode (perf record -o -) would crash like:
+
+Program terminated with signal SIGSEGV, Segmentation fault.
+
+This patch assign proper ph value to ff.
+
+Committer testing:
+
+ (gdb) run record -o -
+ Starting program: /root/bin/perf record -o -
+ PERFILE2
+ <SNIP start of perf.data headers>
+ Thread 1 "perf" received signal SIGSEGV, Segmentation fault.
+ __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
+ 126 memcpy(ff->buf + ff->offset, buf, size);
+ (gdb) bt
+ #0 __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
+ #1 do_write (ff=ff@entry=0x7fffffff8f80, buf=buf@entry=0x160, size=4) at util/header.c:137
+ #2 0x00000000004eddba in write_bpf_prog_info (ff=0x7fffffff8f80, evlist=<optimized out>) at util/header.c:912
+ #3 0x00000000004f69d7 in perf_event__synthesize_features (tool=tool@entry=0x97cc00 <record>, session=session@entry=0x7fffe9c6d010,
+ evlist=0x7fffe9cae010, process=process@entry=0x4435d0 <process_synthesized_event>) at util/header.c:3695
+ #4 0x0000000000443c79 in record__synthesize (tail=tail@entry=false, rec=0x97cc00 <record>) at builtin-record.c:1214
+ #5 0x0000000000444ec9 in __cmd_record (rec=0x97cc00 <record>, argv=<optimized out>, argc=0) at builtin-record.c:1435
+ #6 cmd_record (argc=0, argv=<optimized out>) at builtin-record.c:2450
+ #7 0x00000000004ae3e9 in run_builtin (p=p@entry=0x98e058 <commands+216>, argc=argc@entry=3, argv=0x7fffffffd670) at perf.c:304
+ #8 0x000000000042eded in handle_internal_command (argv=<optimized out>, argc=<optimized out>) at perf.c:356
+ #9 run_argv (argcp=<optimized out>, argv=<optimized out>) at perf.c:400
+ #10 main (argc=3, argv=<optimized out>) at perf.c:522
+ (gdb)
+
+After the patch the SEGSEGV is gone.
+
+Reported-by: David Carrillo Cisneros <davidca@fb.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: kernel-team@fb.com
+Cc: stable@vger.kernel.org # v5.1+
+Fixes: 606f972b1361 ("perf bpf: Save bpf_prog_info information as headers to perf.data")
+Link: http://lkml.kernel.org/r/20190620010453.4118689-1-songliubraving@fb.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/header.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/perf/util/header.c
++++ b/tools/perf/util/header.c
+@@ -3602,6 +3602,7 @@ int perf_event__synthesize_features(stru
+ return -ENOMEM;
+
+ ff.size = sz - sz_hdr;
++ ff.ph = &session->header;
+
+ for_each_set_bit(feat, header->adds_features, HEADER_FEAT_BITS) {
+ if (!feat_ops[feat].synthesize) {
--- /dev/null
+From a2d8a1585e35444789c1c8cf7e2e51fb15589880 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 20 May 2019 14:37:09 +0300
+Subject: perf intel-pt: Fix itrace defaults for perf script intel-pt documentation
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit a2d8a1585e35444789c1c8cf7e2e51fb15589880 upstream.
+
+Fix intel-pt documentation to reflect the change of itrace defaults for
+perf script.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 4eb068157121 ("perf script: Make itrace script default to all calls")
+Link: http://lkml.kernel.org/r/20190520113728.14389-4-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/Documentation/intel-pt.txt | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/tools/perf/Documentation/intel-pt.txt
++++ b/tools/perf/Documentation/intel-pt.txt
+@@ -88,16 +88,16 @@ smaller.
+
+ To represent software control flow, "branches" samples are produced. By default
+ a branch sample is synthesized for every single branch. To get an idea what
+-data is available you can use the 'perf script' tool with no parameters, which
+-will list all the samples.
++data is available you can use the 'perf script' tool with all itrace sampling
++options, which will list all the samples.
+
+ perf record -e intel_pt//u ls
+- perf script
++ perf script --itrace=ibxwpe
+
+ An interesting field that is not printed by default is 'flags' which can be
+ displayed as follows:
+
+- perf script -Fcomm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,flags
++ perf script --itrace=ibxwpe -F+flags
+
+ The flags are "bcrosyiABEx" which stand for branch, call, return, conditional,
+ system, asynchronous, interrupt, transaction abort, trace begin, trace end, and
+@@ -713,7 +713,7 @@ Having no option is the same as
+
+ which, in turn, is the same as
+
+- --itrace=ibxwpe
++ --itrace=cepwx
+
+ The letters are:
+
--- /dev/null
+From 26f19c2eb7e54015564ff133b91983a74e84541b Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 20 May 2019 14:37:07 +0300
+Subject: perf intel-pt: Fix itrace defaults for perf script
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 26f19c2eb7e54015564ff133b91983a74e84541b upstream.
+
+Commit 4eb068157121 ("perf script: Make itrace script default to all
+calls") does not work because 'use_browser' is being used to determine
+whether to default to periodic sampling (i.e. better for perf report).
+The result is that nothing but CBR events display for perf script when
+no --itrace option is specified.
+
+Fix by using 'default_no_sample' and 'inject' instead.
+
+Example:
+
+ Before:
+
+ $ perf record -e intel_pt/cyc/u ls
+ $ perf script > cmp1.txt
+ $ perf script --itrace=cepwx > cmp2.txt
+ $ diff -sq cmp1.txt cmp2.txt
+ Files cmp1.txt and cmp2.txt differ
+
+ After:
+
+ $ perf script > cmp1.txt
+ $ perf script --itrace=cepwx > cmp2.txt
+ $ diff -sq cmp1.txt cmp2.txt
+ Files cmp1.txt and cmp2.txt are identical
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org # v4.20+
+Fixes: 90e457f7be08 ("perf tools: Add Intel PT support")
+Link: http://lkml.kernel.org/r/20190520113728.14389-2-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/util/intel-pt.c
++++ b/tools/perf/util/intel-pt.c
+@@ -2579,7 +2579,8 @@ int intel_pt_process_auxtrace_info(union
+ } else {
+ itrace_synth_opts__set_default(&pt->synth_opts,
+ session->itrace_synth_opts->default_no_sample);
+- if (use_browser != -1) {
++ if (!session->itrace_synth_opts->default_no_sample &&
++ !session->itrace_synth_opts->inject) {
+ pt->synth_opts.branches = false;
+ pt->synth_opts.callchain = true;
+ }
--- /dev/null
+From 599ee18f0740d7661b8711249096db94c09bc508 Mon Sep 17 00:00:00 2001
+From: John Garry <john.garry@huawei.com>
+Date: Fri, 14 Jun 2019 22:07:59 +0800
+Subject: perf pmu: Fix uncore PMU alias list for ARM64
+
+From: John Garry <john.garry@huawei.com>
+
+commit 599ee18f0740d7661b8711249096db94c09bc508 upstream.
+
+In commit 292c34c10249 ("perf pmu: Fix core PMU alias list for X86
+platform"), we fixed the issue of CPU events being aliased to uncore
+events.
+
+Fix this same issue for ARM64, since the said commit left the (broken)
+behaviour untouched for ARM64.
+
+Signed-off-by: John Garry <john.garry@huawei.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Kan Liang <kan.liang@linux.intel.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
+Cc: Thomas Richter <tmricht@linux.ibm.com>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linuxarm@huawei.com
+Cc: stable@vger.kernel.org
+Fixes: 292c34c10249 ("perf pmu: Fix core PMU alias list for X86 platform")
+Link: http://lkml.kernel.org/r/1560521283-73314-2-git-send-email-john.garry@huawei.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/pmu.c | 28 ++++++++++++----------------
+ 1 file changed, 12 insertions(+), 16 deletions(-)
+
+--- a/tools/perf/util/pmu.c
++++ b/tools/perf/util/pmu.c
+@@ -709,9 +709,7 @@ static void pmu_add_cpu_aliases(struct l
+ {
+ int i;
+ struct pmu_events_map *map;
+- struct pmu_event *pe;
+ const char *name = pmu->name;
+- const char *pname;
+
+ map = perf_pmu__find_map(pmu);
+ if (!map)
+@@ -722,28 +720,26 @@ static void pmu_add_cpu_aliases(struct l
+ */
+ i = 0;
+ while (1) {
++ const char *cpu_name = is_arm_pmu_core(name) ? name : "cpu";
++ struct pmu_event *pe = &map->table[i++];
++ const char *pname = pe->pmu ? pe->pmu : cpu_name;
+
+- pe = &map->table[i++];
+ if (!pe->name) {
+ if (pe->metric_group || pe->metric_name)
+ continue;
+ break;
+ }
+
+- if (!is_arm_pmu_core(name)) {
+- pname = pe->pmu ? pe->pmu : "cpu";
++ /*
++ * uncore alias may be from different PMU
++ * with common prefix
++ */
++ if (pmu_is_uncore(name) &&
++ !strncmp(pname, name, strlen(pname)))
++ goto new_alias;
+
+- /*
+- * uncore alias may be from different PMU
+- * with common prefix
+- */
+- if (pmu_is_uncore(name) &&
+- !strncmp(pname, name, strlen(pname)))
+- goto new_alias;
+-
+- if (strcmp(pname, name))
+- continue;
+- }
++ if (strcmp(pname, name))
++ continue;
+
+ new_alias:
+ /* need type casts to override 'const' */
--- /dev/null
+From 97860b483c5597663a174ff7405be957b4838391 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 19 Jun 2019 09:44:28 +0300
+Subject: perf thread-stack: Fix thread stack return from kernel for kernel-only case
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 97860b483c5597663a174ff7405be957b4838391 upstream.
+
+Commit f08046cb3082 ("perf thread-stack: Represent jmps to the start of a
+different symbol") had the side-effect of introducing more stack entries
+before return from kernel space.
+
+When user space is also traced, those entries are popped before entry to
+user space, but when user space is not traced, they get stuck at the
+bottom of the stack, making the stack grow progressively larger.
+
+Fix by detecting a return-from-kernel branch type, and popping kernel
+addresses from the stack then.
+
+Note, the problem and fix affect the exported Call Graph / Tree but not
+the callindent option used by "perf script --call-trace".
+
+Example:
+
+ perf-with-kcore record example -e intel_pt//k -- ls
+ perf-with-kcore script example --itrace=bep -s ~/libexec/perf-core/scripts/python/export-to-sqlite.py example.db branches calls
+ ~/libexec/perf-core/scripts/python/exported-sql-viewer.py example.db
+
+ Menu option: Reports -> Context-Sensitive Call Graph
+
+ Before: (showing Call Path column only)
+
+ Call Path
+ â–¶ perf
+ â–¼ ls
+ â–¼ 12111:12111
+ â–¶ setup_new_exec
+ â–¶ __task_pid_nr_ns
+ â–¶ perf_event_pid_type
+ â–¶ perf_event_comm_output
+ â–¶ perf_iterate_ctx
+ â–¶ perf_iterate_sb
+ â–¶ perf_event_comm
+ â–¶ __set_task_comm
+ â–¶ load_elf_binary
+ â–¶ search_binary_handler
+ â–¶ __do_execve_file.isra.41
+ â–¶ __x64_sys_execve
+ â–¶ do_syscall_64
+ â–¼ entry_SYSCALL_64_after_hwframe
+ â–¼ swapgs_restore_regs_and_return_to_usermode
+ â–¼ native_iret
+ â–¶ error_entry
+ â–¶ do_page_fault
+ â–¼ error_exit
+ â–¼ retint_user
+ â–¶ prepare_exit_to_usermode
+ â–¼ native_iret
+ â–¶ error_entry
+ â–¶ do_page_fault
+ â–¼ error_exit
+ â–¼ retint_user
+ â–¶ prepare_exit_to_usermode
+ â–¼ native_iret
+ â–¶ error_entry
+ â–¶ do_page_fault
+ â–¼ error_exit
+ â–¼ retint_user
+ â–¶ prepare_exit_to_usermode
+ â–¶ native_iret
+
+ After: (showing Call Path column only)
+
+ Call Path
+ â–¶ perf
+ â–¼ ls
+ â–¼ 12111:12111
+ â–¶ setup_new_exec
+ â–¶ __task_pid_nr_ns
+ â–¶ perf_event_pid_type
+ â–¶ perf_event_comm_output
+ â–¶ perf_iterate_ctx
+ â–¶ perf_iterate_sb
+ â–¶ perf_event_comm
+ â–¶ __set_task_comm
+ â–¶ load_elf_binary
+ â–¶ search_binary_handler
+ â–¶ __do_execve_file.isra.41
+ â–¶ __x64_sys_execve
+ â–¶ do_syscall_64
+ â–¶ entry_SYSCALL_64_after_hwframe
+ â–¶ page_fault
+ â–¼ entry_SYSCALL_64
+ â–¼ do_syscall_64
+ â–¶ __x64_sys_brk
+ â–¶ __x64_sys_access
+ â–¶ __x64_sys_openat
+ â–¶ __x64_sys_newfstat
+ â–¶ __x64_sys_mmap
+ â–¶ __x64_sys_close
+ â–¶ __x64_sys_read
+ â–¶ __x64_sys_mprotect
+ â–¶ __x64_sys_arch_prctl
+ â–¶ __x64_sys_munmap
+ â–¶ exit_to_usermode_loop
+ â–¶ __x64_sys_set_tid_address
+ â–¶ __x64_sys_set_robust_list
+ â–¶ __x64_sys_rt_sigaction
+ â–¶ __x64_sys_rt_sigprocmask
+ â–¶ __x64_sys_prlimit64
+ â–¶ __x64_sys_statfs
+ â–¶ __x64_sys_ioctl
+ â–¶ __x64_sys_getdents64
+ â–¶ __x64_sys_write
+ â–¶ __x64_sys_exit_group
+
+Committer notes:
+
+The first arg to the perf-with-kcore needs to be the same for the
+'record' and 'script' lines, otherwise we'll record the perf.data file
+and kcore_dir/ files in one directory ('example') to then try to use it
+from the 'bep' directory, fix the instructions above it so that both use
+'example'.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: f08046cb3082 ("perf thread-stack: Represent jmps to the start of a different symbol")
+Link: http://lkml.kernel.org/r/20190619064429.14940-2-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/thread-stack.c | 30 +++++++++++++++++++++++++++++-
+ 1 file changed, 29 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/util/thread-stack.c
++++ b/tools/perf/util/thread-stack.c
+@@ -616,6 +616,23 @@ static int thread_stack__bottom(struct t
+ true, false);
+ }
+
++static int thread_stack__pop_ks(struct thread *thread, struct thread_stack *ts,
++ struct perf_sample *sample, u64 ref)
++{
++ u64 tm = sample->time;
++ int err;
++
++ /* Return to userspace, so pop all kernel addresses */
++ while (thread_stack__in_kernel(ts)) {
++ err = thread_stack__call_return(thread, ts, --ts->cnt,
++ tm, ref, true);
++ if (err)
++ return err;
++ }
++
++ return 0;
++}
++
+ static int thread_stack__no_call_return(struct thread *thread,
+ struct thread_stack *ts,
+ struct perf_sample *sample,
+@@ -896,7 +913,18 @@ int thread_stack__process(struct thread
+ ts->rstate = X86_RETPOLINE_DETECTED;
+
+ } else if (sample->flags & PERF_IP_FLAG_RETURN) {
+- if (!sample->ip || !sample->addr)
++ if (!sample->addr) {
++ u32 return_from_kernel = PERF_IP_FLAG_SYSCALLRET |
++ PERF_IP_FLAG_INTERRUPT;
++
++ if (!(sample->flags & return_from_kernel))
++ return 0;
++
++ /* Pop kernel stack */
++ return thread_stack__pop_ks(thread, ts, sample, ref);
++ }
++
++ if (!sample->ip)
+ return 0;
+
+ /* x86 retpoline 'return' doesn't match the stack */
crypto-talitos-fix-hash-on-sec1.patch
crypto-lrw-use-correct-alignmask.patch
crypto-talitos-rename-alternative-aead-algos.patch
+fscrypt-don-t-set-policy-for-a-dead-directory.patch
+udf-fix-incorrect-final-not_allocated-hole-extent-length.patch
+media-stv0297-fix-frequency-range-limit.patch
+alsa-usb-audio-fix-parse-of-uac2-extension-units.patch
+alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch
+tpm-actually-fail-on-tpm-errors-during-get-random.patch
+tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch
+block-fix-.bi_size-overflow.patch
+block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch
+perf-intel-pt-fix-itrace-defaults-for-perf-script.patch
+perf-auxtrace-fix-itrace-defaults-for-perf-script.patch
+perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch
+perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch
+perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch
+perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch
+x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch
+x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch
+documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch
+documentation-admin-remove-the-vsyscall-native-documentation.patch
--- /dev/null
+From 782779b60faa2fc7ff609ac8ef938260fd792c0f Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Mon, 1 Apr 2019 12:06:07 -0700
+Subject: tpm: Actually fail on TPM errors during "get random"
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 782779b60faa2fc7ff609ac8ef938260fd792c0f upstream.
+
+A "get random" may fail with a TPM error, but those codes were returned
+as-is to the caller, which assumed the result was the number of bytes
+that had been written to the target buffer, which could lead to a kernel
+heap memory exposure and over-read.
+
+This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as
+before.
+
+[ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random
+[ 18.092106] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-64' (offset 0, size 379)!
+
+Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989
+Reported-by: Phil Baker <baker1tex@gmail.com>
+Reported-by: Craig Robson <craig@zhatt.com>
+Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure")
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Tomas Winkler <tomas.winkler@intel.com>
+Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>
+Tested-by: Bartosz Szczepanek <bsz@semihalf.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm1-cmd.c | 7 +++++--
+ drivers/char/tpm/tpm2-cmd.c | 7 +++++--
+ 2 files changed, 10 insertions(+), 4 deletions(-)
+
+--- a/drivers/char/tpm/tpm1-cmd.c
++++ b/drivers/char/tpm/tpm1-cmd.c
+@@ -510,7 +510,7 @@ struct tpm1_get_random_out {
+ *
+ * Return:
+ * * number of bytes read
+- * * -errno or a TPM return code otherwise
++ * * -errno (positive TPM return codes are masked to -EIO)
+ */
+ int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
+ {
+@@ -531,8 +531,11 @@ int tpm1_get_random(struct tpm_chip *chi
+
+ rc = tpm_transmit_cmd(chip, &buf, sizeof(out->rng_data_len),
+ "attempting get random");
+- if (rc)
++ if (rc) {
++ if (rc > 0)
++ rc = -EIO;
+ goto out;
++ }
+
+ out = (struct tpm1_get_random_out *)&buf.data[TPM_HEADER_SIZE];
+
+--- a/drivers/char/tpm/tpm2-cmd.c
++++ b/drivers/char/tpm/tpm2-cmd.c
+@@ -297,7 +297,7 @@ struct tpm2_get_random_out {
+ *
+ * Return:
+ * size of the buffer on success,
+- * -errno otherwise
++ * -errno otherwise (positive TPM return codes are masked to -EIO)
+ */
+ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
+ {
+@@ -324,8 +324,11 @@ int tpm2_get_random(struct tpm_chip *chi
+ offsetof(struct tpm2_get_random_out,
+ buffer),
+ "attempting get random");
+- if (err)
++ if (err) {
++ if (err > 0)
++ err = -EIO;
+ goto out;
++ }
+
+ out = (struct tpm2_get_random_out *)
+ &buf.data[TPM_HEADER_SIZE];
--- /dev/null
+From db4d8cb9c9f2af71c4d087817160d866ed572cc9 Mon Sep 17 00:00:00 2001
+From: Vadim Sukhomlinov <sukhomlinov@google.com>
+Date: Mon, 10 Jun 2019 15:01:18 -0700
+Subject: tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
+
+From: Vadim Sukhomlinov <sukhomlinov@google.com>
+
+commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream.
+
+TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and disabling
+future TPM operations. TPM 1.2 behavior was different, future TPM
+operations weren't disabled, causing rare issues. This patch ensures
+that future TPM operations are disabled.
+
+Fixes: d1bd4a792d39 ("tpm: Issue a TPM2_Shutdown for TPM2 devices.")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vadim Sukhomlinov <sukhomlinov@google.com>
+[dianders: resolved merge conflicts with mainline]
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm-chip.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/char/tpm/tpm-chip.c
++++ b/drivers/char/tpm/tpm-chip.c
+@@ -289,15 +289,15 @@ static int tpm_class_shutdown(struct dev
+ {
+ struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
+
++ down_write(&chip->ops_sem);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+- down_write(&chip->ops_sem);
+ if (!tpm_chip_start(chip)) {
+ tpm2_shutdown(chip, TPM2_SU_CLEAR);
+ tpm_chip_stop(chip);
+ }
+- chip->ops = NULL;
+- up_write(&chip->ops_sem);
+ }
++ chip->ops = NULL;
++ up_write(&chip->ops_sem);
+
+ return 0;
+ }
--- /dev/null
+From fa33cdbf3eceb0206a4f844fe91aeebcf6ff2b7a Mon Sep 17 00:00:00 2001
+From: "Steven J. Magnani" <steve.magnani@digidescorp.com>
+Date: Sun, 30 Jun 2019 21:39:35 -0500
+Subject: udf: Fix incorrect final NOT_ALLOCATED (hole) extent length
+
+From: Steven J. Magnani <steve.magnani@digidescorp.com>
+
+commit fa33cdbf3eceb0206a4f844fe91aeebcf6ff2b7a upstream.
+
+In some cases, using the 'truncate' command to extend a UDF file results
+in a mismatch between the length of the file's extents (specifically, due
+to incorrect length of the final NOT_ALLOCATED extent) and the information
+(file) length. The discrepancy can prevent other operating systems
+(i.e., Windows 10) from opening the file.
+
+Two particular errors have been observed when extending a file:
+
+1. The final extent is larger than it should be, having been rounded up
+ to a multiple of the block size.
+
+B. The final extent is not shorter than it should be, due to not having
+ been updated when the file's information length was increased.
+
+[JK: simplified udf_do_extend_final_block(), fixed up some types]
+
+Fixes: 2c948b3f86e5 ("udf: Avoid IO in udf_clear_inode")
+CC: stable@vger.kernel.org
+Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
+Link: https://lore.kernel.org/r/1561948775-5878-1-git-send-email-steve@digidescorp.com
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/udf/inode.c | 93 ++++++++++++++++++++++++++++++++++++---------------------
+ 1 file changed, 60 insertions(+), 33 deletions(-)
+
+--- a/fs/udf/inode.c
++++ b/fs/udf/inode.c
+@@ -470,13 +470,15 @@ static struct buffer_head *udf_getblk(st
+ return NULL;
+ }
+
+-/* Extend the file by 'blocks' blocks, return the number of extents added */
++/* Extend the file with new blocks totaling 'new_block_bytes',
++ * return the number of extents added
++ */
+ static int udf_do_extend_file(struct inode *inode,
+ struct extent_position *last_pos,
+ struct kernel_long_ad *last_ext,
+- sector_t blocks)
++ loff_t new_block_bytes)
+ {
+- sector_t add;
++ uint32_t add;
+ int count = 0, fake = !(last_ext->extLength & UDF_EXTENT_LENGTH_MASK);
+ struct super_block *sb = inode->i_sb;
+ struct kernel_lb_addr prealloc_loc = {};
+@@ -486,7 +488,7 @@ static int udf_do_extend_file(struct ino
+
+ /* The previous extent is fake and we should not extend by anything
+ * - there's nothing to do... */
+- if (!blocks && fake)
++ if (!new_block_bytes && fake)
+ return 0;
+
+ iinfo = UDF_I(inode);
+@@ -517,13 +519,12 @@ static int udf_do_extend_file(struct ino
+ /* Can we merge with the previous extent? */
+ if ((last_ext->extLength & UDF_EXTENT_FLAG_MASK) ==
+ EXT_NOT_RECORDED_NOT_ALLOCATED) {
+- add = ((1 << 30) - sb->s_blocksize -
+- (last_ext->extLength & UDF_EXTENT_LENGTH_MASK)) >>
+- sb->s_blocksize_bits;
+- if (add > blocks)
+- add = blocks;
+- blocks -= add;
+- last_ext->extLength += add << sb->s_blocksize_bits;
++ add = (1 << 30) - sb->s_blocksize -
++ (last_ext->extLength & UDF_EXTENT_LENGTH_MASK);
++ if (add > new_block_bytes)
++ add = new_block_bytes;
++ new_block_bytes -= add;
++ last_ext->extLength += add;
+ }
+
+ if (fake) {
+@@ -544,28 +545,27 @@ static int udf_do_extend_file(struct ino
+ }
+
+ /* Managed to do everything necessary? */
+- if (!blocks)
++ if (!new_block_bytes)
+ goto out;
+
+ /* All further extents will be NOT_RECORDED_NOT_ALLOCATED */
+ last_ext->extLocation.logicalBlockNum = 0;
+ last_ext->extLocation.partitionReferenceNum = 0;
+- add = (1 << (30-sb->s_blocksize_bits)) - 1;
+- last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
+- (add << sb->s_blocksize_bits);
++ add = (1 << 30) - sb->s_blocksize;
++ last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED | add;
+
+ /* Create enough extents to cover the whole hole */
+- while (blocks > add) {
+- blocks -= add;
++ while (new_block_bytes > add) {
++ new_block_bytes -= add;
+ err = udf_add_aext(inode, last_pos, &last_ext->extLocation,
+ last_ext->extLength, 1);
+ if (err)
+ return err;
+ count++;
+ }
+- if (blocks) {
++ if (new_block_bytes) {
+ last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
+- (blocks << sb->s_blocksize_bits);
++ new_block_bytes;
+ err = udf_add_aext(inode, last_pos, &last_ext->extLocation,
+ last_ext->extLength, 1);
+ if (err)
+@@ -596,6 +596,24 @@ out:
+ return count;
+ }
+
++/* Extend the final block of the file to final_block_len bytes */
++static void udf_do_extend_final_block(struct inode *inode,
++ struct extent_position *last_pos,
++ struct kernel_long_ad *last_ext,
++ uint32_t final_block_len)
++{
++ struct super_block *sb = inode->i_sb;
++ uint32_t added_bytes;
++
++ added_bytes = final_block_len -
++ (last_ext->extLength & (sb->s_blocksize - 1));
++ last_ext->extLength += added_bytes;
++ UDF_I(inode)->i_lenExtents += added_bytes;
++
++ udf_write_aext(inode, last_pos, &last_ext->extLocation,
++ last_ext->extLength, 1);
++}
++
+ static int udf_extend_file(struct inode *inode, loff_t newsize)
+ {
+
+@@ -605,10 +623,12 @@ static int udf_extend_file(struct inode
+ int8_t etype;
+ struct super_block *sb = inode->i_sb;
+ sector_t first_block = newsize >> sb->s_blocksize_bits, offset;
++ unsigned long partial_final_block;
+ int adsize;
+ struct udf_inode_info *iinfo = UDF_I(inode);
+ struct kernel_long_ad extent;
+- int err;
++ int err = 0;
++ int within_final_block;
+
+ if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_SHORT)
+ adsize = sizeof(struct short_ad);
+@@ -618,18 +638,8 @@ static int udf_extend_file(struct inode
+ BUG();
+
+ etype = inode_bmap(inode, first_block, &epos, &eloc, &elen, &offset);
++ within_final_block = (etype != -1);
+
+- /* File has extent covering the new size (could happen when extending
+- * inside a block)? */
+- if (etype != -1)
+- return 0;
+- if (newsize & (sb->s_blocksize - 1))
+- offset++;
+- /* Extended file just to the boundary of the last file block? */
+- if (offset == 0)
+- return 0;
+-
+- /* Truncate is extending the file by 'offset' blocks */
+ if ((!epos.bh && epos.offset == udf_file_entry_alloc_offset(inode)) ||
+ (epos.bh && epos.offset == sizeof(struct allocExtDesc))) {
+ /* File has no extents at all or has empty last
+@@ -643,7 +653,22 @@ static int udf_extend_file(struct inode
+ &extent.extLength, 0);
+ extent.extLength |= etype << 30;
+ }
+- err = udf_do_extend_file(inode, &epos, &extent, offset);
++
++ partial_final_block = newsize & (sb->s_blocksize - 1);
++
++ /* File has extent covering the new size (could happen when extending
++ * inside a block)?
++ */
++ if (within_final_block) {
++ /* Extending file within the last file block */
++ udf_do_extend_final_block(inode, &epos, &extent,
++ partial_final_block);
++ } else {
++ loff_t add = ((loff_t)offset << sb->s_blocksize_bits) |
++ partial_final_block;
++ err = udf_do_extend_file(inode, &epos, &extent, add);
++ }
++
+ if (err < 0)
+ goto out;
+ err = 0;
+@@ -745,6 +770,7 @@ static sector_t inode_getblk(struct inod
+ /* Are we beyond EOF? */
+ if (etype == -1) {
+ int ret;
++ loff_t hole_len;
+ isBeyondEOF = true;
+ if (count) {
+ if (c)
+@@ -760,7 +786,8 @@ static sector_t inode_getblk(struct inod
+ startnum = (offset > 0);
+ }
+ /* Create extents for the hole between EOF and offset */
+- ret = udf_do_extend_file(inode, &prev_epos, laarr, offset);
++ hole_len = (loff_t)offset << inode->i_blkbits;
++ ret = udf_do_extend_file(inode, &prev_epos, laarr, hole_len);
+ if (ret < 0) {
+ *err = ret;
+ newblock = 0;
--- /dev/null
+From 31a2fbb390fee4231281b939e1979e810f945415 Mon Sep 17 00:00:00 2001
+From: Dianzhang Chen <dianzhangchen0@gmail.com>
+Date: Tue, 25 Jun 2019 23:30:17 +0800
+Subject: x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg()
+
+From: Dianzhang Chen <dianzhangchen0@gmail.com>
+
+commit 31a2fbb390fee4231281b939e1979e810f945415 upstream.
+
+The index to access the threads ptrace_bps is controlled by userspace via
+syscall: sys_ptrace(), hence leading to a potential exploitation of the
+Spectre variant 1 vulnerability.
+
+The index can be controlled from:
+ ptrace -> arch_ptrace -> ptrace_get_debugreg.
+
+Fix this by sanitizing the user supplied index before using it access
+thread->ptrace_bps.
+
+Signed-off-by: Dianzhang Chen <dianzhangchen0@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: bp@alien8.de
+Cc: hpa@zytor.com
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/1561476617-3759-1-git-send-email-dianzhangchen0@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ptrace.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/ptrace.c
++++ b/arch/x86/kernel/ptrace.c
+@@ -25,6 +25,7 @@
+ #include <linux/rcupdate.h>
+ #include <linux/export.h>
+ #include <linux/context_tracking.h>
++#include <linux/nospec.h>
+
+ #include <linux/uaccess.h>
+ #include <asm/pgtable.h>
+@@ -643,9 +644,11 @@ static unsigned long ptrace_get_debugreg
+ {
+ struct thread_struct *thread = &tsk->thread;
+ unsigned long val = 0;
++ int index = n;
+
+ if (n < HBP_NUM) {
+- struct perf_event *bp = thread->ptrace_bps[n];
++ index = array_index_nospec(index, HBP_NUM);
++ struct perf_event *bp = thread->ptrace_bps[index];
+
+ if (bp)
+ val = bp->hw.info.address;
--- /dev/null
+From 993773d11d45c90cb1c6481c2638c3d9f092ea5b Mon Sep 17 00:00:00 2001
+From: Dianzhang Chen <dianzhangchen0@gmail.com>
+Date: Wed, 26 Jun 2019 12:50:30 +0800
+Subject: x86/tls: Fix possible spectre-v1 in do_get_thread_area()
+
+From: Dianzhang Chen <dianzhangchen0@gmail.com>
+
+commit 993773d11d45c90cb1c6481c2638c3d9f092ea5b upstream.
+
+The index to access the threads tls array is controlled by userspace
+via syscall: sys_ptrace(), hence leading to a potential exploitation
+of the Spectre variant 1 vulnerability.
+
+The index can be controlled from:
+ ptrace -> arch_ptrace -> do_get_thread_area.
+
+Fix this by sanitizing the user supplied index before using it to access
+the p->thread.tls_array.
+
+Signed-off-by: Dianzhang Chen <dianzhangchen0@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: bp@alien8.de
+Cc: hpa@zytor.com
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/1561524630-3642-1-git-send-email-dianzhangchen0@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/tls.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/tls.c
++++ b/arch/x86/kernel/tls.c
+@@ -5,6 +5,7 @@
+ #include <linux/user.h>
+ #include <linux/regset.h>
+ #include <linux/syscalls.h>
++#include <linux/nospec.h>
+
+ #include <linux/uaccess.h>
+ #include <asm/desc.h>
+@@ -220,6 +221,7 @@ int do_get_thread_area(struct task_struc
+ struct user_desc __user *u_info)
+ {
+ struct user_desc info;
++ int index;
+
+ if (idx == -1 && get_user(idx, &u_info->entry_number))
+ return -EFAULT;
+@@ -227,8 +229,11 @@ int do_get_thread_area(struct task_struc
+ if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
+ return -EINVAL;
+
+- fill_user_desc(&info, idx,
+- &p->thread.tls_array[idx - GDT_ENTRY_TLS_MIN]);
++ index = idx - GDT_ENTRY_TLS_MIN;
++ index = array_index_nospec(index,
++ GDT_ENTRY_TLS_MAX - GDT_ENTRY_TLS_MIN + 1);
++
++ fill_user_desc(&info, idx, &p->thread.tls_array[index]);
+
+ if (copy_to_user(u_info, &info, sizeof(info)))
+ return -EFAULT;
projects / thirdparty / kernel / stable-queue.git / commitdiff
