linux-stable.git/arch, branch v6.2.2

arm64: dts: uniphier: Fix property name in PXs3 USB node

2023-03-03T10:56:18+00:00

commit 2508d5efd7a588d07915a762e1731173854525f9 upstream.

The property "snps,usb2_gadget_lpm_disable" is wrong.
It should be fixed to "snps,usb2-gadget-lpm-disable".

Cc: stable@vger.kernel.org
Fixes: 19fee1a1096d ("arm64: dts: uniphier: Add USB-device support for PXs3 reference board")
Signed-off-by: Kunihiko Hayashi 
Link: https://lore.kernel.org/r/20230207021429.28925-1-hayashi.kunihiko@socionext.com
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/sm4-gcm - Fix possible crash in GCM cryption

2023-03-03T10:56:16+00:00

commit 4e4a08868f15897ca236528771c3733fded42c62 upstream.

An often overlooked aspect of the skcipher walker API is that an
error is not just indicated by a non-zero return value, but by the
fact that walk->nbytes is zero.

Thus it is an error to call skcipher_walk_done after getting back
walk->nbytes == 0 from the previous interaction with the walker.

This is because when walk->nbytes is zero the walker is left in
an undefined state and any further calls to it may try to free
uninitialised stack memory.

The sm4 arm64 ccm code gets this wrong and ends up calling
skcipher_walk_done even when walk->nbytes is zero.

This patch rewrites the loop in a form that resembles other callers.

Reported-by: Tianjia Zhang 
Fixes: ae1b83c7d572 ("crypto: arm64/sm4 - add CE implementation for GCM mode")
Signed-off-by: Herbert Xu 
Tested-by: Tianjia Zhang 
Signed-off-by: Herbert Xu 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

x86/static_call: Add support for Jcc tail-calls

2023-02-25T10:13:29+00:00

commit 923510c88d2b7d947c4217835fd9ca6bd65cc56c upstream.

Clang likes to create conditional tail calls like:

  0000000000000350 :
  350:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1) 351: R_X86_64_NONE      __fentry__-0x4
  355:       48 83 bf 20 01 00 00 00         cmpq   $0x0,0x120(%rdi)
  35d:       0f 85 00 00 00 00       jne    363      35f: R_X86_64_PLT32     __SCT__amd_pmu_branch_add-0x4
  363:       e9 00 00 00 00          jmp    368      364: R_X86_64_PLT32     __x86_return_thunk-0x4

Where 0x35d is a static call site that's turned into a conditional
tail-call using the Jcc class of instructions.

Teach the in-line static call text patching about this.

Notably, since there is no conditional-ret, in that case patch the Jcc
to point at an empty stub function that does the ret -- or the return
thunk when needed.

Reported-by: "Erhard F." 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/Y9Kdg9QjHkr9G5b5@hirez.programming.kicks-ass.net
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions

2023-02-25T10:13:28+00:00

commit ac0ee0a9560c97fa5fe1409e450c2425d4ebd17a upstream.

In order to re-write Jcc.d32 instructions text_poke_bp() needs to be
taught about them.

The biggest hurdle is that the whole machinery is currently made for 5
byte instructions and extending this would grow struct text_poke_loc
which is currently a nice 16 bytes and used in an array.

However, since text_poke_loc contains a full copy of the (s32)
displacement, it is possible to map the Jcc.d32 2 byte opcodes to
Jcc.d8 1 byte opcode for the int3 emulation.

This then leaves the replacement bytes; fudge that by only storing the
last 5 bytes and adding the rule that 'length == 6' instruction will
be prefixed with a 0x0f byte.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20230123210607.115718513@infradead.org
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

x86/alternatives: Introduce int3_emulate_jcc()

2023-02-25T10:13:28+00:00

commit db7adcfd1cec4e95155e37bc066fddab302c6340 upstream.

Move the kprobe Jcc emulation into int3_emulate_jcc() so it can be
used by more code -- specifically static_call() will need this.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20230123210607.057678245@infradead.org
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'x86-urgent-2023-02-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2023-02-19T01:57:16+00:00

Pull x86 fix from Thomas Gleixner:
 "A single fix for x86.

  Revert the recent change to the MTRR code which aimed to support
  SEV-SNP guests on Hyper-V. It caused a regression on XEN Dom0 kernels.

  The underlying issue of MTTR (mis)handling in the x86 code needs some
  deeper investigation and is definitely not 6.2 material"

* tag 'x86-urgent-2023-02-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mtrr: Revert 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2023-02-18T19:07:32+00:00

Pull kvm/x86 fixes from Paolo Bonzini:

 - zero all padding for KVM_GET_DEBUGREGS

 - fix rST warning

 - disable vPMU support on hybrid CPUs

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  kvm: initialize all of the kvm_debugregs structure before sending it to userspace
  perf/x86: Refuse to export capabilities for hybrid PMUs
  KVM: x86/pmu: Disable vPMU support on hybrid CPUs (host PMUs)
  Documentation/hw-vuln: Fix rST warning

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2023-02-18T18:10:49+00:00

Pull arm64 regression fix from Will Deacon:
 "Apologies for the _extremely_ late pull request here, but we had a
  'perf' (i.e. CPU PMU) regression on the Apple M1 reported on Wednesday
  [1] which was introduced by bd2756811766 ("perf: Rewrite core context
  handling") during the merge window.

  Mark and I looked into this and noticed an additional problem caused
  by the same patch, where the 'CHAIN' event (used to combine two
  adjacent 32-bit counters into a single 64-bit counter) was not being
  filtered correctly. Mark posted a series on Thursday [2] which
  addresses both of these regressions and I queued it the same day.

  The changes are small, self-contained and have been confirmed to fix
  the original regression.

  Summary:

   - Fix 'perf' regression for non-standard CPU PMU hardware (i.e. Apple
     M1)"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: perf: reject CHAIN events at creation time
  arm_pmu: fix event CPU filtering

Merge tag 'powerpc-6.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2023-02-17T22:53:37+00:00

Pull powerpc fix from Michael Ellerman:

 - Prevent fallthrough to hash TLB flush when using radix

Thanks to Benjamin Gray and Erhard Furtner.

* tag 'powerpc-6.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/64s: Prevent fallthrough to hash TLB flush when using radix

powerpc/64s: Prevent fallthrough to hash TLB flush when using radix

2023-02-17T01:30:56+00:00

In the fix reconnecting hash__tlb_flush() to tlb_flush() the
void return on radix__tlb_flush() was not restored and subsequently
falls through to the restored hash__tlb_flush().

Guard hash__tlb_flush() under an else to prevent this.

Fixes: 1665c027afb2 ("powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()")
Reported-by: "Erhard F." 
Suggested-by: Christophe Leroy 
Signed-off-by: Benjamin Gray 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20230217011434.115554-1-bgray@linux.ibm.com