1. 21 9月, 2019 5 次提交
  2. 19 9月, 2019 35 次提交
    • G
      Linux 4.19.74 · dbc29aff
      Greg Kroah-Hartman 提交于
      dbc29aff
    • L
      x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence GCC9 build warning · 9d587fe2
      Linus Torvalds 提交于
      commit 42e0e95474fc6076b5cd68cab8fa0340a1797a72 upstream.
      
      One of the very few warnings I have in the current build comes from
      arch/x86/boot/edd.c, where I get the following with a gcc9 build:
      
         arch/x86/boot/edd.c: In function ‘query_edd’:
         arch/x86/boot/edd.c:148:11: warning: taking address of packed member of ‘struct boot_params’ may result in an unaligned pointer value [-Waddress-of-packed-member]
           148 |  mbrptr = boot_params.edd_mbr_sig_buffer;
               |           ^~~~~~~~~~~
      
      This warning triggers because we throw away all the CFLAGS and then make
      a new set for REALMODE_CFLAGS, so the -Wno-address-of-packed-member we
      added in the following commit is not present:
      
        6f303d60534c ("gcc-9: silence 'address-of-packed-member' warning")
      
      The simplest solution for now is to adjust the warning for this version
      of CFLAGS as well, but it would definitely make sense to examine whether
      REALMODE_CFLAGS could be derived from CFLAGS, so that it picks up changes
      in the compiler flags environment automatically.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d587fe2
    • J
      nvmem: Use the same permissions for eeprom as for nvmem · 96c08711
      Jean Delvare 提交于
      commit e70d8b287301eb6d7c7761c6171c56af62110ea3 upstream.
      
      The compatibility "eeprom" attribute is currently root-only no
      matter what the configuration says. The "nvmem" attribute does
      respect the setting of the root_only configuration bit, so do the
      same for "eeprom".
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Fixes: b6c217ab ("nvmem: Add backwards compatibility support for older EEPROM drivers.")
      Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20190728184255.563332e6@endymionSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96c08711
    • H
      rsi: fix a double free bug in rsi_91x_deinit() · 3622d621
      Hui Peng 提交于
      commit 8b51dc7291473093c821195c4b6af85fadedbc2f upstream.
      
      `dev` (struct rsi_91x_usbdev *) field of adapter
      (struct rsi_91x_usbdev *) is allocated  and initialized in
      `rsi_init_usb_interface`. If any error is detected in information
      read from the device side,  `rsi_init_usb_interface` will be
      freed. However, in the higher level error handling code in
      `rsi_probe`, if error is detected, `rsi_91x_deinit` is called
      again, in which `dev` will be freed again, resulting double free.
      
      This patch fixes the double free by removing the free operation on
      `dev` in `rsi_init_usb_interface`, because `rsi_91x_deinit` is also
      used in `rsi_disconnect`, in that code path, the `dev` field is not
       (and thus needs to be) freed.
      
      This bug was found in v4.19, but is also present in the latest version
      of kernel. Fixes CVE-2019-15504.
      Reported-by: NHui Peng <benquike@gmail.com>
      Reported-by: NMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: NHui Peng <benquike@gmail.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3622d621
    • S
      platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to critclk_systems DMI table · 780f3aad
      Steffen Dirkwinkel 提交于
      commit 9452fbf5c6cf5f470e0748fe7a14a683e7765f7a upstream.
      
      The CB4063 board uses pmc_plt_clk* clocks for ethernet controllers. This
      adds it to the critclk_systems DMI table so the clocks are marked as
      CLK_CRITICAL and not turned off.
      
      Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
      Signed-off-by: NSteffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      780f3aad
    • Y
      modules: fix compile error if don't have strict module rwx · 52bfcc9c
      Yang Yingliang 提交于
      commit 93651f80dcb616b8c9115cdafc8e57a781af22d0 upstream.
      
      If CONFIG_ARCH_HAS_STRICT_MODULE_RWX is not defined,
      we need stub for module_enable_nx() and module_enable_x().
      
      If CONFIG_ARCH_HAS_STRICT_MODULE_RWX is defined, but
      CONFIG_STRICT_MODULE_RWX is disabled, we need stub for
      module_enable_nx.
      
      Move frob_text() outside of the CONFIG_STRICT_MODULE_RWX,
      because it is needed anyway.
      
      Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52bfcc9c
    • Y
      modules: fix BUG when load module with rodata=n · ae415d7a
      Yang Yingliang 提交于
      commit 2eef1399a866c57687962e15142b141a4f8e7862 upstream.
      
      When loading a module with rodata=n, it causes an executing
      NX-protected page BUG.
      
      [   32.379191] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
      [   32.382917] BUG: unable to handle page fault for address: ffffffffc0005000
      [   32.385947] #PF: supervisor instruction fetch in kernel mode
      [   32.387662] #PF: error_code(0x0011) - permissions violation
      [   32.389352] PGD 240c067 P4D 240c067 PUD 240e067 PMD 421a52067 PTE 8000000421a53063
      [   32.391396] Oops: 0011 [#1] SMP PTI
      [   32.392478] CPU: 7 PID: 2697 Comm: insmod Tainted: G           O      5.2.0-rc5+ #202
      [   32.394588] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [   32.398157] RIP: 0010:ko_test_init+0x0/0x1000 [ko_test]
      [   32.399662] Code: Bad RIP value.
      [   32.400621] RSP: 0018:ffffc900029f3ca8 EFLAGS: 00010246
      [   32.402171] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   32.404332] RDX: 00000000000004c7 RSI: 0000000000000cc0 RDI: ffffffffc0005000
      [   32.406347] RBP: ffffffffc0005000 R08: ffff88842fbebc40 R09: ffffffff810ede4a
      [   32.408392] R10: ffffea00108e3480 R11: 0000000000000000 R12: ffff88842bee21a0
      [   32.410472] R13: 0000000000000001 R14: 0000000000000001 R15: ffffc900029f3e78
      [   32.412609] FS:  00007fb4f0c0a700(0000) GS:ffff88842fbc0000(0000) knlGS:0000000000000000
      [   32.414722] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   32.416290] CR2: ffffffffc0004fd6 CR3: 0000000421a90004 CR4: 0000000000020ee0
      [   32.418471] Call Trace:
      [   32.419136]  do_one_initcall+0x41/0x1df
      [   32.420199]  ? _cond_resched+0x10/0x40
      [   32.421433]  ? kmem_cache_alloc_trace+0x36/0x160
      [   32.422827]  do_init_module+0x56/0x1f7
      [   32.423946]  load_module+0x1e67/0x2580
      [   32.424947]  ? __alloc_pages_nodemask+0x150/0x2c0
      [   32.426413]  ? map_vm_area+0x2d/0x40
      [   32.427530]  ? __vmalloc_node_range+0x1ef/0x260
      [   32.428850]  ? __do_sys_init_module+0x135/0x170
      [   32.430060]  ? _cond_resched+0x10/0x40
      [   32.431249]  __do_sys_init_module+0x135/0x170
      [   32.432547]  do_syscall_64+0x43/0x120
      [   32.433853]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Because if rodata=n, set_memory_x() can't be called, fix this by
      calling set_memory_x in complete_formation();
      
      Fixes: f2c65fb3221a ("x86/modules: Avoid breaking W^X while loading modules")
      Suggested-by: NJian Cheng <cj.chengjian@huawei.com>
      Reviewed-by: NNadav Amit <namit@vmware.com>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae415d7a
    • O
      iio: adc: stm32-dfsdm: fix data type · 0ae0c43a
      Olivier Moysan 提交于
      commit c6013bf50e2a2a94ab3d012e191096432aa50c6f upstream.
      
      Fix the data type as DFSDM raw output is complements 2,
      24bits left aligned in a 32-bit register.
      This change does not affect AUDIO path
      - Set data as signed for IIO (as for AUDIO)
      - Set 8 bit right shift for IIO.
      The 8 LSBs bits of data contains channel info and are masked.
      Signed-off-by: NOlivier Moysan <olivier.moysan@st.com>
      Fixes: e2e6771c ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
      Acked-by: NFabrice Gasnier <fabrice.gasnier@st.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ae0c43a
    • M
      Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature" · acf77c41
      Mario Limonciello 提交于
      commit 1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f upstream.
      
      This reverts commit a0085f25.
      
      This commit has caused regressions in notebooks that support suspend
      to idle such as the XPS 9360, XPS 9370 and XPS 9380.
      
      These notebooks will wakeup from suspend to idle from an unsolicited
      advertising packet from an unpaired BLE device.
      
      In a bug report it was sugggested that this is caused by a generic
      lack of LE privacy support.  Revert this commit until that behavior
      can be avoided by the kernel.
      
      Fixes: a0085f25 ("Bluetooth: btusb: driver to enable the usb-wakeup feature")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=200039
      Link: https://marc.info/?l=linux-bluetooth&m=156441081612627&w=2
      Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/750073/
      CC: Bastien Nocera <hadess@hadess.net>
      CC: Christian Kellner <ckellner@redhat.com>
      CC: Sukumar Ghorai <sukumar.ghorai@intel.com>
      Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acf77c41
    • N
      drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto · a03ed289
      Nishka Dasgupta 提交于
      commit 165d42c012be69900f0e2f8545626cb9e7d4a832 upstream.
      
      Each iteration of for_each_child_of_node puts the previous
      node, but in the case of a goto from the middle of the loop, there is
      no put, thus causing a memory leak. Hence add an of_node_put before the
      goto in two places.
      Issue found with Coccinelle.
      
      Fixes: 119f5173 (drm/mediatek: Add DRM Driver for Mediatek SoC MT8173)
      Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a03ed289
    • H
      drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPC · d13a836d
      Hans de Goede 提交于
      commit dae1ccee012ea7514af8e4a88429844157aca7dc upstream.
      
      Newer GPD MicroPC BIOS versions have proper DMI strings, add an extra quirk
      table entry for these new strings. This is good news, as this means that we
      no longer have to update the BIOS dates list with every BIOS update.
      
      Fixes: 652b8b086538("drm: panel-orientation-quirks: Add quirk for GPD MicroPC")
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190624154014.8557-2-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d13a836d
    • A
      firmware: ti_sci: Always request response from firmware · 4b30a069
      Andrew F. Davis 提交于
      commit 66f030eac257a572fbedab3d9646d87d647351fd upstream.
      
      TI-SCI firmware will only respond to messages when the
      TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages already do
      this, set this for the ones that do not.
      
      This will be enforced in future firmware that better match the TI-SCI
      specifications, this patch will not break users of existing firmware.
      
      Fixes: aa276781 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
      Signed-off-by: NAndrew F. Davis <afd@ti.com>
      Acked-by: NNishanth Menon <nm@ti.com>
      Tested-by: NAlejandro Hernandez <ajhernandez@ti.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b30a069
    • C
      crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking. · 3dfc787f
      Christophe Leroy 提交于
      commit 4bbfb839259a9c96a0be872e16f7471b7136aee5 upstream.
      
      In that mode, hardware ICV verification is not supported.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 7405c8d7 ("crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3dfc787f
    • C
      crypto: talitos - Do not modify req->cryptlen on decryption. · e89d4cb6
      Christophe Leroy 提交于
      commit 7ede4c36cf7c6516986ee9d75b197c8bf73ea96f upstream.
      
      For decrypt, req->cryptlen includes the size of the authentication
      part while all functions of the driver expect cryptlen to be
      the size of the encrypted data.
      
      As it is not expected to change req->cryptlen, this patch
      implements local calculation of cryptlen.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 9c4a7965 ("crypto: talitos - Freescale integrated security engine (SEC) driver")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e89d4cb6
    • C
      crypto: talitos - fix ECB algs ivsize · 9aff4077
      Christophe Leroy 提交于
      commit d84cc9c9524ec5973a337533e6d8ccd3e5f05f2b upstream.
      
      ECB's ivsize must be 0.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 5e75ae1b ("crypto: talitos - add new crypto modes")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9aff4077
    • C
      crypto: talitos - check data blocksize in ablkcipher. · c4d7148e
      Christophe Leroy 提交于
      commit ee483d32ee1a1a7f7d7e918fbc350c790a5af64a upstream.
      
      When data size is not a multiple of the alg's block size,
      the SEC generates an error interrupt and dumps the registers.
      And for NULL size, the SEC does just nothing and the interrupt
      is awaited forever.
      
      This patch ensures the data size is correct before submitting
      the request to the SEC engine.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 4de9d0b5 ("crypto: talitos - Add ablkcipher algorithms")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4d7148e
    • C
      crypto: talitos - fix CTR alg blocksize · 02ebbb4f
      Christophe Leroy 提交于
      commit b9a05b6041cb9810a291315569b2af0d63c3680a upstream.
      
      CTR has a blocksize of 1.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 5e75ae1b ("crypto: talitos - add new crypto modes")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02ebbb4f
    • C
      crypto: talitos - check AES key size · 39fa02a3
      Christophe Leroy 提交于
      commit 1ba34e71e9e56ac29a52e0d42b6290f3dc5bfd90 upstream.
      
      Although the HW accepts any size and silently truncates
      it to the correct length, the extra tests expects EINVAL
      to be returned when the key size is not valid.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Fixes: 4de9d0b5 ("crypto: talitos - Add ablkcipher algorithms")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39fa02a3
    • M
      driver core: Fix use-after-free and double free on glue directory · e1666bcb
      Muchun Song 提交于
      commit ac43432cb1f5c2950408534987e57c2071e24d8f upstream.
      
      There is a race condition between removing glue directory and adding a new
      device under the glue dir. It can be reproduced in following test:
      
      CPU1:                                         CPU2:
      
      device_add()
        get_device_parent()
          class_dir_create_and_add()
            kobject_add_internal()
              create_dir()    // create glue_dir
      
                                                    device_add()
                                                      get_device_parent()
                                                        kobject_get() // get glue_dir
      
      device_del()
        cleanup_glue_dir()
          kobject_del(glue_dir)
      
                                                      kobject_add()
                                                        kobject_add_internal()
                                                          create_dir() // in glue_dir
                                                            sysfs_create_dir_ns()
                                                              kernfs_create_dir_ns(sd)
      
            sysfs_remove_dir() // glue_dir->sd=NULL
            sysfs_put()        // free glue_dir->sd
      
                                                                // sd is freed
                                                                kernfs_new_node(sd)
                                                                  kernfs_get(glue_dir)
                                                                  kernfs_add_one()
                                                                  kernfs_put()
      
      Before CPU1 remove last child device under glue dir, if CPU2 add a new
      device under glue dir, the glue_dir kobject reference count will be
      increase to 2 via kobject_get() in get_device_parent(). And CPU2 has
      been called kernfs_create_dir_ns(), but not call kernfs_new_node().
      Meanwhile, CPU1 call sysfs_remove_dir() and sysfs_put(). This result in
      glue_dir->sd is freed and it's reference count will be 0. Then CPU2 call
      kernfs_get(glue_dir) will trigger a warning in kernfs_get() and increase
      it's reference count to 1. Because glue_dir->sd is freed by CPU1, the next
      call kernfs_add_one() by CPU2 will fail(This is also use-after-free)
      and call kernfs_put() to decrease reference count. Because the reference
      count is decremented to 0, it will also call kmem_cache_free() to free
      the glue_dir->sd again. This will result in double free.
      
      In order to avoid this happening, we also should make sure that kernfs_node
      for glue_dir is released in CPU1 only when refcount for glue_dir kobj is
      1 to fix this race.
      
      The following calltrace is captured in kernel 4.14 with the following patch
      applied:
      
      commit 726e4109 ("drivers: core: Remove glue dirs from sysfs earlier")
      
      --------------------------------------------------------------------------
      [    3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
                      Here is WARN_ON(!atomic_read(&kn->count) in kernfs_get().
      ....
      [    3.633986] Call trace:
      [    3.633991]  kernfs_create_dir_ns+0xa8/0xb0
      [    3.633994]  sysfs_create_dir_ns+0x54/0xe8
      [    3.634001]  kobject_add_internal+0x22c/0x3f0
      [    3.634005]  kobject_add+0xe4/0x118
      [    3.634011]  device_add+0x200/0x870
      [    3.634017]  _request_firmware+0x958/0xc38
      [    3.634020]  request_firmware_into_buf+0x4c/0x70
      ....
      [    3.634064] kernel BUG at .../mm/slub.c:294!
                      Here is BUG_ON(object == fp) in set_freepointer().
      ....
      [    3.634346] Call trace:
      [    3.634351]  kmem_cache_free+0x504/0x6b8
      [    3.634355]  kernfs_put+0x14c/0x1d8
      [    3.634359]  kernfs_create_dir_ns+0x88/0xb0
      [    3.634362]  sysfs_create_dir_ns+0x54/0xe8
      [    3.634366]  kobject_add_internal+0x22c/0x3f0
      [    3.634370]  kobject_add+0xe4/0x118
      [    3.634374]  device_add+0x200/0x870
      [    3.634378]  _request_firmware+0x958/0xc38
      [    3.634381]  request_firmware_into_buf+0x4c/0x70
      --------------------------------------------------------------------------
      
      Fixes: 726e4109 ("drivers: core: Remove glue dirs from sysfs earlier")
      Signed-off-by: NMuchun Song <smuchun@gmail.com>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NPrateek Sood <prsood@codeaurora.org>
      Link: https://lore.kernel.org/r/20190727032122.24639-1-smuchun@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1666bcb
    • R
      ubifs: Correctly use tnc_next() in search_dh_cookie() · 72cd230b
      Richard Weinberger 提交于
      commit bacfa94b08027b9f66ede7044972e3b066766b3e upstream.
      
      Commit c877154d fixed an uninitialized variable and optimized
      the function to not call tnc_next() in the first iteration of the
      loop. While this seemed perfectly legit and wise, it turned out to
      be illegal.
      If the lookup function does not find an exact match it will rewind
      the cursor by 1.
      The rewinded cursor will not match the name hash we are looking for
      and this results in a spurious -ENOENT.
      So we need to move to the next entry in case of an non-exact match,
      but not if the match was exact.
      
      While we are here, update the documentation to avoid further confusion.
      
      Cc: Hyunchul Lee <hyc.lee@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Fixes: c877154d ("ubifs: Fix uninitialized variable in search_dh_cookie()")
      Fixes: 781f675e ("ubifs: Fix unlink code wrt. double hash lookups")
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72cd230b
    • K
      gpio: fix line flag validation in lineevent_create · a6529008
      Kent Gibson 提交于
      commit 5ca2f54b597c816df54ff1b28eb99cf7262b955d upstream.
      
      lineevent_create should not allow any of GPIOHANDLE_REQUEST_OUTPUT,
      GPIOHANDLE_REQUEST_OPEN_DRAIN or GPIOHANDLE_REQUEST_OPEN_SOURCE to be set.
      
      Fixes: d7c51b47 ("gpio: userspace ABI for reading/writing GPIO lines")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NKent Gibson <warthog618@gmail.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6529008
    • A
      PCI: Always allow probing with driver_override · 0f4095f3
      Alex Williamson 提交于
      commit 2d2f4273cbe9058d1f5a518e5e880d27d7b3b30f upstream.
      
      Commit 0e7df224 ("PCI: Add sysfs sriov_drivers_autoprobe to control
      VF driver binding") introduced the sriov_drivers_autoprobe attribute
      which allows users to prevent the kernel from automatically probing a
      driver for new VFs as they are created.  This allows VFs to be spawned
      without automatically binding the new device to a host driver, such as
      in cases where the user intends to use the device only with a meta
      driver like vfio-pci.  However, the current implementation prevents any
      use of drivers_probe with the VF while sriov_drivers_autoprobe=0.  This
      blocks the now current general practice of setting driver_override
      followed by using drivers_probe to bind a device to a specified driver.
      
      The kernel never automatically sets a driver_override therefore it seems
      we can assume a driver_override reflects the intent of the user.  Also,
      probing a device using a driver_override match seems outside the scope
      of the 'auto' part of sriov_drivers_autoprobe.  Therefore, let's allow
      driver_override matches regardless of sriov_drivers_autoprobe, which we
      can do by simply testing if a driver_override is set for a device as a
      'can probe' condition.
      
      Fixes: 0e7df224 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding")
      Link: https://lore.kernel.org/lkml/155742996741.21878.569845487290798703.stgit@gimli.home
      Link: https://lore.kernel.org/linux-pci/155672991496.20698.4279330795743262888.stgit@gimli.home/T/#uSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f4095f3
    • X
      mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue · 70facf93
      Xiaolei Li 提交于
      commit 336d4b138be2dad372b67a2388e42805c48aaa38 upstream.
      
      One main goal of the function mtk_nfc_update_ecc_stats is to check
      whether sectors are all empty. If they are empty, set these sectors's
      data buffer and OOB buffer as 0xff.
      
      But now, the sector OOB buffer pointer is wrongly assigned. We always
      do memset from sector 0.
      
      To fix this issue, pass start sector number to make OOB buffer pointer
      be properly assigned.
      
      Fixes: 1d6b1e46 ("mtd: mediatek: driver for MTK Smart Device")
      Signed-off-by: NXiaolei Li <xiaolei.li@mediatek.com>
      Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70facf93
    • D
      clk: rockchip: Don't yell about bad mmc phases when getting · 6da56f89
      Douglas Anderson 提交于
      commit 6943b839721ad4a31ad2bacf6e71b21f2dfe3134 upstream.
      
      At boot time, my rk3288-veyron devices yell with 8 lines that look
      like this:
        [    0.000000] rockchip_mmc_get_phase: invalid clk rate
      
      This is because the clock framework at clk_register() time tries to
      get the phase but we don't have a parent yet.
      
      While the errors appear to be harmless they are still ugly and, in
      general, we don't want yells like this in the log unless they are
      important.
      
      There's no real reason to be yelling here.  We can still return
      -EINVAL to indicate that the phase makes no sense without a parent.
      If someone really tries to do tuning and the clock is reported as 0
      then we'll see the yells in rockchip_mmc_set_phase().
      
      Fixes: 4bf59902 ("clk: rockchip: Prevent calculating mmc phase if clock rate is zero")
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6da56f89
    • N
      drm/meson: Add support for XBGR8888 & ABGR8888 formats · a63416f3
      Neil Armstrong 提交于
      commit 5ffff4415f9eeae834960226770963e2947e17eb upstream.
      
      Add missing XBGR8888 & ABGR8888 formats variants from the primary plane.
      
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NKevin Hilman <khilman@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190429075238.7884-1-narmstrong@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a63416f3
    • S
      powerpc: Add barrier_nospec to raw_copy_in_user() · d9e8b4ba
      Suraj Jitindar Singh 提交于
      commit 6fbcdd59094ade30db63f32316e9502425d7b256 upstream.
      
      Commit ddf35cf3 ("powerpc: Use barrier_nospec in copy_from_user()")
      Added barrier_nospec before loading from user-controlled pointers. The
      intention was to order the load from the potentially user-controlled
      pointer vs a previous branch based on an access_ok() check or similar.
      
      In order to achieve the same result, add a barrier_nospec to the
      raw_copy_in_user() function before loading from such a user-controlled
      pointer.
      
      Fixes: ddf35cf3 ("powerpc: Use barrier_nospec in copy_from_user()")
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9e8b4ba
    • S
      x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to... · eb020b77
      Steve Wahl 提交于
      x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors
      
      commit e16c2983fba0fa6763e43ad10916be35e3d8dc05 upstream.
      
      The last change to this Makefile caused relocation errors when loading
      a kdump kernel.  Restore -mcmodel=large (not -mcmodel=kernel),
      -ffreestanding, and -fno-zero-initialized-bsss, without reverting to
      the former practice of resetting KBUILD_CFLAGS.
      
      Purgatory.ro is a standalone binary that is not linked against the
      rest of the kernel.  Its image is copied into an array that is linked
      to the kernel, and from there kexec relocates it wherever it desires.
      
      With the previous change to compiler flags, the error "kexec: Overflow
      in relocation type 11 value 0x11fffd000" was encountered when trying
      to load the crash kernel.  This is from kexec code trying to relocate
      the purgatory.ro object.
      
      From the error message, relocation type 11 is R_X86_64_32S.  The
      x86_64 ABI says:
      
        "The R_X86_64_32 and R_X86_64_32S relocations truncate the
         computed value to 32-bits.  The linker must verify that the
         generated value for the R_X86_64_32 (R_X86_64_32S) relocation
         zero-extends (sign-extends) to the original 64-bit value."
      
      This type of relocation doesn't work when kexec chooses to place the
      purgatory binary in memory that is not reachable with 32 bit
      addresses.
      
      The compiler flag -mcmodel=kernel allows those type of relocations to
      be emitted, so revert to using -mcmodel=large as was done before.
      
      Also restore the -ffreestanding and -fno-zero-initialized-bss flags
      because they are appropriate for a stand alone piece of object code
      which doesn't explicitly zero the bss, and one other report has said
      undefined symbols are encountered without -ffreestanding.
      
      These identical compiler flag changes need to happen for every object
      that becomes part of the purgatory.ro object, so gather them together
      first into PURGATORY_CFLAGS_REMOVE and PURGATORY_CFLAGS, and then
      apply them to each of the objects that have C source.  Do not apply
      any of these flags to kexec-purgatory.o, which is not part of the
      standalone object but part of the kernel proper.
      Tested-by: NVaibhav Rustagi <vaibhavrustagi@google.com>
      Tested-by: NAndreas Smas <andreas@lonelycoder.com>
      Signed-off-by: NSteve Wahl <steve.wahl@hpe.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: None
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: clang-built-linux@googlegroups.com
      Cc: dimitri.sivanich@hpe.com
      Cc: mike.travis@hpe.com
      Cc: russ.anderson@hpe.com
      Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      Link: https://lkml.kernel.org/r/20190905202346.GA26595@swahl-linuxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Andreas Smas <andreas@lonelycoder.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      eb020b77
    • P
      KVM: nVMX: handle page fault in vmread · 73c31bd9
      Paolo Bonzini 提交于
      commit f7eea636c3d505fe6f1d1066234f1aaf7171b681 upstream.
      
      The implementation of vmread to memory is still incomplete, as it
      lacks the ability to do vmread to I/O memory just like vmptrst.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73c31bd9
    • F
      KVM: x86: work around leak of uninitialized stack contents · 6e60900c
      Fuqian Huang 提交于
      commit 541ab2aeb28251bf7135c7961f3a6080eebcc705 upstream.
      
      Emulation of VMPTRST can incorrectly inject a page fault
      when passed an operand that points to an MMIO address.
      The page fault will use uninitialized kernel stack memory
      as the CR2 and error code.
      
      The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
      exit to userspace; however, it is not an easy fix, so for now just ensure
      that the error code and CR2 are zero.
      Signed-off-by: NFuqian Huang <huangfq.daxian@gmail.com>
      Cc: stable@vger.kernel.org
      [add comment]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e60900c
    • T
      KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl · 09a9f894
      Thomas Huth 提交于
      commit 53936b5bf35e140ae27e4bbf0447a61063f400da upstream.
      
      When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject
      an interrupt, we convert them from the legacy struct kvm_s390_interrupt
      to the new struct kvm_s390_irq via the s390int_to_s390irq() function.
      However, this function does not take care of all types of interrupts
      that we can inject into the guest later (see do_inject_vcpu()). Since we
      do not clear out the s390irq values before calling s390int_to_s390irq(),
      there is a chance that we copy random data from the kernel stack which
      could be leaked to the userspace later.
      
      Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT
      interrupt: s390int_to_s390irq() does not handle it, and the function
      __inject_pfault_init() later copies irq->u.ext which contains the
      random kernel stack data. This data can then be leaked either to
      the guest memory in __deliver_pfault_init(), or the userspace might
      retrieve it directly with the KVM_S390_GET_IRQ_STATE ioctl.
      
      Fix it by handling that interrupt type in s390int_to_s390irq(), too,
      and by making sure that the s390irq struct is properly pre-initialized.
      And while we're at it, make sure that s390int_to_s390irq() now
      directly returns -EINVAL for unknown interrupt types, so that we
      immediately get a proper error code in case we add more interrupt
      types to do_inject_vcpu() without updating s390int_to_s390irq()
      sometime in the future.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Link: https://lore.kernel.org/kvm/20190912115438.25761-1-thuth@redhat.comSigned-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09a9f894
    • I
      KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset() · 9f8a2825
      Igor Mammedov 提交于
      commit 13a17cc0526f08d1df9507f7484176371cd263a0 upstream.
      
      If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling
      kvm_s390_vm_start_migration(), kernel will oops with:
      
        Unable to handle kernel pointer dereference in virtual kernel address space
        Failing address: 0000000000000000 TEID: 0000000000000483
        Fault in home space mode while using kernel ASCE.
        AS:0000000002a2000b R2:00000001bff8c00b R3:00000001bff88007 S:00000001bff91000 P:000000000000003d
        Oops: 0004 ilc:2 [#1] SMP
        ...
        Call Trace:
        ([<001fffff804ec552>] kvm_s390_vm_set_attr+0x347a/0x3828 [kvm])
         [<001fffff804ecfc0>] kvm_arch_vm_ioctl+0x6c0/0x1998 [kvm]
         [<001fffff804b67e4>] kvm_vm_ioctl+0x51c/0x11a8 [kvm]
         [<00000000008ba572>] do_vfs_ioctl+0x1d2/0xe58
         [<00000000008bb284>] ksys_ioctl+0x8c/0xb8
         [<00000000008bb2e2>] sys_ioctl+0x32/0x40
         [<000000000175552c>] system_call+0x2b8/0x2d8
        INFO: lockdep is turned off.
        Last Breaking-Event-Address:
         [<0000000000dbaf60>] __memset+0xc/0xa0
      
      due to ms->dirty_bitmap being NULL, which might crash the host.
      
      Make sure that ms->dirty_bitmap is set before using it or
      return -EINVAL otherwise.
      
      Cc: <stable@vger.kernel.org>
      Fixes: afdad616 ("KVM: s390: Fix storage attributes migration with memory slots")
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Link: https://lore.kernel.org/kvm/20190911075218.29153-1-imammedo@redhat.com/Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NClaudio Imbrenda <imbrenda@linux.ibm.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      Reviewed-by: NJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: NJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f8a2825
    • Y
      genirq: Prevent NULL pointer dereference in resend_irqs() · 991b3458
      Yunfeng Ye 提交于
      commit eddf3e9c7c7e4d0707c68d1bb22cc6ec8aef7d4a upstream.
      
      The following crash was observed:
      
        Unable to handle kernel NULL pointer dereference at 0000000000000158
        Internal error: Oops: 96000004 [#1] SMP
        pc : resend_irqs+0x68/0xb0
        lr : resend_irqs+0x64/0xb0
        ...
        Call trace:
         resend_irqs+0x68/0xb0
         tasklet_action_common.isra.6+0x84/0x138
         tasklet_action+0x2c/0x38
         __do_softirq+0x120/0x324
         run_ksoftirqd+0x44/0x60
         smpboot_thread_fn+0x1ac/0x1e8
         kthread+0x134/0x138
         ret_from_fork+0x10/0x18
      
      The reason for this is that the interrupt resend mechanism happens in soft
      interrupt context, which is a asynchronous mechanism versus other
      operations on interrupts. free_irq() does not take resend handling into
      account. Thus, the irq descriptor might be already freed before the resend
      tasklet is executed. resend_irqs() does not check the return value of the
      interrupt descriptor lookup and derefences the return value
      unconditionally.
      
        1):
        __setup_irq
          irq_startup
            check_irq_resend  // activate softirq to handle resend irq
        2):
        irq_domain_free_irqs
          irq_free_descs
            free_desc
              call_rcu(&desc->rcu, delayed_free_desc)
        3):
        __do_softirq
          tasklet_action
            resend_irqs
              desc = irq_to_desc(irq)
              desc->handle_irq(desc)  // desc is NULL --> Ooops
      
      Fix this by adding a NULL pointer check in resend_irqs() before derefencing
      the irq descriptor.
      
      Fixes: a4633adc ("[PATCH] genirq: add genirq sw IRQ-retrigger")
      Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NZhiqiang Liu <liuzhiqiang26@huawei.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1630ae13-5c8e-901e-de09-e740b6a426a7@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      991b3458
    • A
      ixgbe: Prevent u8 wrapping of ITR value to something less than 10us · 5b5f1460
      Alexander Duyck 提交于
      commit 377228accbbb8b9738f615d791aa803f41c067e0 upstream.
      
      There were a couple cases where the ITR value generated via the adaptive
      ITR scheme could exceed 126. This resulted in the value becoming either 0
      or something less than 10. Switching back and forth between a value less
      than 10 and a value greater than 10 can cause issues as certain hardware
      features such as RSC to not function well when the ITR value has dropped
      that low.
      
      CC: stable@vger.kernel.org
      Fixes: b4ded832 ("ixgbe: Update adaptive ITR algorithm")
      Reported-by: NGregg Leventhal <gleventhal@janestreet.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b5f1460
    • F
      Btrfs: fix assertion failure during fsync and use of stale transaction · 7cbd49cf
      Filipe Manana 提交于
      commit 410f954cb1d1c79ae485dd83a175f21954fd87cd upstream.
      
      Sometimes when fsync'ing a file we need to log that other inodes exist and
      when we need to do that we acquire a reference on the inodes and then drop
      that reference using iput() after logging them.
      
      That generally is not a problem except if we end up doing the final iput()
      (dropping the last reference) on the inode and that inode has a link count
      of 0, which can happen in a very short time window if the logging path
      gets a reference on the inode while it's being unlinked.
      
      In that case we end up getting the eviction callback, btrfs_evict_inode(),
      invoked through the iput() call chain which needs to drop all of the
      inode's items from its subvolume btree, and in order to do that, it needs
      to join a transaction at the helper function evict_refill_and_join().
      However because the task previously started a transaction at the fsync
      handler, btrfs_sync_file(), it has current->journal_info already pointing
      to a transaction handle and therefore evict_refill_and_join() will get
      that transaction handle from btrfs_join_transaction(). From this point on,
      two different problems can happen:
      
      1) evict_refill_and_join() will often change the transaction handle's
         block reserve (->block_rsv) and set its ->bytes_reserved field to a
         value greater than 0. If evict_refill_and_join() never commits the
         transaction, the eviction handler ends up decreasing the reference
         count (->use_count) of the transaction handle through the call to
         btrfs_end_transaction(), and after that point we have a transaction
         handle with a NULL ->block_rsv (which is the value prior to the
         transaction join from evict_refill_and_join()) and a ->bytes_reserved
         value greater than 0. If after the eviction/iput completes the inode
         logging path hits an error or it decides that it must fallback to a
         transaction commit, the btrfs fsync handle, btrfs_sync_file(), gets a
         non-zero value from btrfs_log_dentry_safe(), and because of that
         non-zero value it tries to commit the transaction using a handle with
         a NULL ->block_rsv and a non-zero ->bytes_reserved value. This makes
         the transaction commit hit an assertion failure at
         btrfs_trans_release_metadata() because ->bytes_reserved is not zero but
         the ->block_rsv is NULL. The produced stack trace for that is like the
         following:
      
         [192922.917158] assertion failed: !trans->bytes_reserved, file: fs/btrfs/transaction.c, line: 816
         [192922.917553] ------------[ cut here ]------------
         [192922.917922] kernel BUG at fs/btrfs/ctree.h:3532!
         [192922.918310] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
         [192922.918666] CPU: 2 PID: 883 Comm: fsstress Tainted: G        W         5.1.4-btrfs-next-47 #1
         [192922.919035] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
         [192922.919801] RIP: 0010:assfail.constprop.25+0x18/0x1a [btrfs]
         (...)
         [192922.920925] RSP: 0018:ffffaebdc8a27da8 EFLAGS: 00010286
         [192922.921315] RAX: 0000000000000051 RBX: ffff95c9c16a41c0 RCX: 0000000000000000
         [192922.921692] RDX: 0000000000000000 RSI: ffff95cab6b16838 RDI: ffff95cab6b16838
         [192922.922066] RBP: ffff95c9c16a41c0 R08: 0000000000000000 R09: 0000000000000000
         [192922.922442] R10: ffffaebdc8a27e70 R11: 0000000000000000 R12: ffff95ca731a0980
         [192922.922820] R13: 0000000000000000 R14: ffff95ca84c73338 R15: ffff95ca731a0ea8
         [192922.923200] FS:  00007f337eda4e80(0000) GS:ffff95cab6b00000(0000) knlGS:0000000000000000
         [192922.923579] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         [192922.923948] CR2: 00007f337edad000 CR3: 00000001e00f6002 CR4: 00000000003606e0
         [192922.924329] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
         [192922.924711] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
         [192922.925105] Call Trace:
         [192922.925505]  btrfs_trans_release_metadata+0x10c/0x170 [btrfs]
         [192922.925911]  btrfs_commit_transaction+0x3e/0xaf0 [btrfs]
         [192922.926324]  btrfs_sync_file+0x44c/0x490 [btrfs]
         [192922.926731]  do_fsync+0x38/0x60
         [192922.927138]  __x64_sys_fdatasync+0x13/0x20
         [192922.927543]  do_syscall_64+0x60/0x1c0
         [192922.927939]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
         (...)
         [192922.934077] ---[ end trace f00808b12068168f ]---
      
      2) If evict_refill_and_join() decides to commit the transaction, it will
         be able to do it, since the nested transaction join only increments the
         transaction handle's ->use_count reference counter and it does not
         prevent the transaction from getting committed. This means that after
         eviction completes, the fsync logging path will be using a transaction
         handle that refers to an already committed transaction. What happens
         when using such a stale transaction can be unpredictable, we are at
         least having a use-after-free on the transaction handle itself, since
         the transaction commit will call kmem_cache_free() against the handle
         regardless of its ->use_count value, or we can end up silently losing
         all the updates to the log tree after that iput() in the logging path,
         or using a transaction handle that in the meanwhile was allocated to
         another task for a new transaction, etc, pretty much unpredictable
         what can happen.
      
      In order to fix both of them, instead of using iput() during logging, use
      btrfs_add_delayed_iput(), so that the logging path of fsync never drops
      the last reference on an inode, that step is offloaded to a safe context
      (usually the cleaner kthread).
      
      The assertion failure issue was sporadically triggered by the test case
      generic/475 from fstests, which loads the dm error target while fsstress
      is running, which lead to fsync failing while logging inodes with -EIO
      errors and then trying later to commit the transaction, triggering the
      assertion failure.
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cbd49cf
    • K
      gpio: fix line flag validation in linehandle_create · 22ed1d47
      Kent Gibson 提交于
      commit e95fbc130a162ba9ad956311b95aa0da269eea48 upstream.
      
      linehandle_create should not allow both GPIOHANDLE_REQUEST_INPUT
      and GPIOHANDLE_REQUEST_OUTPUT to be set.
      
      Fixes: d7c51b47 ("gpio: userspace ABI for reading/writing GPIO lines")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NKent Gibson <warthog618@gmail.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22ed1d47