--- /dev/null
+From 3220022038b9a3845eea762af85f1c5694b9f861 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Tue, 11 Oct 2022 20:00:12 +0100
+Subject: ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream.
+
+clang-15's ability to elide loops completely became more aggressive when
+it can deduce how a variable is being updated in a loop. Counting down
+one variable by an increment of another can be replaced by a modulo
+operation.
+
+For 64b variables on 32b ARM EABI targets, this can result in the
+compiler generating calls to __aeabi_uldivmod, which it does for a do
+while loop in float64_rem().
+
+For the kernel, we'd generally prefer that developers not open code 64b
+division via binary / operators and instead use the more explicit
+helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can
+result in linkage failures due to undefined references to
+__aeabi_uldivmod().
+
+While developers can avoid open coding divisions on 64b variables, the
+compiler doesn't know that the Linux kernel has a partial implementation
+of a compiler runtime (--rtlib) to enforce this convention.
+
+It's also undecidable for the compiler whether the code in question
+would be faster to execute the loop vs elide it and do the 64b division.
+
+While I actively avoid using the internal -mllvm command line flags, I
+think we get better code than using barrier() here, which will force
+reloads+spills in the loop for all toolchains.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/1666
+
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/nwfpe/Makefile | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/arm/nwfpe/Makefile
++++ b/arch/arm/nwfpe/Makefile
+@@ -11,3 +11,9 @@ nwfpe-y += fpa11.o fpa11_cpdo.o fpa11
+ entry.o
+
+ nwfpe-$(CONFIG_FPE_NWFPE_XP) += extended_cpdo.o
++
++# Try really hard to avoid generating calls to __aeabi_uldivmod() from
++# float64_rem() due to loop elision.
++ifdef CONFIG_CC_IS_CLANG
++CFLAGS_softfloat.o += -mllvm -replexitval=never
++endif
--- /dev/null
+From a85ceafd41927e41a4103d228a993df7edd8823b Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Fri, 16 Dec 2022 22:03:41 -0300
+Subject: cifs: fix confusing debug message
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit a85ceafd41927e41a4103d228a993df7edd8823b upstream.
+
+Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an
+existing smb session was found, free_xid() would be called and then
+print
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12
+
+Fix this by initialising rc to 0 and then let free_xid() print this
+instead
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0
+
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -3038,7 +3038,7 @@ cifs_set_cifscreds(struct smb_vol *vol _
+ struct cifs_ses *
+ cifs_get_smb_ses(struct TCP_Server_Info *server, struct smb_vol *volume_info)
+ {
+- int rc = -ENOMEM;
++ int rc = 0;
+ unsigned int xid;
+ struct cifs_ses *ses;
+ struct sockaddr_in *addr = (struct sockaddr_in *)&server->dstaddr;
+@@ -3080,6 +3080,8 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ return ses;
+ }
+
++ rc = -ENOMEM;
++
+ cifs_dbg(FYI, "Existing smb sess not found\n");
+ ses = sesInfoAlloc();
+ if (ses == NULL)
--- /dev/null
+From 2bfd81043e944af0e52835ef6d9b41795af22341 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Sun, 11 Dec 2022 13:54:21 -0600
+Subject: cifs: fix missing display of three mount options
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 2bfd81043e944af0e52835ef6d9b41795af22341 upstream.
+
+Three mount options: "tcpnodelay" and "noautotune" and "noblocksend"
+were not displayed when passed in on cifs/smb3 mounts (e.g. displayed
+in /proc/mounts e.g.). No change to defaults so these are not
+displayed if not specified on mount.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/cifsfs.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -619,9 +619,15 @@ cifs_show_options(struct seq_file *s, st
+ seq_printf(s, ",echo_interval=%lu",
+ tcon->ses->server->echo_interval / HZ);
+
+- /* Only display max_credits if it was overridden on mount */
++ /* Only display the following if overridden on mount */
+ if (tcon->ses->server->max_credits != SMB2_MAX_CREDITS_AVAILABLE)
+ seq_printf(s, ",max_credits=%u", tcon->ses->server->max_credits);
++ if (tcon->ses->server->tcp_nodelay)
++ seq_puts(s, ",tcpnodelay");
++ if (tcon->ses->server->noautotune)
++ seq_puts(s, ",noautotune");
++ if (tcon->ses->server->noblocksnd)
++ seq_puts(s, ",noblocksend");
+
+ if (tcon->snapshot_time)
+ seq_printf(s, ",snapshot=%llu", tcon->snapshot_time);
--- /dev/null
+From fd3dc56253acbe9c641a66d312d8393cd55eb04c Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Fri, 9 Dec 2022 10:52:47 -0500
+Subject: ftrace/x86: Add back ftrace_expected for ftrace bug reports
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit fd3dc56253acbe9c641a66d312d8393cd55eb04c upstream.
+
+After someone reported a bug report with a failed modification due to the
+expected value not matching what was found, it came to my attention that
+the ftrace_expected is no longer set when that happens. This makes for
+debugging the issue a bit more difficult.
+
+Set ftrace_expected to the expected code before calling ftrace_bug, so
+that it shows what was expected and why it failed.
+
+Link: https://lore.kernel.org/all/CA+wXwBQ-VhK+hpBtYtyZP-NiX4g8fqRRWithFOHQW-0coQ3vLg@mail.gmail.com/
+Link: https://lore.kernel.org/linux-trace-kernel/20221209105247.01d4e51d@gandalf.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: "x86@kernel.org" <x86@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/ftrace.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -219,7 +219,9 @@ void ftrace_replace_code(int enable)
+
+ ret = ftrace_verify_code(rec->ip, old);
+ if (ret) {
++ ftrace_expected = old;
+ ftrace_bug(ret, rec);
++ ftrace_expected = NULL;
+ return;
+ }
+ }
--- /dev/null
+From 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 6 Oct 2022 00:19:56 +0000
+Subject: KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream.
+
+Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the
+generic "is CRx valid" check, but passes the CR4.VMXE check, and do the
+generic checks _after_ handling the post-VMXON VM-Fail.
+
+The CR4.VMXE check, and all other #UD cases, are special pre-conditions
+that are enforced prior to pivoting on the current VMX mode, i.e. occur
+before interception if VMXON is attempted in VMX non-root mode.
+
+All other CR0/CR4 checks generate #GP and effectively have lower priority
+than the post-VMXON check.
+
+Per the SDM:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD;
+ ELSIF not in VMX operation
+ THEN
+ IF (CPL > 0) or (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+ ELSIF in VMX non-root operation
+ THEN VMexit;
+ ELSIF CPL > 0
+ THEN #GP(0);
+ ELSE VMfail("VMXON executed in VMX root operation");
+ FI;
+
+which, if re-written without ELSIF, yields:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD
+
+ IF in VMX non-root operation
+ THEN VMexit;
+
+ IF CPL > 0
+ THEN #GP(0)
+
+ IF in VMX operation
+ THEN VMfail("VMXON executed in VMX root operation");
+
+ IF (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+
+Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1,
+i.e. there is no need to check the vCPU is not in VMX non-root mode. Add
+a comment to explain why unconditionally forwarding such exits is
+functionally correct.
+
+Reported-by: Eric Li <ercli@ucdavis.edu>
+Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 44 +++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 33 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -4901,24 +4901,35 @@ static int handle_vmon(struct kvm_vcpu *
+ | FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX;
+
+ /*
+- * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks
+- * that have higher priority than VM-Exit (see Intel SDM's pseudocode
+- * for VMXON), as KVM must load valid CR0/CR4 values into hardware while
+- * running the guest, i.e. KVM needs to check the _guest_ values.
++ * Manually check CR4.VMXE checks, KVM must force CR4.VMXE=1 to enter
++ * the guest and so cannot rely on hardware to perform the check,
++ * which has higher priority than VM-Exit (see Intel SDM's pseudocode
++ * for VMXON).
+ *
+- * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and
+- * !COMPATIBILITY modes. KVM may run the guest in VM86 to emulate Real
+- * Mode, but KVM will never take the guest out of those modes.
++ * Rely on hardware for the other pre-VM-Exit checks, CR0.PE=1, !VM86
++ * and !COMPATIBILITY modes. For an unrestricted guest, KVM doesn't
++ * force any of the relevant guest state. For a restricted guest, KVM
++ * does force CR0.PE=1, but only to also force VM86 in order to emulate
++ * Real Mode, and so there's no need to check CR0.PE manually.
+ */
+- if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
+- !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
+
+ /*
+- * CPL=0 and all other checks that are lower priority than VM-Exit must
+- * be checked manually.
++ * The CPL is checked for "not in VMX operation" and for "in VMX root",
++ * and has higher priority than the VM-Fail due to being post-VMXON,
++ * i.e. VMXON #GPs outside of VMX non-root if CPL!=0. In VMX non-root,
++ * VMXON causes VM-Exit and KVM unconditionally forwards VMXON VM-Exits
++ * from L2 to L1, i.e. there's no need to check for the vCPU being in
++ * VMX non-root.
++ *
++ * Forwarding the VM-Exit unconditionally, i.e. without performing the
++ * #UD checks (see above), is functionally ok because KVM doesn't allow
++ * L1 to run L2 without CR4.VMXE=0, and because KVM never modifies L2's
++ * CR0 or CR4, i.e. it's L2's responsibility to emulate #UDs that are
++ * missed by hardware due to shadowing CR0 and/or CR4.
+ */
+ if (vmx_get_cpl(vcpu)) {
+ kvm_inject_gp(vcpu, 0);
+@@ -4928,6 +4939,17 @@ static int handle_vmon(struct kvm_vcpu *
+ if (vmx->nested.vmxon)
+ return nested_vmx_fail(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
+
++ /*
++ * Invalid CR0/CR4 generates #GP. These checks are performed if and
++ * only if the vCPU isn't already in VMX operation, i.e. effectively
++ * have lower priority than the VM-Fail above.
++ */
++ if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
++ !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ kvm_inject_gp(vcpu, 0);
++ return 1;
++ }
++
+ if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES)
+ != VMXON_NEEDED_FEATURES) {
+ kvm_inject_gp(vcpu, 0);
--- /dev/null
+From 6b0d0477fce747d4137aa65856318b55fba72198 Mon Sep 17 00:00:00 2001
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Date: Tue, 26 Apr 2022 06:29:19 +0100
+Subject: media: dvb-core: Fix double free in dvb_register_device()
+
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+
+commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream.
+
+In function dvb_register_device() -> dvb_register_media_device() ->
+dvb_create_media_entity(), dvb->entity is allocated and initialized. If
+the initialization fails, it frees the dvb->entity, and return an error
+code. The caller takes the error code and handles the error by calling
+dvb_media_device_free(), which unregisters the entity and frees the
+field again if it is not NULL. As dvb->entity may not NULLed in
+dvb_create_media_entity() when the allocation of dvbdev->pad fails, a
+double free may occur. This may also cause an Use After free in
+media_device_unregister_entity().
+
+Fix this by storing NULL to dvb->entity when it is freed.
+
+Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp
+Fixes: fcd5ce4b3936 ("media: dvb-core: fix a memory leak bug")
+Cc: stable@vger.kernel.org
+Cc: Wenwen Wang <wenwen@cs.uga.edu>
+Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dvbdev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/dvb-core/dvbdev.c
++++ b/drivers/media/dvb-core/dvbdev.c
+@@ -345,6 +345,7 @@ static int dvb_create_media_entity(struc
+ GFP_KERNEL);
+ if (!dvbdev->pads) {
+ kfree(dvbdev->entity);
++ dvbdev->entity = NULL;
+ return -ENOMEM;
+ }
+ }
--- /dev/null
+From fd3d91ab1c6ab0628fe642dd570b56302c30a792 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 31 Oct 2022 11:02:45 +0100
+Subject: media: dvb-core: Fix UAF due to refcount races at releasing
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream.
+
+The dvb-core tries to sync the releases of opened files at
+dvb_dmxdev_release() with two refcounts: dvbdev->users and
+dvr_dvbdev->users. A problem is present in those two syncs: when yet
+another dvb_demux_open() is called during those sync waits,
+dvb_demux_open() continues to process even if the device is being
+closed. This includes the increment of the former refcount, resulting
+in the leftover refcount after the sync of the latter refcount at
+dvb_dmxdev_release(). It ends up with use-after-free, since the
+function believes that all usages were gone and releases the
+resources.
+
+This patch addresses the problem by adding the check of dmxdev->exit
+flag at dvb_demux_open(), just like dvb_dvr_open() already does. With
+the exit flag check, the second call of dvb_demux_open() fails, hence
+the further corruption can be avoided.
+
+Also for avoiding the races of the dmxdev->exit flag reference, this
+patch serializes the dmxdev->exit set up and the sync waits with the
+dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock,
+dvb_demux_open() (or dvb_dvr_open()) may run concurrently with
+dvb_dmxdev_release(), which allows to skip the exit flag check and
+continue the open process that is being closed.
+
+CVE-2022-41218 is assigned to those bugs above.
+
+Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dmxdev.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/media/dvb-core/dmxdev.c
++++ b/drivers/media/dvb-core/dmxdev.c
+@@ -800,6 +800,11 @@ static int dvb_demux_open(struct inode *
+ if (mutex_lock_interruptible(&dmxdev->mutex))
+ return -ERESTARTSYS;
+
++ if (dmxdev->exit) {
++ mutex_unlock(&dmxdev->mutex);
++ return -ENODEV;
++ }
++
+ for (i = 0; i < dmxdev->filternum; i++)
+ if (dmxdev->filter[i].state == DMXDEV_STATE_FREE)
+ break;
+@@ -1458,7 +1463,10 @@ EXPORT_SYMBOL(dvb_dmxdev_init);
+
+ void dvb_dmxdev_release(struct dmxdev *dmxdev)
+ {
++ mutex_lock(&dmxdev->mutex);
+ dmxdev->exit = 1;
++ mutex_unlock(&dmxdev->mutex);
++
+ if (dmxdev->dvbdev->users > 1) {
+ wait_event(dmxdev->dvbdev->wait_queue,
+ dmxdev->dvbdev->users == 1);
--- /dev/null
+From 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Thu, 27 Oct 2022 17:32:49 +0100
+Subject: rtc: ds1347: fix value written to century register
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 upstream.
+
+In `ds1347_set_time()`, the wrong value is being written to the
+`DS1347_CENTURY_REG` register. It needs to be converted to BCD. Fix
+it.
+
+Fixes: 147dae76dbb9 ("rtc: ds1347: handle century register")
+Cc: <stable@vger.kernel.org> # v5.5+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20221027163249.447416-1-abbotti@mev.co.uk
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-ds1347.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/rtc/rtc-ds1347.c
++++ b/drivers/rtc/rtc-ds1347.c
+@@ -112,7 +112,7 @@ static int ds1347_set_time(struct device
+ return err;
+
+ century = (dt->tm_year / 100) + 19;
+- err = regmap_write(map, DS1347_CENTURY_REG, century);
++ err = regmap_write(map, DS1347_CENTURY_REG, bin2bcd(century));
+ if (err)
+ return err;
+
dm-cache-set-needs_check-flag-after-aborting-metadata.patch
tracing-hist-fix-out-of-bound-write-on-action_data.var_ref_idx.patch
perf-core-call-lsm-hook-after-copying-perf_event_attr.patch
+kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch
+x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch
+ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch
+x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch
+tracing-hist-fix-wrong-return-value-in-parse_action_params.patch
+tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch
+staging-media-tegra-video-fix-chan-mipi-value-on-error.patch
+arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch
+media-dvb-core-fix-double-free-in-dvb_register_device.patch
+media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch
+cifs-fix-confusing-debug-message.patch
+cifs-fix-missing-display-of-three-mount-options.patch
+rtc-ds1347-fix-value-written-to-century-register.patch
--- /dev/null
+From 10b5ce6743c839fa75336042c64e2479caec9430 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Wed, 2 Nov 2022 12:01:01 +0100
+Subject: staging: media: tegra-video: fix chan->mipi value on error
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit 10b5ce6743c839fa75336042c64e2479caec9430 upstream.
+
+chan->mipi takes the return value of tegra_mipi_request() which can be a
+valid pointer or an error. However chan->mipi is checked in several places,
+including error-cleanup code in tegra_csi_channels_cleanup(), as 'if
+(chan->mipi)', which suggests the initial intent was that chan->mipi should
+be either NULL or a valid pointer, never an error. As a consequence,
+cleanup code in case of tegra_mipi_request() errors would dereference an
+invalid pointer.
+
+Fix by ensuring chan->mipi always contains either NULL or a void pointer.
+
+Also add that to the documentation.
+
+Fixes: 523c857e34ce ("media: tegra-video: Add CSI MIPI pads calibration")
+Cc: stable@vger.kernel.org
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/media/tegra-video/csi.c | 1 +
+ drivers/staging/media/tegra-video/csi.h | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/media/tegra-video/csi.c
++++ b/drivers/staging/media/tegra-video/csi.c
+@@ -435,6 +435,7 @@ static int tegra_csi_channel_alloc(struc
+ chan->mipi = tegra_mipi_request(csi->dev, node);
+ if (IS_ERR(chan->mipi)) {
+ ret = PTR_ERR(chan->mipi);
++ chan->mipi = NULL;
+ dev_err(csi->dev, "failed to get mipi device: %d\n", ret);
+ }
+
+--- a/drivers/staging/media/tegra-video/csi.h
++++ b/drivers/staging/media/tegra-video/csi.h
+@@ -50,7 +50,7 @@ struct tegra_csi;
+ * @framerate: active framerate for TPG
+ * @h_blank: horizontal blanking for TPG active format
+ * @v_blank: vertical blanking for TPG active format
+- * @mipi: mipi device for corresponding csi channel pads
++ * @mipi: mipi device for corresponding csi channel pads, or NULL if not applicable (TPG, error)
+ * @pixel_rate: active pixel rate from the sensor on this channel
+ */
+ struct tegra_csi_channel {
--- /dev/null
+From c1ac03af6ed45d05786c219d102f37eb44880f28 Mon Sep 17 00:00:00 2001
+From: Yang Jihong <yangjihong1@huawei.com>
+Date: Tue, 29 Nov 2022 19:30:09 +0800
+Subject: tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
+
+From: Yang Jihong <yangjihong1@huawei.com>
+
+commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream.
+
+print_trace_line may overflow seq_file buffer. If the event is not
+consumed, the while loop keeps peeking this event, causing a infinite loop.
+
+Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 088b1e427dbba ("ftrace: pipe fixes")
+Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6371,7 +6371,20 @@ waitagain:
+
+ ret = print_trace_line(iter);
+ if (ret == TRACE_TYPE_PARTIAL_LINE) {
+- /* don't print partial lines */
++ /*
++ * If one print_trace_line() fills entire trace_seq in one shot,
++ * trace_seq_to_user() will returns -EBUSY because save_len == 0,
++ * In this case, we need to consume it, otherwise, loop will peek
++ * this event next time, resulting in an infinite loop.
++ */
++ if (save_len == 0) {
++ iter->seq.full = 0;
++ trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n");
++ trace_consume(iter);
++ break;
++ }
++
++ /* In other cases, don't print partial lines */
+ iter->seq.seq.len = save_len;
+ break;
+ }
--- /dev/null
+From 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Wed, 7 Dec 2022 11:46:35 +0800
+Subject: tracing/hist: Fix wrong return value in parse_action_params()
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 upstream.
+
+When number of synth fields is more than SYNTH_FIELDS_MAX,
+parse_action_params() should return -EINVAL.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221207034635.2253990-1-zhengyejian1@huawei.com
+
+Cc: <mhiramat@kernel.org>
+Cc: <zanussi@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_hist.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -3115,6 +3115,7 @@ static int parse_action_params(struct tr
+ while (params) {
+ if (data->n_params >= SYNTH_FIELDS_MAX) {
+ hist_err(tr, HIST_ERR_TOO_MANY_PARAMS, 0);
++ ret = -EINVAL;
+ goto out;
+ }
+
--- /dev/null
+From 1993bf97992df2d560287f3c4120eda57426843d Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 19 Dec 2022 23:35:10 +0900
+Subject: x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 1993bf97992df2d560287f3c4120eda57426843d upstream.
+
+Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping
+speculative execution after RET instruction, kprobes always failes to
+check the probed instruction boundary by decoding the function body if
+the probed address is after such sequence. (Note that some conditional
+code blocks will be placed after function return, if compiler decides
+it is not on the hot path.)
+
+This is because kprobes expects kgdb puts the INT3 as a software
+breakpoint and it will replace the original instruction.
+But these INT3 are not such purpose, it doesn't need to recover the
+original instruction.
+
+To avoid this issue, kprobes checks whether the INT3 is owned by
+kgdb or not, and if so, stop decoding and make it fail. The other
+INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be
+treated as a one-byte instruction.
+
+Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation")
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/167146051026.1374301.392728975473572291.stgit@devnote3
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -37,6 +37,7 @@
+ #include <linux/extable.h>
+ #include <linux/kdebug.h>
+ #include <linux/kallsyms.h>
++#include <linux/kgdb.h>
+ #include <linux/ftrace.h>
+ #include <linux/kasan.h>
+ #include <linux/moduleloader.h>
+@@ -306,12 +307,15 @@ static int can_probe(unsigned long paddr
+ kernel_insn_init(&insn, (void *)__addr, MAX_INSN_SIZE);
+ insn_get_length(&insn);
+
++#ifdef CONFIG_KGDB
+ /*
+- * Another debugging subsystem might insert this breakpoint.
+- * In that case, we can't recover it.
++ * If there is a dynamically installed kgdb sw breakpoint,
++ * this function should not be probed.
+ */
+- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE &&
++ kgdb_has_hit_break(addr))
+ return 0;
++#endif
+ addr += insn.length;
+ }
+
--- /dev/null
+From be1b670f61443aa5d0d01782e9b8ea0ee825d018 Mon Sep 17 00:00:00 2001
+From: Ashok Raj <ashok.raj@intel.com>
+Date: Tue, 29 Nov 2022 13:08:27 -0800
+Subject: x86/microcode/intel: Do not retry microcode reloading on the APs
+
+From: Ashok Raj <ashok.raj@intel.com>
+
+commit be1b670f61443aa5d0d01782e9b8ea0ee825d018 upstream.
+
+The retries in load_ucode_intel_ap() were in place to support systems
+with mixed steppings. Mixed steppings are no longer supported and there is
+only one microcode image at a time. Any retries will simply reattempt to
+apply the same image over and over without making progress.
+
+ [ bp: Zap the circumstantial reasoning from the commit message. ]
+
+Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
+Signed-off-by: Ashok Raj <ashok.raj@intel.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -659,7 +659,6 @@ void load_ucode_intel_ap(void)
+ else
+ iup = &intel_ucode_patch;
+
+-reget:
+ if (!*iup) {
+ patch = __load_ucode_intel(&uci);
+ if (!patch)
+@@ -670,12 +669,7 @@ reget:
+
+ uci.mc = *iup;
+
+- if (apply_microcode_early(&uci, true)) {
+- /* Mixed-silicon system? Try to refetch the proper patch: */
+- *iup = NULL;
+-
+- goto reget;
+- }
++ apply_microcode_early(&uci, true);
+ }
+
+ static struct microcode_intel *find_patch(struct ucode_cpu_info *uci)
projects / thirdparty / kernel / stable-queue.git / commitdiff
