1. 14 Aug, 2020 1 commit
    • Eric Dumazet's avatar
      x86/fsgsbase/64: Fix NULL deref in 86_fsgsbase_read_task · 8ab49526
      Eric Dumazet authored
      syzbot found its way in 86_fsgsbase_read_task() and triggered this oops:
      
         KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
         CPU: 0 PID: 6866 Comm: syz-executor262 Not tainted 5.8.0-syzkaller #0
         RIP: 0010:x86_fsgsbase_read_task+0x16d/0x310 arch/x86/kernel/process_64.c:393
         Call Trace:
           putreg32+0x3ab/0x530 arch/x86/kernel/ptrace.c:876
           genregs32_set arch/x86/kernel/ptrace.c:1026 [inline]
           genregs32_set+0xa4/0x100 arch/x86/kernel/ptrace.c:1006
           copy_regset_from_user include/linux/regset.h:326 [inline]
           ia32_arch_ptrace arch/x86/kernel/ptrace.c:1061 [inline]
           compat_arch_ptrace+0x36c/0xd90 arch/x86/kernel/ptrace.c:1198
           __do_compat_sys_ptrace kernel/ptrace.c:1420 [inline]
           __se_compat_sys_ptrace kernel/ptrace.c:1389 [inline]
           __ia32_compat_sys_ptrace+0x220/0x2f0 kernel/ptrace.c:1389
           do_syscall_32_irqs_on arch/x86/entry/common.c:84 [inline]
           __do_fast_syscall_32+0x57/0x80 arch/x86/entry/common.c:126
           do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:149
           entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
      
      This can happen if ptrace() or sigreturn() pokes an LDT selector into FS
      or GS for a task with no LDT and something tries to read the base before
      a return to usermode notices the bad selector and fixes it.
      
      The fix is to make sure ldt pointer is not NULL.
      
      Fixes: 07e1d88a
      
       ("x86/fsgsbase/64: Fix ptrace() to read the FS/GS base accurately")
      Co-developed-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Chang S. Bae <chang.seok.bae@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Markus T Metzger <markus.t.metzger@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ab49526
  2. 13 Aug, 2020 1 commit
  3. 11 Aug, 2020 2 commits
  4. 07 Aug, 2020 1 commit
    • Mike Rapoport's avatar
      mm: remove unneeded includes of <asm/pgalloc.h> · ca15ca40
      Mike Rapoport authored
      
      
      Patch series "mm: cleanup usage of <asm/pgalloc.h>"
      
      Most architectures have very similar versions of pXd_alloc_one() and
      pXd_free_one() for intermediate levels of page table.  These patches add
      generic versions of these functions in <asm-generic/pgalloc.h> and enable
      use of the generic functions where appropriate.
      
      In addition, functions declared and defined in <asm/pgalloc.h> headers are
      used mostly by core mm and early mm initialization in arch and there is no
      actual reason to have the <asm/pgalloc.h> included all over the place.
      The first patch in this series removes unneeded includes of
      <asm/pgalloc.h>
      
      In the end it didn't work out as neatly as I hoped and moving
      pXd_alloc_track() definitions to <asm-generic/pgalloc.h> would require
      unnecessary changes to arches that have custom page table allocations, so
      I've decided to move lib/ioremap.c to mm/ and make pgalloc-track.h local
      to mm/.
      
      This patch (of 8):
      
      In most cases <asm/pgalloc.h> header is required only for allocations of
      page table memory.  Most of the .c files that include that header do not
      use symbols declared in <asm/pgalloc.h> and do not require that header.
      
      As for the other header files that used to include <asm/pgalloc.h>, it is
      possible to move that include into the .c file that actually uses symbols
      from <asm/pgalloc.h> and drop the include from the header file.
      
      The process was somewhat automated using
      
      	sed -i -E '/[<"]asm\/pgalloc\.h/d' \
                      $(grep -L -w -f /tmp/xx \
                              $(git grep -E -l '[<"]asm/pgalloc\.h'))
      
      where /tmp/xx contains all the symbols defined in
      arch/*/include/asm/pgalloc.h.
      
      [rppt@linux.ibm.com: fix powerpc warning]
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarPekka Enberg <penberg@kernel.org>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>	[m68k]
      Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Link: http://lkml.kernel.org/r/20200627143453.31835-1-rppt@kernel.org
      Link: http://lkml.kernel.org/r/20200627143453.31835-2-rppt@kernel.org
      
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ca15ca40
  5. 06 Aug, 2020 8 commits
  6. 30 Jul, 2020 1 commit
  7. 29 Jul, 2020 1 commit
  8. 27 Jul, 2020 3 commits
    • Al Viro's avatar
      x86: switch to ->regset_get() · 0557d64d
      Al Viro authored
      
      
      	All instances of ->get() in arch/x86 switched; that might or might
      not be worth splitting up.  Notes:
      
      	* for xstateregs_get() the amount we want to store is determined at
      the boot time; see init_xstate_size() and update_regset_xstate_info() for
      details.  task->thread.fpu.state.xsave ends with a flexible array member and
      the amount of data in it depends upon the FPU features supported/enabled.
      
      	* fpregs_get() writes slightly less than full ->thread.fpu.state.fsave
      (the last word is not copied); we pass the full size of state.fsave and let
      membuf_write() trim to the amount declared by regset - __regset_get() will
      make sure that the space in buffer is no more than that.
      
      	* copy_xstate_to_user() and its helpers are gone now.
      
      	* fpregs_soft_get() was getting user_regset_copyout() arguments
      wrong.  Since "x86: x86 user_regset math_emu" back in 2008...  I really
      doubt that it's worth splitting out for -stable, though - you need
      a 486SX box for that to trigger...
      
      [Kevin's braino fix for copy_xstate_to_kernel() essentially duplicated here]
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      0557d64d
    • Thomas Gleixner's avatar
      genirq/affinity: Make affinity setting if activated opt-in · f0c7baca
      Thomas Gleixner authored
      John reported that on a RK3288 system the perf per CPU interrupts are all
      affine to CPU0 and provided the analysis:
      
       "It looks like what happens is that because the interrupts are not per-CPU
        in the hardware, armpmu_request_irq() calls irq_force_affinity() while
        the interrupt is deactivated and then request_irq() with IRQF_PERCPU |
        IRQF_NOBALANCING.  
      
        Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls
        irq_setup_affinity() which returns early because IRQF_PERCPU and
        IRQF_NOBALANCING are set, leaving the interrupt on its original CPU."
      
      This was broken by the recent commit which blocked interrupt affinity
      setting in hardware before activation of the interrupt. While this works in
      general, it does not work for this particular case. As contrary to the
      initial analysis not all interrupt chip drivers implement an activate
      callback, the safe cure is to make the deferred interrupt affinity setting
      at activation time opt-in.
      
      Implement the necessary core logic and make the two irqchip implementations
      for which this is required opt-in. In hindsight this would have been the
      right thing to do, but ...
      
      Fixes: baedb87d
      
       ("genirq/affinity: Handle affinity setting on inactive interrupts correctly")
      Reported-by: default avatarJohn Keeping <john@metanate.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarMarc Zyngier <maz@kernel.org>
      Acked-by: default avatarMarc Zyngier <maz@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de
      f0c7baca
    • Ricardo Neri's avatar
      x86/cpu: Relocate sync_core() to sync_core.h · 9998a983
      Ricardo Neri authored
      
      
      Having sync_core() in processor.h is problematic since it is not possible
      to check for hardware capabilities via the *cpu_has() family of macros.
      The latter needs the definitions in processor.h.
      
      It also looks more intuitive to relocate the function to sync_core.h.
      
      This changeset does not make changes in functionality.
      
      Signed-off-by: default avatarRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
      Link: https://lore.kernel.org/r/20200727043132.15082-3-ricardo.neri-calderon@linux.intel.com
      9998a983
  9. 25 Jul, 2020 1 commit
  10. 24 Jul, 2020 4 commits
  11. 22 Jul, 2020 8 commits
  12. 21 Jul, 2020 1 commit
  13. 20 Jul, 2020 1 commit
    • Kevin Buettner's avatar
      copy_xstate_to_kernel: Fix typo which caused GDB regression · 5714ee50
      Kevin Buettner authored
      
      
      This fixes a regression encountered while running the
      gdb.base/corefile.exp test in GDB's test suite.
      
      In my testing, the typo prevented the sw_reserved field of struct
      fxregs_state from being output to the kernel XSAVES area.  Thus the
      correct mask corresponding to XCR0 was not present in the core file for
      GDB to interrogate, resulting in the following behavior:
      
         [kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/corefile/corefile testsuite/outputs/gdb.base/corefile/corefile.core
         Reading symbols from testsuite/outputs/gdb.base/corefile/corefile...
         [New LWP 232880]
      
         warning: Unexpected size of section `.reg-xstate/232880' in core file.
      
      With the typo fixed, the test works again as expected.
      
      Signed-off-by: default avatarKevin Buettner <kevinb@redhat.com>
      Fixes: 9e463654
      
       ("copy_xstate_to_kernel(): don't leave parts of destination uninitialized")
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5714ee50
  14. 18 Jul, 2020 1 commit
  15. 17 Jul, 2020 3 commits
  16. 16 Jul, 2020 1 commit
  17. 14 Jul, 2020 1 commit
  18. 10 Jul, 2020 1 commit