]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 14 Aug 2022 10:24:55 +0000 (12:24 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 14 Aug 2022 10:24:55 +0000 (12:24 +0200)
added patches:
cifs-fix-lock-length-calculation.patch
ftrace-x86-add-back-ftrace_expected-assignment.patch
input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch
posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch
smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch
x86-bugs-enable-stibp-for-ibpb-mitigated-retbleed.patch
x86-kprobes-update-kcb-status-flag-after-singlestepping.patch
x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch

queue-5.19/cifs-fix-lock-length-calculation.patch [new file with mode: 0644]
queue-5.19/ftrace-x86-add-back-ftrace_expected-assignment.patch [new file with mode: 0644]
queue-5.19/input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch [new file with mode: 0644]
queue-5.19/posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch [new file with mode: 0644]
queue-5.19/series
queue-5.19/smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch [new file with mode: 0644]
queue-5.19/x86-bugs-enable-stibp-for-ibpb-mitigated-retbleed.patch [new file with mode: 0644]
queue-5.19/x86-kprobes-update-kcb-status-flag-after-singlestepping.patch [new file with mode: 0644]
queue-5.19/x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch [new file with mode: 0644]

diff --git a/queue-5.19/cifs-fix-lock-length-calculation.patch b/queue-5.19/cifs-fix-lock-length-calculation.patch
new file mode 100644 (file)
index 0000000..a4d26ad
--- /dev/null
@@ -0,0 +1,106 @@
+From 773891ffd4d628d05c4e22f34541e4779ee7a076 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Mon, 8 Aug 2022 13:41:18 -0300
+Subject: cifs: fix lock length calculation
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit 773891ffd4d628d05c4e22f34541e4779ee7a076 upstream.
+
+The lock length was wrongly set to 0 when fl_end == OFFSET_MAX, thus
+failing to lock the whole file when l_start=0 and l_len=0.
+
+This fixes test 2 from cthon04.
+
+Before patch:
+
+$ ./cthon04/lock/tlocklfs -t 2 /mnt
+
+Creating parent/child synchronization pipes.
+
+Test #1 - Test regions of an unlocked file.
+        Parent: 1.1  - F_TEST  [               0,               1] PASSED.
+        Parent: 1.2  - F_TEST  [               0,          ENDING] PASSED.
+        Parent: 1.3  - F_TEST  [               0,7fffffffffffffff] PASSED.
+        Parent: 1.4  - F_TEST  [               1,               1] PASSED.
+        Parent: 1.5  - F_TEST  [               1,          ENDING] PASSED.
+        Parent: 1.6  - F_TEST  [               1,7fffffffffffffff] PASSED.
+        Parent: 1.7  - F_TEST  [7fffffffffffffff,               1] PASSED.
+        Parent: 1.8  - F_TEST  [7fffffffffffffff,          ENDING] PASSED.
+        Parent: 1.9  - F_TEST  [7fffffffffffffff,7fffffffffffffff] PASSED.
+
+Test #2 - Try to lock the whole file.
+        Parent: 2.0  - F_TLOCK [               0,          ENDING] PASSED.
+        Child:  2.1  - F_TEST  [               0,               1] FAILED!
+        Child:  **** Expected EACCES, returned success...
+        Child:  **** Probably implementation error.
+
+**  CHILD pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).
+        Parent: Child died
+
+** PARENT pass 1 results: 10/10 pass, 0/0 warn, 0/0 fail (pass/total).
+
+After patch:
+
+$ ./cthon04/lock/tlocklfs -t 2 /mnt
+
+Creating parent/child synchronization pipes.
+
+Test #2 - Try to lock the whole file.
+        Parent: 2.0  - F_TLOCK [               0,          ENDING] PASSED.
+        Child:  2.1  - F_TEST  [               0,               1] PASSED.
+        Child:  2.2  - F_TEST  [               0,          ENDING] PASSED.
+        Child:  2.3  - F_TEST  [               0,7fffffffffffffff] PASSED.
+        Child:  2.4  - F_TEST  [               1,               1] PASSED.
+        Child:  2.5  - F_TEST  [               1,          ENDING] PASSED.
+        Child:  2.6  - F_TEST  [               1,7fffffffffffffff] PASSED.
+        Child:  2.7  - F_TEST  [7fffffffffffffff,               1] PASSED.
+        Child:  2.8  - F_TEST  [7fffffffffffffff,          ENDING] PASSED.
+        Child:  2.9  - F_TEST  [7fffffffffffffff,7fffffffffffffff] PASSED.
+        Parent: 2.10 - F_ULOCK [               0,          ENDING] PASSED.
+
+** PARENT pass 1 results: 2/2 pass, 0/0 warn, 0/0 fail (pass/total).
+
+**  CHILD pass 1 results: 9/9 pass, 0/0 warn, 0/0 fail (pass/total).
+
+Fixes: d80c69846ddf ("cifs: fix signed integer overflow when fl_end is OFFSET_MAX")
+Reported-by: Xiaoli Feng <xifeng@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/cifsglob.h |    4 ++--
+ fs/cifs/file.c     |    6 +++---
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/cifs/cifsglob.h
++++ b/fs/cifs/cifsglob.h
+@@ -2085,9 +2085,9 @@ static inline bool cifs_is_referral_serv
+       return is_tcon_dfs(tcon) || (ref && (ref->flags & DFSREF_REFERRAL_SERVER));
+ }
+-static inline u64 cifs_flock_len(struct file_lock *fl)
++static inline u64 cifs_flock_len(const struct file_lock *fl)
+ {
+-      return fl->fl_end == OFFSET_MAX ? 0 : fl->fl_end - fl->fl_start + 1;
++      return (u64)fl->fl_end - fl->fl_start + 1;
+ }
+ static inline size_t ntlmssp_workstation_name_size(const struct cifs_ses *ses)
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -1861,9 +1861,9 @@ int cifs_lock(struct file *file, int cmd
+       rc = -EACCES;
+       xid = get_xid();
+-      cifs_dbg(FYI, "Lock parm: 0x%x flockflags: 0x%x flocktype: 0x%x start: %lld end: %lld\n",
+-               cmd, flock->fl_flags, flock->fl_type,
+-               flock->fl_start, flock->fl_end);
++      cifs_dbg(FYI, "%s: %pD2 cmd=0x%x type=0x%x flags=0x%x r=%lld:%lld\n", __func__, file, cmd,
++               flock->fl_flags, flock->fl_type, (long long)flock->fl_start,
++               (long long)flock->fl_end);
+       cfile = (struct cifsFileInfo *)file->private_data;
+       tcon = tlink_tcon(cfile->tlink);
diff --git a/queue-5.19/ftrace-x86-add-back-ftrace_expected-assignment.patch b/queue-5.19/ftrace-x86-add-back-ftrace_expected-assignment.patch
new file mode 100644 (file)
index 0000000..c81d6f5
--- /dev/null
@@ -0,0 +1,44 @@
+From ac6c1b2ca77e722a1e5d651f12f437f2f237e658 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Tue, 26 Jul 2022 10:18:51 -0400
+Subject: ftrace/x86: Add back ftrace_expected assignment
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit ac6c1b2ca77e722a1e5d651f12f437f2f237e658 upstream.
+
+When a ftrace_bug happens (where ftrace fails to modify a location) it is
+helpful to have what was at that location as well as what was expected to
+be there.
+
+But with the conversion to text_poke() the variable that assigns the
+expected for debugging was dropped. Unfortunately, I noticed this when I
+needed it. Add it back.
+
+Link: https://lkml.kernel.org/r/20220726101851.069d2e70@gandalf.local.home
+
+Cc: "x86@kernel.org" <x86@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Andrew Morton <akpm@linux-foundation.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 |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -91,6 +91,7 @@ static int ftrace_verify_code(unsigned l
+       /* Make sure it is what we expect it to be */
+       if (memcmp(cur_code, old_code, MCOUNT_INSN_SIZE) != 0) {
++              ftrace_expected = old_code;
+               WARN_ON(1);
+               return -EINVAL;
+       }
diff --git a/queue-5.19/input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch b/queue-5.19/input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch
new file mode 100644 (file)
index 0000000..a83179a
--- /dev/null
@@ -0,0 +1,35 @@
+From e61b3125a4f036b3c6b87ffd656fc1ab00440ae9 Mon Sep 17 00:00:00 2001
+From: Xie Shaowen <studentxswpy@163.com>
+Date: Tue, 2 Aug 2022 15:20:33 +0800
+Subject: Input: gscps2 - check return value of ioremap() in gscps2_probe()
+
+From: Xie Shaowen <studentxswpy@163.com>
+
+commit e61b3125a4f036b3c6b87ffd656fc1ab00440ae9 upstream.
+
+The function ioremap() in gscps2_probe() can fail, so
+its return value should be checked.
+
+Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache")
+Cc: <stable@vger.kernel.org> # v5.6+
+Reported-by: Hacash Robot <hacashRobot@santino.com>
+Signed-off-by: Xie Shaowen <studentxswpy@163.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/gscps2.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/input/serio/gscps2.c
++++ b/drivers/input/serio/gscps2.c
+@@ -350,6 +350,10 @@ static int __init gscps2_probe(struct pa
+       ps2port->port = serio;
+       ps2port->padev = dev;
+       ps2port->addr = ioremap(hpa, GSC_STATUS + 4);
++      if (!ps2port->addr) {
++              ret = -ENOMEM;
++              goto fail_nomem;
++      }
+       spin_lock_init(&ps2port->lock);
+       gscps2_reset(ps2port);
diff --git a/queue-5.19/posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch b/queue-5.19/posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch
new file mode 100644 (file)
index 0000000..df676e5
--- /dev/null
@@ -0,0 +1,47 @@
+From e362359ace6f87c201531872486ff295df306d13 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Date: Tue, 9 Aug 2022 14:07:51 -0300
+Subject: posix-cpu-timers: Cleanup CPU timers before freeing them during exec
+
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+
+commit e362359ace6f87c201531872486ff295df306d13 upstream.
+
+Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a
+task") started looking up tasks by PID when deleting a CPU timer.
+
+When a non-leader thread calls execve, it will switch PIDs with the leader
+process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find
+the task because the timer still points out to the old PID.
+
+That means that armed timers won't be disarmed, that is, they won't be
+removed from the timerqueue_list. exit_itimers will still release their
+memory, and when that list is later processed, it leads to a
+use-after-free.
+
+Clean up the timers from the de-threaded task before freeing them. This
+prevents a reported use-after-free.
+
+Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task")
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220809170751.164716-1-cascardo@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/exec.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -1301,6 +1301,9 @@ int begin_new_exec(struct linux_binprm *
+       bprm->mm = NULL;
+ #ifdef CONFIG_POSIX_TIMERS
++      spin_lock_irq(&me->sighand->siglock);
++      posix_cpu_timers_exit(me);
++      spin_unlock_irq(&me->sighand->siglock);
+       exit_itimers(me);
+       flush_itimer_signals();
+ #endif
index d43b08a27035ab7ad3561dccbd2c3f18b8110a92..af2e1df88050cf996b049c41d6a8c21ffa7cef46 100644 (file)
@@ -1044,3 +1044,11 @@ scsi-qla2xxx-wind-down-adapter-after-pcie-error.patch
 scsi-qla2xxx-fix-losing-fcp-2-targets-on-long-port-disable-with-i-os.patch
 scsi-qla2xxx-fix-losing-target-when-it-reappears-during-delete.patch
 scsi-qla2xxx-fix-losing-fcp-2-targets-during-port-perturbation-tests.patch
+cifs-fix-lock-length-calculation.patch
+x86-bugs-enable-stibp-for-ibpb-mitigated-retbleed.patch
+ftrace-x86-add-back-ftrace_expected-assignment.patch
+x86-kprobes-update-kcb-status-flag-after-singlestepping.patch
+x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch
+smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch
+posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch
+input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch
diff --git a/queue-5.19/smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch b/queue-5.19/smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch
new file mode 100644 (file)
index 0000000..c3133b7
--- /dev/null
@@ -0,0 +1,66 @@
+From 9e31678fb403eae0f4fe37c6374be098835c73cd Mon Sep 17 00:00:00 2001
+From: Bharath SM <bharathsm@microsoft.com>
+Date: Thu, 11 Aug 2022 19:46:11 +0000
+Subject: SMB3: fix lease break timeout when multiple deferred close handles for the same file.
+
+From: Bharath SM <bharathsm@microsoft.com>
+
+commit 9e31678fb403eae0f4fe37c6374be098835c73cd upstream.
+
+Solution is to send lease break ack immediately even in case of
+deferred close handles to avoid lease break request timing out
+and let deferred closed handle gets closed as scheduled.
+Later patches could optimize cases where we then close some
+of these handles sooner for the cases where lease break is to 'none'
+
+Cc: stable@kernel.org
+Signed-off-by: Bharath SM <bharathsm@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/file.c |   20 +-------------------
+ 1 file changed, 1 insertion(+), 19 deletions(-)
+
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -4811,8 +4811,6 @@ void cifs_oplock_break(struct work_struc
+       struct TCP_Server_Info *server = tcon->ses->server;
+       int rc = 0;
+       bool purge_cache = false;
+-      bool is_deferred = false;
+-      struct cifs_deferred_close *dclose;
+       wait_on_bit(&cinode->flags, CIFS_INODE_PENDING_WRITERS,
+                       TASK_UNINTERRUPTIBLE);
+@@ -4849,22 +4847,6 @@ void cifs_oplock_break(struct work_struc
+ oplock_break_ack:
+       /*
+-       * When oplock break is received and there are no active
+-       * file handles but cached, then schedule deferred close immediately.
+-       * So, new open will not use cached handle.
+-       */
+-      spin_lock(&CIFS_I(inode)->deferred_lock);
+-      is_deferred = cifs_is_deferred_close(cfile, &dclose);
+-      spin_unlock(&CIFS_I(inode)->deferred_lock);
+-      if (is_deferred &&
+-          cfile->deferred_close_scheduled &&
+-          delayed_work_pending(&cfile->deferred)) {
+-              if (cancel_delayed_work(&cfile->deferred)) {
+-                      _cifsFileInfo_put(cfile, false, false);
+-                      goto oplock_break_done;
+-              }
+-      }
+-      /*
+        * releasing stale oplock after recent reconnect of smb session using
+        * a now incorrect file handle is not a data integrity issue but do
+        * not bother sending an oplock release if session to server still is
+@@ -4875,7 +4857,7 @@ oplock_break_ack:
+                                                            cinode);
+               cifs_dbg(FYI, "Oplock release rc = %d\n", rc);
+       }
+-oplock_break_done:
++
+       _cifsFileInfo_put(cfile, false /* do not wait for ourself */, false);
+       cifs_done_oplock_break(cinode);
+ }
diff --git a/queue-5.19/x86-bugs-enable-stibp-for-ibpb-mitigated-retbleed.patch b/queue-5.19/x86-bugs-enable-stibp-for-ibpb-mitigated-retbleed.patch
new file mode 100644 (file)
index 0000000..38c788f
--- /dev/null
@@ -0,0 +1,115 @@
+From e6cfcdda8cbe81eaf821c897369a65fec987b404 Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Mon, 8 Aug 2022 09:32:33 -0500
+Subject: x86/bugs: Enable STIBP for IBPB mitigated RETBleed
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit e6cfcdda8cbe81eaf821c897369a65fec987b404 upstream.
+
+AMD's "Technical Guidance for Mitigating Branch Type Confusion,
+Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
+Privileged Mode Entry / SMT Safety" says:
+
+  Similar to the Jmp2Ret mitigation, if the code on the sibling thread
+  cannot be trusted, software should set STIBP to 1 or disable SMT to
+  ensure SMT safety when using this mitigation.
+
+So, like already being done for retbleed=unret, and now also for
+retbleed=ibpb, force STIBP on machines that have it, and report its SMT
+vulnerability status accordingly.
+
+ [ bp: Remove the "we" and remove "[AMD]" applicability parameter which
+   doesn't work here. ]
+
+Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
+Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/admin-guide/kernel-parameters.txt |   29 +++++++++++++++++-------
+ arch/x86/kernel/cpu/bugs.c                      |   10 ++++----
+ 2 files changed, 27 insertions(+), 12 deletions(-)
+
+--- a/Documentation/admin-guide/kernel-parameters.txt
++++ b/Documentation/admin-guide/kernel-parameters.txt
+@@ -5203,20 +5203,33 @@
+                       Speculative Code Execution with Return Instructions)
+                       vulnerability.
++                      AMD-based UNRET and IBPB mitigations alone do not stop
++                      sibling threads from influencing the predictions of other
++                      sibling threads. For that reason, STIBP is used on pro-
++                      cessors that support it, and mitigate SMT on processors
++                      that don't.
++
+                       off          - no mitigation
+                       auto         - automatically select a migitation
+                       auto,nosmt   - automatically select a mitigation,
+                                      disabling SMT if necessary for
+                                      the full mitigation (only on Zen1
+                                      and older without STIBP).
+-                      ibpb         - mitigate short speculation windows on
+-                                     basic block boundaries too. Safe, highest
+-                                     perf impact.
+-                      unret        - force enable untrained return thunks,
+-                                     only effective on AMD f15h-f17h
+-                                     based systems.
+-                      unret,nosmt  - like unret, will disable SMT when STIBP
+-                                     is not available.
++                      ibpb         - On AMD, mitigate short speculation
++                                     windows on basic block boundaries too.
++                                     Safe, highest perf impact. It also
++                                     enables STIBP if present. Not suitable
++                                     on Intel.
++                      ibpb,nosmt   - Like "ibpb" above but will disable SMT
++                                     when STIBP is not available. This is
++                                     the alternative for systems which do not
++                                     have STIBP.
++                      unret        - Force enable untrained return thunks,
++                                     only effective on AMD f15h-f17h based
++                                     systems.
++                      unret,nosmt  - Like unret, but will disable SMT when STIBP
++                                     is not available. This is the alternative for
++                                     systems which do not have STIBP.
+                       Selecting 'auto' will choose a mitigation method at run
+                       time according to the CPU.
+--- a/arch/x86/kernel/cpu/bugs.c
++++ b/arch/x86/kernel/cpu/bugs.c
+@@ -152,7 +152,7 @@ void __init check_bugs(void)
+       /*
+        * spectre_v2_user_select_mitigation() relies on the state set by
+        * retbleed_select_mitigation(); specifically the STIBP selection is
+-       * forced for UNRET.
++       * forced for UNRET or IBPB.
+        */
+       spectre_v2_user_select_mitigation();
+       ssb_select_mitigation();
+@@ -1179,7 +1179,8 @@ spectre_v2_user_select_mitigation(void)
+           boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON))
+               mode = SPECTRE_V2_USER_STRICT_PREFERRED;
+-      if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET) {
++      if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET ||
++          retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
+               if (mode != SPECTRE_V2_USER_STRICT &&
+                   mode != SPECTRE_V2_USER_STRICT_PREFERRED)
+                       pr_info("Selecting STIBP always-on mode to complement retbleed mitigation\n");
+@@ -2360,10 +2361,11 @@ static ssize_t srbds_show_state(char *bu
+ static ssize_t retbleed_show_state(char *buf)
+ {
+-      if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET) {
++      if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET ||
++          retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
+           if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+               boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
+-                  return sprintf(buf, "Vulnerable: untrained return thunk on non-Zen uarch\n");
++                  return sprintf(buf, "Vulnerable: untrained return thunk / IBPB on non-AMD based uarch\n");
+           return sprintf(buf, "%s; SMT %s\n",
+                          retbleed_strings[retbleed_mitigation],
diff --git a/queue-5.19/x86-kprobes-update-kcb-status-flag-after-singlestepping.patch b/queue-5.19/x86-kprobes-update-kcb-status-flag-after-singlestepping.patch
new file mode 100644 (file)
index 0000000..5905f73
--- /dev/null
@@ -0,0 +1,62 @@
+From dec8784c9088b131a1523f582c2194cfc8107dc0 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Tue, 2 Aug 2022 15:04:16 +0900
+Subject: x86/kprobes: Update kcb status flag after singlestepping
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit dec8784c9088b131a1523f582c2194cfc8107dc0 upstream.
+
+Fix kprobes to update kcb (kprobes control block) status flag to
+KPROBE_HIT_SSDONE even if the kp->post_handler is not set.
+
+This bug may cause a kernel panic if another INT3 user runs right
+after kprobes because kprobe_int3_handler() misunderstands the
+INT3 is kprobe's single stepping INT3.
+
+Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
+Reported-by: Daniel Müller <deso@posteo.net>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Daniel Müller <deso@posteo.net>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20220727210136.jjgc3lpqeq42yr3m@muellerd-fedora-PC2BDTX9
+Link: https://lore.kernel.org/r/165942025658.342061.12452378391879093249.stgit@devnote2
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c |   18 +++++++++++-------
+ 1 file changed, 11 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -814,16 +814,20 @@ set_current_kprobe(struct kprobe *p, str
+ static void kprobe_post_process(struct kprobe *cur, struct pt_regs *regs,
+                              struct kprobe_ctlblk *kcb)
+ {
+-      if ((kcb->kprobe_status != KPROBE_REENTER) && cur->post_handler) {
+-              kcb->kprobe_status = KPROBE_HIT_SSDONE;
+-              cur->post_handler(cur, regs, 0);
+-      }
+-
+       /* Restore back the original saved kprobes variables and continue. */
+-      if (kcb->kprobe_status == KPROBE_REENTER)
++      if (kcb->kprobe_status == KPROBE_REENTER) {
++              /* This will restore both kcb and current_kprobe */
+               restore_previous_kprobe(kcb);
+-      else
++      } else {
++              /*
++               * Always update the kcb status because
++               * reset_curent_kprobe() doesn't update kcb.
++               */
++              kcb->kprobe_status = KPROBE_HIT_SSDONE;
++              if (cur->post_handler)
++                      cur->post_handler(cur, regs, 0);
+               reset_current_kprobe();
++      }
+ }
+ NOKPROBE_SYMBOL(kprobe_post_process);
diff --git a/queue-5.19/x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch b/queue-5.19/x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch
new file mode 100644 (file)
index 0000000..7be9b32
--- /dev/null
@@ -0,0 +1,49 @@
+From 3a2ba42cbd0b669ce3837ba400905f93dd06c79f Mon Sep 17 00:00:00 2001
+From: Alexander Lobakin <alexandr.lobakin@intel.com>
+Date: Fri, 15 Jul 2022 17:15:36 +0200
+Subject: x86/olpc: fix 'logical not is only applied to the left hand side'
+
+From: Alexander Lobakin <alexandr.lobakin@intel.com>
+
+commit 3a2ba42cbd0b669ce3837ba400905f93dd06c79f upstream.
+
+The bitops compile-time optimization series revealed one more
+problem in olpc-xo1-sci.c:send_ebook_state(), resulted in GCC
+warnings:
+
+arch/x86/platform/olpc/olpc-xo1-sci.c: In function 'send_ebook_state':
+arch/x86/platform/olpc/olpc-xo1-sci.c:83:63: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
+   83 |         if (!!test_bit(SW_TABLET_MODE, ebook_switch_idev->sw) == state)
+      |                                                               ^~
+arch/x86/platform/olpc/olpc-xo1-sci.c:83:13: note: add parentheses around left hand side expression to silence this warning
+
+Despite this code working as intended, this redundant double
+negation of boolean value, together with comparing to `char`
+with no explicit conversion to bool, makes compilers think
+the author made some unintentional logical mistakes here.
+Make it the other way around and negate the char instead
+to silence the warnings.
+
+Fixes: d2aa37411b8e ("x86/olpc/xo1/sci: Produce wakeup events for buttons and switches")
+Cc: stable@vger.kernel.org # 3.5+
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Reported-by: kernel test robot <lkp@intel.com>
+Reviewed-and-tested-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
+Signed-off-by: Yury Norov <yury.norov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/platform/olpc/olpc-xo1-sci.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/platform/olpc/olpc-xo1-sci.c
++++ b/arch/x86/platform/olpc/olpc-xo1-sci.c
+@@ -80,7 +80,7 @@ static void send_ebook_state(void)
+               return;
+       }
+-      if (!!test_bit(SW_TABLET_MODE, ebook_switch_idev->sw) == state)
++      if (test_bit(SW_TABLET_MODE, ebook_switch_idev->sw) == !!state)
+               return; /* Nothing new to report. */
+       input_report_switch(ebook_switch_idev, SW_TABLET_MODE, state);