1. 17 Aug, 2018 14 commits
    • Chintan Pandya's avatar
      ioremap: Update pgtable free interfaces with addr · 6e6b6377
      Chintan Pandya authored
      commit 785a19f9 upstream.
      
      The following kernel panic was observed on ARM64 platform due to a stale
      TLB entry.
      
       1. ioremap with 4K size, a valid pte page table is set.
       2. iounmap it, its pte entry is set to 0.
       3. ioremap the same address with 2M size, update its pmd entry with
          a new value.
       4. CPU may hit an exception because the old pmd entry is still in TLB,
          which leads to a kernel panic.
      
      Commit b6bdb751 ("mm/vmalloc: add interfaces to free unmapped page
      table") has addressed this panic by falling to pte mappings in the above
      case on ARM64.
      
      To support pmd mappings in all cases, TLB purge needs to be performed
      in this case on ARM64.
      
      Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
      so that TLB purge can be added later in seprate patches.
      
      [toshi.kani@hpe.com: merge changes, rewrite patch description]
      Fixes: 28ee90fe ("x86/mm: implement free pmd/pte page interfaces")
      Signed-off-by: default avatarChintan Pandya <cpandya@codeaurora.org>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: mhocko@suse.com
      Cc: akpm@linux-foundation.org
      Cc: hpa@zytor.com
      Cc: linux-mm@kvack.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: stable@vger.kernel.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20180627141348.21777-3-toshi.kani@hpe.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e6b6377
    • Mark Salyzyn's avatar
      Bluetooth: hidp: buffer overflow in hidp_process_report · 7c7940ff
      Mark Salyzyn authored
      commit 7992c188 upstream.
      
      CVE-2018-9363
      
      The buffer length is unsigned at all layers, but gets cast to int and
      checked in hidp_process_report and can lead to a buffer overflow.
      Switch len parameter to unsigned int to resolve issue.
      
      This affects 3.18 and newer kernels.
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Fixes: a4b1b587 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: security@kernel.org
      Cc: kernel-team@android.com
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c7940ff
    • Thierry Escande's avatar
      ASoC: Intel: cht_bsw_max98090_ti: Fix jack initialization · 5daf2471
      Thierry Escande authored
      commit 3bbda5a3 upstream.
      
      If the ts3a227e audio accessory detection hardware is present and its
      driver probed, the jack needs to be created before enabling jack
      detection in the ts3a227e driver. With this patch, the jack is
      instantiated in the max98090 headset init function if the ts3a227e is
      present. This fixes a null pointer dereference as the jack detection
      enabling function in the ts3a driver was called before the jack is
      created.
      
      [minor correction to keep error handling on jack creation the same
      as before by Pierre Bossart]
      Signed-off-by: default avatarThierry Escande <thierry.escande@collabora.com>
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Acked-By: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5daf2471
    • Eric Biggers's avatar
      crypto: ablkcipher - fix crash flushing dcache in error path · b7c2b699
      Eric Biggers authored
      commit 318abdfb upstream.
      
      Like the skcipher_walk and blkcipher_walk cases:
      
      scatterwalk_done() is only meant to be called after a nonzero number of
      bytes have been processed, since scatterwalk_pagedone() will flush the
      dcache of the *previous* page.  But in the error case of
      ablkcipher_walk_done(), e.g. if the input wasn't an integer number of
      blocks, scatterwalk_done() was actually called after advancing 0 bytes.
      This caused a crash ("BUG: unable to handle kernel paging request")
      during '!PageSlab(page)' on architectures like arm and arm64 that define
      ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE, provided that the input was
      page-aligned as in that case walk->offset == 0.
      
      Fix it by reorganizing ablkcipher_walk_done() to skip the
      scatterwalk_advance() and scatterwalk_done() if an error has occurred.
      Reported-by: default avatarLiu Chao <liuchao741@huawei.com>
      Fixes: bf06099d ("crypto: skcipher - Add ablkcipher_walk interfaces")
      Cc: <stable@vger.kernel.org> # v2.6.35+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7c2b699
    • Eric Biggers's avatar
      crypto: blkcipher - fix crash flushing dcache in error path · afd5c42d
      Eric Biggers authored
      commit 0868def3 upstream.
      
      Like the skcipher_walk case:
      
      scatterwalk_done() is only meant to be called after a nonzero number of
      bytes have been processed, since scatterwalk_pagedone() will flush the
      dcache of the *previous* page.  But in the error case of
      blkcipher_walk_done(), e.g. if the input wasn't an integer number of
      blocks, scatterwalk_done() was actually called after advancing 0 bytes.
      This caused a crash ("BUG: unable to handle kernel paging request")
      during '!PageSlab(page)' on architectures like arm and arm64 that define
      ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE, provided that the input was
      page-aligned as in that case walk->offset == 0.
      
      Fix it by reorganizing blkcipher_walk_done() to skip the
      scatterwalk_advance() and scatterwalk_done() if an error has occurred.
      
      This bug was found by syzkaller fuzzing.
      
      Reproducer, assuming ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE:
      
      	#include <linux/if_alg.h>
      	#include <sys/socket.h>
      	#include <unistd.h>
      
      	int main()
      	{
      		struct sockaddr_alg addr = {
      			.salg_type = "skcipher",
      			.salg_name = "ecb(aes-generic)",
      		};
      		char buffer[4096] __attribute__((aligned(4096))) = { 0 };
      		int fd;
      
      		fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
      		bind(fd, (void *)&addr, sizeof(addr));
      		setsockopt(fd, SOL_ALG, ALG_SET_KEY, buffer, 16);
      		fd = accept(fd, NULL, NULL);
      		write(fd, buffer, 15);
      		read(fd, buffer, 15);
      	}
      Reported-by: default avatarLiu Chao <liuchao741@huawei.com>
      Fixes: 5cde0af2 ("[CRYPTO] cipher: Added block cipher type")
      Cc: <stable@vger.kernel.org> # v2.6.19+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afd5c42d
    • Eric Biggers's avatar
      crypto: vmac - separate tfm and request context · 81ad8a8e
      Eric Biggers authored
      commit bb296481 upstream.
      
      syzbot reported a crash in vmac_final() when multiple threads
      concurrently use the same "vmac(aes)" transform through AF_ALG.  The bug
      is pretty fundamental: the VMAC template doesn't separate per-request
      state from per-tfm (per-key) state like the other hash algorithms do,
      but rather stores it all in the tfm context.  That's wrong.
      
      Also, vmac_final() incorrectly zeroes most of the state including the
      derived keys and cached pseudorandom pad.  Therefore, only the first
      VMAC invocation with a given key calculates the correct digest.
      
      Fix these bugs by splitting the per-tfm state from the per-request state
      and using the proper init/update/final sequencing for requests.
      
      Reproducer for the crash:
      
          #include <linux/if_alg.h>
          #include <sys/socket.h>
          #include <unistd.h>
      
          int main()
          {
                  int fd;
                  struct sockaddr_alg addr = {
                          .salg_type = "hash",
                          .salg_name = "vmac(aes)",
                  };
                  char buf[256] = { 0 };
      
                  fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
                  bind(fd, (void *)&addr, sizeof(addr));
                  setsockopt(fd, SOL_ALG, ALG_SET_KEY, buf, 16);
                  fork();
                  fd = accept(fd, NULL, NULL);
                  for (;;)
                          write(fd, buf, 256);
          }
      
      The immediate cause of the crash is that vmac_ctx_t.partial_size exceeds
      VMAC_NHBYTES, causing vmac_final() to memset() a negative length.
      
      Reported-by: syzbot+264bca3a6e8d645550d3@syzkaller.appspotmail.com
      Fixes: f1939f7c ("crypto: vmac - New hash algorithm for intel_txt support")
      Cc: <stable@vger.kernel.org> # v2.6.32+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81ad8a8e
    • Eric Biggers's avatar
      crypto: vmac - require a block cipher with 128-bit block size · 371c35cb
      Eric Biggers authored
      commit 73bf20ef upstream.
      
      The VMAC template assumes the block cipher has a 128-bit block size, but
      it failed to check for that.  Thus it was possible to instantiate it
      using a 64-bit block size cipher, e.g. "vmac(cast5)", causing
      uninitialized memory to be used.
      
      Add the needed check when instantiating the template.
      
      Fixes: f1939f7c ("crypto: vmac - New hash algorithm for intel_txt support")
      Cc: <stable@vger.kernel.org> # v2.6.32+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      371c35cb
    • Eric Biggers's avatar
      crypto: x86/sha256-mb - fix digest copy in sha256_mb_mgr_get_comp_job_avx2() · e87485a5
      Eric Biggers authored
      commit af839b4e upstream.
      
      There is a copy-paste error where sha256_mb_mgr_get_comp_job_avx2()
      copies the SHA-256 digest state from sha256_mb_mgr::args::digest to
      job_sha256::result_digest.  Consequently, the sha256_mb algorithm
      sometimes calculates the wrong digest.  Fix it.
      
      Reproducer using AF_ALG:
      
          #include <assert.h>
          #include <linux/if_alg.h>
          #include <stdio.h>
          #include <string.h>
          #include <sys/socket.h>
          #include <unistd.h>
      
          static const __u8 expected[32] =
              "\xad\x7f\xac\xb2\x58\x6f\xc6\xe9\x66\xc0\x04\xd7\xd1\xd1\x6b\x02"
              "\x4f\x58\x05\xff\x7c\xb4\x7c\x7a\x85\xda\xbd\x8b\x48\x89\x2c\xa7";
      
          int main()
          {
              int fd;
              struct sockaddr_alg addr = {
                  .salg_type = "hash",
                  .salg_name = "sha256_mb",
              };
              __u8 data[4096] = { 0 };
              __u8 digest[32];
              int ret;
              int i;
      
              fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
              bind(fd, (void *)&addr, sizeof(addr));
              fork();
              fd = accept(fd, 0, 0);
              do {
                  ret = write(fd, data, 4096);
                  assert(ret == 4096);
                  ret = read(fd, digest, 32);
                  assert(ret == 32);
              } while (memcmp(digest, expected, 32) == 0);
      
              printf("wrong digest: ");
              for (i = 0; i < 32; i++)
                  printf("%02x", digest[i]);
              printf("\n");
          }
      
      Output was:
      
          wrong digest: ad7facb2000000000000000000000000ffffffef7cb47c7a85dabd8b48892ca7
      
      Fixes: 172b1d6b ("crypto: sha256-mb - fix ctx pointer and digest copy")
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e87485a5
    • Randy Dunlap's avatar
      kbuild: verify that $DEPMOD is installed · 2d43ff0f
      Randy Dunlap authored
      commit 934193a6 upstream.
      
      Verify that 'depmod' ($DEPMOD) is installed.
      This is a partial revert of commit 620c231c
      ("kbuild: do not check for ancient modutils tools").
      
      Also update Documentation/process/changes.rst to refer to
      kmod instead of module-init-tools.
      
      Fixes kernel bugzilla #198965:
      https://bugzilla.kernel.org/show_bug.cgi?id=198965Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Chih-Wei Huang <cwhuang@linux.org.tw>
      Cc: stable@vger.kernel.org # any kernel since 2012
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d43ff0f
    • Liwei Song's avatar
      i2c: ismt: fix wrong device address when unmap the data buffer · 52b9b51a
      Liwei Song authored
      commit 17e83549 upstream.
      
      Fix the following kernel bug:
      
      kernel BUG at drivers/iommu/intel-iommu.c:3260!
      invalid opcode: 0000 [#5] PREEMPT SMP
      Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
      task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
      RIP: 0010:[<ffffffff8150a83b>]  [<ffffffff8150a83b>] intel_unmap+0x25b/0x260
      RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
      RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
      RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
      RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
      R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
      R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
      FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
      Stack:
       00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
       ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
       ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
      Call Trace:
       [<ffffffff8199867f>] ? printk+0x46/0x48
       [<ffffffff8150a86e>] intel_unmap_page+0xe/0x10
       [<ffffffffa039d99b>] ismt_access+0x27b/0x8fa [i2c_ismt]
       [<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
       [<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
       [<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
       [<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
       [<ffffffff8143dfd0>] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
       [<ffffffff8172b36c>] i2c_smbus_xfer+0xec/0x4b0
       [<ffffffff810aa4d5>] ? vprintk_emit+0x345/0x530
       [<ffffffffa038936b>] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
       [<ffffffff810aa829>] ? vprintk_default+0x29/0x40
       [<ffffffffa0389b33>] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
       [<ffffffff811b04c8>] do_vfs_ioctl+0x328/0x5d0
       [<ffffffff8119d8ec>] ? vfs_write+0x11c/0x190
       [<ffffffff8109d449>] ? rt_up_read+0x19/0x20
       [<ffffffff811b07f1>] SyS_ioctl+0x81/0xa0
       [<ffffffff819a351b>] system_call_fastpath+0x16/0x6e
      
      This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.
      
      After finished I2C block read/write, when unmap the data buffer,
      a wrong device address was pass to dma_unmap_single().
      
      To fix this, give dma_unmap_single() the "dev" parameter, just like
      what dma_map_single() does, then unmap can find the right devices.
      
      Fixes: 13f35ac1 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
      Signed-off-by: default avatarLiwei Song <liwei.song@windriver.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52b9b51a
    • Andrey Konovalov's avatar
      kasan: don't emit builtin calls when sanitization is off · 76b6f30f
      Andrey Konovalov authored
      commit 0e410e15 upstream.
      
      With KASAN enabled the kernel has two different memset() functions, one
      with KASAN checks (memset) and one without (__memset).  KASAN uses some
      macro tricks to use the proper version where required.  For example
      memset() calls in mm/slub.c are without KASAN checks, since they operate
      on poisoned slab object metadata.
      
      The issue is that clang emits memset() calls even when there is no
      memset() in the source code.  They get linked with improper memset()
      implementation and the kernel fails to boot due to a huge amount of KASAN
      reports during early boot stages.
      
      The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
      n marker.
      
      Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.comSigned-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ Sami: Backported to 4.9 avoiding c5caf21a and e7c52b84 ]
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76b6f30f
    • Toshi Kani's avatar
      x86/mm: Disable ioremap free page handling on x86-PAE · 2130e543
      Toshi Kani authored
      commit f967db0b upstream.
      
      ioremap() supports pmd mappings on x86-PAE.  However, kernel's pmd
      tables are not shared among processes on x86-PAE.  Therefore, any
      update to sync'd pmd entries need re-syncing.  Freeing a pte page
      also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().
      
      Disable free page handling on x86-PAE.  pud_free_pmd_page() and
      pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
      This assures that ioremap() does not update sync'd pmd entries at the
      cost of falling back to pte mappings.
      
      Fixes: 28ee90fe ("x86/mm: implement free pmd/pte page interfaces")
      Reported-by: default avatarJoerg Roedel <joro@8bytes.org>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: mhocko@suse.com
      Cc: akpm@linux-foundation.org
      Cc: hpa@zytor.com
      Cc: cpandya@codeaurora.org
      Cc: linux-mm@kvack.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: stable@vger.kernel.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20180627141348.21777-2-toshi.kani@hpe.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2130e543
    • Guenter Roeck's avatar
      x86: i8259: Add missing include file · cc83ba49
      Guenter Roeck authored
      commit 0a957467 upstream.
      
      i8259.h uses inb/outb and thus needs to include asm/io.h to avoid the
      following build error, as seen with x86_64:defconfig and CONFIG_SMP=n.
      
        In file included from drivers/rtc/rtc-cmos.c:45:0:
        arch/x86/include/asm/i8259.h: In function 'inb_pic':
        arch/x86/include/asm/i8259.h:32:24: error:
      	implicit declaration of function 'inb'
      
        arch/x86/include/asm/i8259.h: In function 'outb_pic':
        arch/x86/include/asm/i8259.h:45:2: error:
      	implicit declaration of function 'outb'
      Reported-by: default avatarSebastian Gottschall <s.gottschall@dd-wrt.com>
      Suggested-by: default avatarSebastian Gottschall <s.gottschall@dd-wrt.com>
      Fixes: 447ae316 ("x86: Don't include linux/irq.h from asm/hardirq.h")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc83ba49
    • Guenter Roeck's avatar
      x86/l1tf: Fix build error seen if CONFIG_KVM_INTEL is disabled · 61341a36
      Guenter Roeck authored
      commit 1eb46908 upstream.
      
      allmodconfig+CONFIG_INTEL_KVM=n results in the following build error.
      
        ERROR: "l1tf_vmx_mitigation" [arch/x86/kvm/kvm.ko] undefined!
      
      Fixes: 5b76a3cf ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61341a36
  2. 15 Aug, 2018 26 commits