1. 18 Jan, 2018 1 commit
    • Nick Desaulniers's avatar
      Input: synaptics-rmi4 - prevent UAF reported by KASAN · 55edde9f
      Nick Desaulniers authored
      KASAN found a UAF due to dangling pointer. As the report below says,
      rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in
      [  311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core]
      [  311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162
      [  311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2
      [  311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017
      [  311.424078] Call Trace:
      [  311.424086]  dump_stack+0xae/0x12d
      [  311.424090]  ? _atomic_dec_and_lock+0x103/0x103
      [  311.424094]  ? show_regs_print_info+0xa/0xa
      [  311.424099]  ? input_handle_event+0x10b/0x810
      [  311.424104]  print_address_description+0x65/0x229
      [  311.424108]  kasan_report.cold.5+0xa7/0x281
      [  311.424117]  rmi_f11_attention+0x526/0x5e0 [rmi_core]
      [  311.424123]  ? memcpy+0x1f/0x50
      [  311.424132]  ? rmi_f11_attention+0x526/0x5e0 [rmi_core]
      [  311.424143]  ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core]
      [  311.424153]  ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core]
      [  311.424163]  ? rmi_irq_fn+0x22c/0x270 [rmi_core]
      [  311.424173]  ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
      [  311.424177]  ? free_irq+0xa0/0xa0
      [  311.424180]  ? irq_finalize_oneshot.part.39+0xeb/0x180
      [  311.424190]  ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
      [  311.424193]  ? irq_thread_fn+0x3d/0x80
      [  311.424197]  ? irq_finalize_oneshot.part.39+0x180/0x180
      [  311.424200]  ? irq_thread+0x21d/0x290
      [  311.424203]  ? irq_thread_check_affinity+0x170/0x170
      [  311.424207]  ? remove_wait_queue+0x150/0x150
      [  311.424212]  ? kasan_unpoison_shadow+0x30/0x40
      [  311.424214]  ? __init_waitqueue_head+0xa0/0xd0
      [  311.424218]  ? task_non_contending.cold.55+0x18/0x18
      [  311.424221]  ? irq_forced_thread_fn+0xa0/0xa0
      [  311.424226]  ? irq_thread_check_affinity+0x170/0x170
      [  311.424230]  ? kthread+0x19e/0x1c0
      [  311.424233]  ? kthread_create_worker_on_cpu+0xc0/0xc0
      [  311.424237]  ? ret_from_fork+0x32/0x40
      [  311.424244] Allocated by task 899:
      [  311.424249]  kasan_kmalloc+0xbf/0xe0
      [  311.424252]  __kmalloc_track_caller+0xd9/0x1f0
      [  311.424255]  kmemdup+0x17/0x40
      [  311.424264]  rmi_set_attn_data+0xa4/0x1b0 [rmi_core]
      [  311.424269]  rmi_raw_event+0x10b/0x1f0 [hid_rmi]
      [  311.424278]  hid_input_report+0x1a8/0x2c0 [hid]
      [  311.424283]  i2c_hid_irq+0x146/0x1d0 [i2c_hid]
      [  311.424286]  irq_thread_fn+0x3d/0x80
      [  311.424288]  irq_thread+0x21d/0x290
      [  311.424291]  kthread+0x19e/0x1c0
      [  311.424293]  ret_from_fork+0x32/0x40
      [  311.424296] Freed by task 1162:
      [  311.424300]  kasan_slab_free+0x71/0xc0
      [  311.424303]  kfree+0x90/0x190
      [  311.424311]  rmi_irq_fn+0x1b2/0x270 [rmi_core]
      [  311.424319]  rmi_irq_fn+0x257/0x270 [rmi_core]
      [  311.424322]  irq_thread_fn+0x3d/0x80
      [  311.424324]  irq_thread+0x21d/0x290
      [  311.424327]  kthread+0x19e/0x1c0
      [  311.424330]  ret_from_fork+0x32/0x40
      [  311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64
      [  311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100)
      [  311.424344] The buggy address belongs to the page:
      [  311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0
      [  311.424353] flags: 0x17ffffc0000100(slab)
      [  311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a
      [  311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000
      [  311.424366] page dumped because: kasan: bad access detected
      [  311.424369] Memory state around the buggy address:
      [  311.424373]  ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  311.424377]  ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
      [  311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
      [  311.424384]                                                     ^
      [  311.424387]  ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
      [  311.424391]  ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNick Desaulniers <nick.desaulniers@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
  2. 12 Jan, 2018 1 commit
    • Nir Perry's avatar
      Input: ALPS - fix multi-touch decoding on SS4 plus touchpads · 4d94e776
      Nir Perry authored
      The fix for handling two-finger scroll (i4a646580 - "Input: ALPS -
      fix two-finger scroll breakage in right side on ALPS touchpad")
      introduced a minor "typo" that broke decoding of multi-touch events are
      decoded on some ALPS touchpads.  For example, tapping with three-fingers
      can no longer be used to emulate middle-mouse-button (the kernel doesn't
      recognize this as the proper event, and doesn't report it correctly to
      userspace).  This affects touchpads that use SS4 "plus" protocol
      variant, like those found on Dell E7270 & E7470 laptops (tested on
      First, probably the code in alps_decode_ss4_v2() for case
      SS4_PACKET_ID_MULTI used inconsistent indices to "f->mt[]". You can see
      0 & 1 are used for the "if" part but 2 & 3 are used for the "else" part.
      Second, in the previous patch, new macros were introduced to decode X
      coordinates specific to the SS4 "plus" variant, but the macro to
      define the maximum X value wasn't changed accordingly. The macros to
      decode X values for "plus" variant are effectively shifted right by 1
      bit, but the max wasn't shifted too. This causes the driver to
      incorrectly handle "no data" cases, which also interfered with how
      multi-touch was handled.
      Fixes: 4a646580 ("Input: ALPS - fix two-finger scroll breakage...")
      Signed-off-by: default avatarNir Perry <nirperry@gmail.com>
      Reviewed-by: default avatarMasaki Ota <masaki.ota@jp.alps.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
  3. 11 Jan, 2018 2 commits
  4. 09 Jan, 2018 3 commits
  5. 02 Jan, 2018 1 commit
  6. 18 Dec, 2017 1 commit
  7. 30 Nov, 2017 2 commits
    • Dmitry Torokhov's avatar
      Input: elants_i2c - do not clobber interrupt trigger on x86 · 4c83c071
      Dmitry Torokhov authored
      This is similar to commit a4b0a58b ("Input: elan_i2c - do not
      clobber interrupt trigger on x86")
      On x86 we historically used falling edge interrupts in the driver
      because that's how first Chrome devices were configured. They also
      did not use ACPI to enumerate I2C devices (because back then there
      was no kernel support for that), so trigger was hard-coded in the
      driver. However the controller behavior is much more reliable if
      we use level triggers, and that is how we configured ARM devices,
      and how want to configure newer x86 devices as well. All newer
      x86 boxes have their I2C devices enumerated in ACPI.
      Let's see if platform code (ACPI, DT) described interrupt and
      specified particular trigger type, and if so, let's use it instead
      of always clobbering trigger with IRQF_TRIGGER_FALLING. We will
      still use this trigger type as a fallback if platform code left
      interrupt trigger unconfigured.
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
    • Olof Johansson's avatar
      Input: joystick/analog - riscv has get_cycles() · da8df839
      Olof Johansson authored
      drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer not defined for this architecture. [-Wcpp]
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
  8. 27 Nov, 2017 2 commits
  9. 14 Nov, 2017 1 commit
  10. 10 Nov, 2017 6 commits
  11. 08 Nov, 2017 5 commits
  12. 05 Nov, 2017 8 commits
  13. 04 Nov, 2017 7 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm · 2d634994
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       - omit EFI memory map sorting, which was recently introduced, but
         caused problems with the decompressor due to additional sections
         being emitted.
       - avoid unaligned load fault-generating instructions in the
         decompressor by switching to a private unaligned implementation.
       - add a symbol into the decompressor to further debug non-boot
         situations (ld's documentation is extremely poor for how "." works,
         ld doesn't seem to follow its own documentation!)
       - parse endian information to sparse
      * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: add debug ".edata_real" symbol
        ARM: 8716/1: pass endianness info to sparse
        efi/libstub: arm: omit sorting of the UEFI memory map
        ARM: 8715/1: add a private asm/unaligned.h
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f0a32ee4
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "Fixes for interrupt controller emulation in ARM/ARM64 and x86, plus a
        one-liner x86 KVM guest fix"
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: Update APICv on APIC reset
        KVM: VMX: Do not fully reset PI descriptor on vCPU reset
        kvm: Return -ENODEV from update_persistent_clock
        KVM: arm/arm64: vgic-its: Check GITS_BASER Valid bit before saving tables
        KVM: arm/arm64: vgic-its: Check CBASER/BASER validity before enabling the ITS
        KVM: arm/arm64: vgic-its: Fix vgic_its_restore_collection_table returned value
        KVM: arm/arm64: vgic-its: Fix return value for device table restore
        arm/arm64: kvm: Disable branch profiling in HYP code
        arm/arm64: kvm: Move initialization completion message
        arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort
        KVM: arm64: its: Fix missing dynamic allocation check in scan_its_table
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · b1878b85
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "Only two patches came in over the last two weeks: Uniphier USB support
        needs additional clocks enabled (on both 32-bit and 64-bit ARM), and a
        Marvell MVEBU stability issue has been fixed"
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: dts: mvebu: pl310-cache disable double-linefill
        arm64: dts: uniphier: add STDMAC clock to EHCI nodes
        ARM: dts: uniphier: add STDMAC clock to EHCI nodes
    • Linus Torvalds's avatar
      Merge tag 'mips_fixes_4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips · dab30d55
      Linus Torvalds authored
      Pull MIPS fixes from James Hogan:
       "A selection of important MIPS fixes for 4.14, and some MAINTAINERS /
        email address updates:
        Maintainership updates:
         - imgtec.com -> mips.com email addresses (this trivially updates
           comments in quite a few files, as well as MAINTAINERS)
         - Pistachio SoC maintainership update
         - NI 169445 build (new platform in 4.14)
         - EVA regression (4.14)
         - SMP-CPS build & preemption regressions (4.14)
         - SMP/hotplug deadlock & race (deadlock reintroduced 4.13)
         - ebpf_jit error return (4.13)
         - SMP-CMP build regressions (4.11 and 4.14)
         - bad UASM microMIPS encoding (3.16)
         - CM definitions (3.15)"
      [ I had taken the email address updates separately, because I didn't
        expect James to send a pull request, so those got applied twice.   - Linus]
      * tag 'mips_fixes_4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips:
        MIPS: Update email address for Marcin Nowakowski
        MIPS: smp-cmp: Fix vpe_id build error
        MAINTAINERS: Update Pistachio platform maintainers
        MIPS: smp-cmp: Use right include for task_struct
        MIPS: Update Goldfish RTC driver maintainer email address
        MIPS: Update RINT emulation maintainer email address
        MIPS: CPS: Fix use of current_cpu_data in preemptible code
        MIPS: SMP: Fix deadlock & online race
        MIPS: bpf: Fix a typo in build_one_insn()
        MIPS: microMIPS: Fix incorrect mask in insn_table_MM
        MIPS: Fix CM region target definitions
        MIPS: generic: Fix compilation error from include asm/mips-cpc.h
        MIPS: Fix exception entry when CONFIG_EVA enabled
        MIPS: generic: Fix NI 169445 its build
        Update MIPS email addresses
    • Josh Poimboeuf's avatar
      objtool: Prevent GCC from merging annotate_unreachable(), take 2 · ec1e1b61
      Josh Poimboeuf authored
      This fixes the following warning with GCC 4.6:
        mm/migrate.o: warning: objtool: migrate_misplaced_transhuge_page()+0x71: unreachable instruction
      The problem is that the compiler merged identical annotate_unreachable()
      inline asm blocks, resulting in a missing 'unreachable' annotation.
      This problem happened before, and was partially fixed with:
        3d1e2360 ("objtool: Prevent GCC from merging annotate_unreachable()")
      That commit tried to ensure that each instance of the
      annotate_unreachable() inline asm statement has a unique label.  It used
      the __LINE__ macro to generate the label number.  However, even the line
      number isn't necessarily unique when used in an inline function with
      multiple callers (in this case, __alloc_pages_node()'s use of
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kbuild-all@01.org
      Cc: tipbuild@zytor.com
      Fixes: 3d1e2360 ("objtool: Prevent GCC from merging annotate_unreachable()")
      Link: http://lkml.kernel.org/r/20171103221941.cajpwszir7ujxyc4@trebleSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Andy Lutomirski's avatar
      Revert "x86/mm: Stop calling leave_mm() in idle code" · 67535736
      Andy Lutomirski authored
      This reverts commit 43858b4f.
      The reason I removed the leave_mm() calls in question is because the
      heuristic wasn't needed after that patch.  With the original version
      of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
      kernel thread) due a flush on the loaded mm.
      Unfortunately, that caused architectural issues, so now I've
      reinstated these flushes on non-PCID systems in:
          commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode").
      That, in turn, gives us a power management and occasionally
      performance regression as compared to old kernels: a process that
      goes into a deep idle state on a given CPU and gets its mm flushed
      due to activity on a different CPU will wake the idle CPU.
      Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
      intel_idle state that is likely to cause a TLB flush gets its mm
      switched to init_mm before going idle.
      FWIW, this heuristic is lousy.  Whether we should change CR3 before
      idle isn't a good hint except insofar as the performance hit is a bit
      lower if the TLB is getting flushed by the idle code anyway.  What we
      really want to know is whether we anticipate being idle long enough
      that the mm is likely to be flushed before we wake up.  This is more a
      matter of the expected latency than the idle state that gets chosen.
      This heuristic also completely fails on systems that don't know
      whether the TLB will be flushed (e.g. AMD systems?).  OTOH it may be a
      bit obsolete anyway -- PCID systems don't presently benefit from this
      heuristic at all.
      We also shouldn't do this callback from innermost bit of the idle code
      due to the RCU nastiness it causes.  All the information need is
      available before rcu_idle_enter() needs to happen.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code"
      Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Frank Rowand's avatar