From: Greg Kroah-Hartman Date: Wed, 4 Jan 2023 14:22:42 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v6.1.4~49 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6c38991cdc6e11d74ed4d0f78cf236eef940cc8f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch cifs-fix-confusing-debug-message.patch cifs-fix-missing-display-of-three-mount-options.patch ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch media-dvb-core-fix-double-free-in-dvb_register_device.patch media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch rtc-ds1347-fix-value-written-to-century-register.patch staging-media-tegra-video-fix-chan-mipi-value-on-error.patch staging-media-tegra-video-fix-device_node-use-after-free.patch tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch tracing-hist-fix-wrong-return-value-in-parse_action_params.patch tracing-probes-handle-system-names-with-hyphens.patch x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch --- diff --git a/queue-5.15/arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch b/queue-5.15/arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch new file mode 100644 index 00000000000..62e6c27f417 --- /dev/null +++ b/queue-5.15/arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch @@ -0,0 +1,60 @@ +From 3220022038b9a3845eea762af85f1c5694b9f861 Mon Sep 17 00:00:00 2001 +From: Nick Desaulniers +Date: Tue, 11 Oct 2022 20:00:12 +0100 +Subject: ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod + +From: Nick Desaulniers + +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 +Reviewed-by: Arnd Bergmann +Signed-off-by: Nick Desaulniers +Tested-by: Nathan Chancellor +Cc: stable@vger.kernel.org +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.15/block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch b/queue-5.15/block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch new file mode 100644 index 00000000000..1fd8c37bc90 --- /dev/null +++ b/queue-5.15/block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch @@ -0,0 +1,162 @@ +From 015d02f48537cf2d1a65eeac50717566f9db6eec Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Thu, 24 Nov 2022 11:12:08 +0900 +Subject: block: mq-deadline: Do not break sequential write streams to zoned HDDs + +From: Damien Le Moal + +commit 015d02f48537cf2d1a65eeac50717566f9db6eec upstream. + +mq-deadline ensures an in order dispatching of write requests to zoned +block devices using a per zone lock (a bit). This implies that for any +purely sequential write workload, the drive is exercised most of the +time at a maximum queue depth of one. + +However, when such sequential write workload crosses a zone boundary +(when sequentially writing multiple contiguous zones), zone write +locking may prevent the last write to one zone to be issued (as the +previous write is still being executed) but allow the first write to the +following zone to be issued (as that zone is not yet being writen and +not locked). This result in an out of order delivery of the sequential +write commands to the device every time a zone boundary is crossed. + +While such behavior does not break the sequential write constraint of +zoned block devices (and does not generate any write error), some zoned +hard-disks react badly to seeing these out of order writes, resulting in +lower write throughput. + +This problem can be addressed by always dispatching the first request +of a stream of sequential write requests, regardless of the zones +targeted by these sequential writes. To do so, the function +deadline_skip_seq_writes() is introduced and used in +deadline_next_request() to select the next write command to issue if the +target device is an HDD (blk_queue_nonrot() being false). +deadline_fifo_request() is modified using the new +deadline_earlier_request() and deadline_is_seq_write() helpers to ignore +requests in the fifo list that have a preceding request in lba order +that is sequential. + +With this fix, a sequential write workload executed with the following +fio command: + +fio --name=seq-write --filename=/dev/sda --zonemode=zbd --direct=1 \ + --size=68719476736 --ioengine=libaio --iodepth=32 --rw=write \ + --bs=65536 + +results in an increase from 225 MB/s to 250 MB/s of the write throughput +of an SMR HDD (11% increase). + +Cc: +Signed-off-by: Damien Le Moal +Reviewed-by: Johannes Thumshirn +Link: https://lore.kernel.org/r/20221124021208.242541-3-damien.lemoal@opensource.wdc.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/mq-deadline.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++---- + 1 file changed, 62 insertions(+), 4 deletions(-) + +--- a/block/mq-deadline.c ++++ b/block/mq-deadline.c +@@ -154,6 +154,20 @@ static u8 dd_rq_ioclass(struct request * + } + + /* ++ * get the request before `rq' in sector-sorted order ++ */ ++static inline struct request * ++deadline_earlier_request(struct request *rq) ++{ ++ struct rb_node *node = rb_prev(&rq->rb_node); ++ ++ if (node) ++ return rb_entry_rq(node); ++ ++ return NULL; ++} ++ ++/* + * get the request after `rq' in sector-sorted order + */ + static inline struct request * +@@ -289,6 +303,39 @@ static inline int deadline_check_fifo(st + } + + /* ++ * Check if rq has a sequential request preceding it. ++ */ ++static bool deadline_is_seq_writes(struct deadline_data *dd, struct request *rq) ++{ ++ struct request *prev = deadline_earlier_request(rq); ++ ++ if (!prev) ++ return false; ++ ++ return blk_rq_pos(prev) + blk_rq_sectors(prev) == blk_rq_pos(rq); ++} ++ ++/* ++ * Skip all write requests that are sequential from @rq, even if we cross ++ * a zone boundary. ++ */ ++static struct request *deadline_skip_seq_writes(struct deadline_data *dd, ++ struct request *rq) ++{ ++ sector_t pos = blk_rq_pos(rq); ++ sector_t skipped_sectors = 0; ++ ++ while (rq) { ++ if (blk_rq_pos(rq) != pos + skipped_sectors) ++ break; ++ skipped_sectors += blk_rq_sectors(rq); ++ rq = deadline_latter_request(rq); ++ } ++ ++ return rq; ++} ++ ++/* + * For the specified data direction, return the next request to + * dispatch using arrival ordered lists. + */ +@@ -308,11 +355,16 @@ deadline_fifo_request(struct deadline_da + + /* + * Look for a write request that can be dispatched, that is one with +- * an unlocked target zone. ++ * an unlocked target zone. For some HDDs, breaking a sequential ++ * write stream can lead to lower throughput, so make sure to preserve ++ * sequential write streams, even if that stream crosses into the next ++ * zones and these zones are unlocked. + */ + spin_lock_irqsave(&dd->zone_lock, flags); + list_for_each_entry(rq, &per_prio->fifo_list[DD_WRITE], queuelist) { +- if (blk_req_can_dispatch_to_zone(rq)) ++ if (blk_req_can_dispatch_to_zone(rq) && ++ (blk_queue_nonrot(rq->q) || ++ !deadline_is_seq_writes(dd, rq))) + goto out; + } + rq = NULL; +@@ -342,13 +394,19 @@ deadline_next_request(struct deadline_da + + /* + * Look for a write request that can be dispatched, that is one with +- * an unlocked target zone. ++ * an unlocked target zone. For some HDDs, breaking a sequential ++ * write stream can lead to lower throughput, so make sure to preserve ++ * sequential write streams, even if that stream crosses into the next ++ * zones and these zones are unlocked. + */ + spin_lock_irqsave(&dd->zone_lock, flags); + while (rq) { + if (blk_req_can_dispatch_to_zone(rq)) + break; +- rq = deadline_latter_request(rq); ++ if (blk_queue_nonrot(rq->q)) ++ rq = deadline_latter_request(rq); ++ else ++ rq = deadline_skip_seq_writes(dd, rq); + } + spin_unlock_irqrestore(&dd->zone_lock, flags); + diff --git a/queue-5.15/cifs-fix-confusing-debug-message.patch b/queue-5.15/cifs-fix-confusing-debug-message.patch new file mode 100644 index 00000000000..503d77d5f13 --- /dev/null +++ b/queue-5.15/cifs-fix-confusing-debug-message.patch @@ -0,0 +1,54 @@ +From a85ceafd41927e41a4103d228a993df7edd8823b Mon Sep 17 00:00:00 2001 +From: Paulo Alcantara +Date: Fri, 16 Dec 2022 22:03:41 -0300 +Subject: cifs: fix confusing debug message + +From: Paulo Alcantara + +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) +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/connect.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -1948,7 +1948,7 @@ cifs_set_cifscreds(struct smb3_fs_contex + struct cifs_ses * + cifs_get_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx) + { +- int rc = -ENOMEM; ++ int rc = 0; + unsigned int xid; + struct cifs_ses *ses; + struct sockaddr_in *addr = (struct sockaddr_in *)&server->dstaddr; +@@ -1990,6 +1990,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) diff --git a/queue-5.15/cifs-fix-missing-display-of-three-mount-options.patch b/queue-5.15/cifs-fix-missing-display-of-three-mount-options.patch new file mode 100644 index 00000000000..56faa682039 --- /dev/null +++ b/queue-5.15/cifs-fix-missing-display-of-three-mount-options.patch @@ -0,0 +1,41 @@ +From 2bfd81043e944af0e52835ef6d9b41795af22341 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Sun, 11 Dec 2022 13:54:21 -0600 +Subject: cifs: fix missing display of three mount options + +From: Steve French + +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) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/cifsfs.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/cifs/cifsfs.c ++++ b/fs/cifs/cifsfs.c +@@ -656,9 +656,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); diff --git a/queue-5.15/ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch b/queue-5.15/ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch new file mode 100644 index 00000000000..8e5ac218651 --- /dev/null +++ b/queue-5.15/ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch @@ -0,0 +1,47 @@ +From fd3dc56253acbe9c641a66d312d8393cd55eb04c Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Fri, 9 Dec 2022 10:52:47 -0500 +Subject: ftrace/x86: Add back ftrace_expected for ftrace bug reports + +From: Steven Rostedt (Google) + +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 +Cc: Andrew Morton +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: "x86@kernel.org" +Cc: Borislav Petkov +Cc: Ingo Molnar +Cc: stable@vger.kernel.org +Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()") +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } diff --git a/queue-5.15/kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch b/queue-5.15/kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch new file mode 100644 index 00000000000..aed2cf2a3fb --- /dev/null +++ b/queue-5.15/kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch @@ -0,0 +1,136 @@ +From 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +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 + +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 +Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -4970,24 +4970,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); +@@ -4997,6 +5008,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); diff --git a/queue-5.15/kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch b/queue-5.15/kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch new file mode 100644 index 00000000000..aaea5b29b8b --- /dev/null +++ b/queue-5.15/kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch @@ -0,0 +1,60 @@ +From 31de69f4eea77b28a9724b3fa55aae104fc91fc7 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 13 Dec 2022 06:23:03 +0000 +Subject: KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1 + +From: Sean Christopherson + +commit 31de69f4eea77b28a9724b3fa55aae104fc91fc7 upstream. + +Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the +feature is supported in hardware and enabled in KVM's base, non-nested +configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported. +This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail +if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and +obviously allows L1 to enable the feature for L2. + +KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing +the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when +updating secondary controls in response to KVM_SET_CPUID(2), but (a) that +depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID +updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction +that the guest value must be a strict subset of the supported host value. + +Although no past commit explicitly enabled nested support for WAITPKG, +doing so is safe and functionally correct from an architectural +perspective as no additional KVM support is needed to virtualize TPAUSE, +UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards +VM-Exits to L1 as necessary (commit bf653b78f960, "KVM: vmx: Introduce +handle_unexpected_vmexit and handle WAITPKG vmexit"). + +Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in +hardware, i.e. always runs both L1 and L2 with the host's power management +settings for TPAUSE and UMWAIT. See commit bf09fb6cba4f ("KVM: VMX: Stop +context switching MSR_IA32_UMWAIT_CONTROL") for more details. + +Fixes: e69e72faa3a0 ("KVM: x86: Add support for user wait instructions") +Cc: stable@vger.kernel.org +Reported-by: Aaron Lewis +Reported-by: Yu Zhang +Signed-off-by: Sean Christopherson +Reviewed-by: Jim Mattson +Message-Id: <20221213062306.667649-2-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/nested.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -6666,7 +6666,8 @@ void nested_vmx_setup_ctls_msrs(struct n + SECONDARY_EXEC_ENABLE_INVPCID | + SECONDARY_EXEC_RDSEED_EXITING | + SECONDARY_EXEC_XSAVES | +- SECONDARY_EXEC_TSC_SCALING; ++ SECONDARY_EXEC_TSC_SCALING | ++ SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE; + + /* + * We can emulate "VMCS shadowing," even if the hardware diff --git a/queue-5.15/kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch b/queue-5.15/kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch new file mode 100644 index 00000000000..da85d410923 --- /dev/null +++ b/queue-5.15/kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch @@ -0,0 +1,39 @@ +From eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 30 Sep 2022 23:31:32 +0000 +Subject: KVM: VMX: Resume guest immediately when injecting #GP on ECREATE + +From: Sean Christopherson + +commit eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 upstream. + +Resume the guest immediately when injecting a #GP on ECREATE due to an +invalid enclave size, i.e. don't attempt ECREATE in the host. The #GP is +a terminal fault, e.g. skipping the instruction if ECREATE is successful +would result in KVM injecting #GP on the instruction following ECREATE. + +Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions") +Cc: stable@vger.kernel.org +Cc: Kai Huang +Signed-off-by: Sean Christopherson +Reviewed-by: Kai Huang +Link: https://lore.kernel.org/r/20220930233132.1723330-1-seanjc@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/sgx.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx/sgx.c ++++ b/arch/x86/kvm/vmx/sgx.c +@@ -188,8 +188,10 @@ static int __handle_encls_ecreate(struct + /* Enforce CPUID restriction on max enclave size. */ + max_size_log2 = (attributes & SGX_ATTR_MODE64BIT) ? sgx_12_0->edx >> 8 : + sgx_12_0->edx; +- if (size >= BIT_ULL(max_size_log2)) ++ if (size >= BIT_ULL(max_size_log2)) { + kvm_inject_gp(vcpu, 0); ++ return 1; ++ } + + /* + * sgx_virt_ecreate() returns: diff --git a/queue-5.15/media-dvb-core-fix-double-free-in-dvb_register_device.patch b/queue-5.15/media-dvb-core-fix-double-free-in-dvb_register_device.patch new file mode 100644 index 00000000000..c4c94464cba --- /dev/null +++ b/queue-5.15/media-dvb-core-fix-double-free-in-dvb_register_device.patch @@ -0,0 +1,42 @@ +From 6b0d0477fce747d4137aa65856318b55fba72198 Mon Sep 17 00:00:00 2001 +From: Keita Suzuki +Date: Tue, 26 Apr 2022 06:29:19 +0100 +Subject: media: dvb-core: Fix double free in dvb_register_device() + +From: Keita Suzuki + +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 +Signed-off-by: Keita Suzuki +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } diff --git a/queue-5.15/media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch b/queue-5.15/media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch new file mode 100644 index 00000000000..897fcfaa280 --- /dev/null +++ b/queue-5.15/media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch @@ -0,0 +1,69 @@ +From fd3d91ab1c6ab0628fe642dd570b56302c30a792 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 31 Oct 2022 11:02:45 +0100 +Subject: media: dvb-core: Fix UAF due to refcount races at releasing + +From: Takashi Iwai + +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 +Cc: +Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/rtc-ds1347-fix-value-written-to-century-register.patch b/queue-5.15/rtc-ds1347-fix-value-written-to-century-register.patch new file mode 100644 index 00000000000..2ebd4b01c25 --- /dev/null +++ b/queue-5.15/rtc-ds1347-fix-value-written-to-century-register.patch @@ -0,0 +1,34 @@ +From 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 Mon Sep 17 00:00:00 2001 +From: Ian Abbott +Date: Thu, 27 Oct 2022 17:32:49 +0100 +Subject: rtc: ds1347: fix value written to century register + +From: Ian Abbott + +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: # v5.5+ +Signed-off-by: Ian Abbott +Link: https://lore.kernel.org/r/20221027163249.447416-1-abbotti@mev.co.uk +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.15/series b/queue-5.15/series index fe6e39f5bae..6381b5a83c1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -91,3 +91,24 @@ 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 of-kexec-fix-reading-32-bit-linux-initrd-start-end-values.patch +kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch +kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch +kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.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 +x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch +tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch +tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch +tracing-hist-fix-wrong-return-value-in-parse_action_params.patch +tracing-probes-handle-system-names-with-hyphens.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 +staging-media-tegra-video-fix-device_node-use-after-free.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 +block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch diff --git a/queue-5.15/staging-media-tegra-video-fix-chan-mipi-value-on-error.patch b/queue-5.15/staging-media-tegra-video-fix-chan-mipi-value-on-error.patch new file mode 100644 index 00000000000..e74345898b3 --- /dev/null +++ b/queue-5.15/staging-media-tegra-video-fix-chan-mipi-value-on-error.patch @@ -0,0 +1,53 @@ +From 10b5ce6743c839fa75336042c64e2479caec9430 Mon Sep 17 00:00:00 2001 +From: Luca Ceresoli +Date: Wed, 2 Nov 2022 12:01:01 +0100 +Subject: staging: media: tegra-video: fix chan->mipi value on error + +From: Luca Ceresoli + +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 +Signed-off-by: Luca Ceresoli +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -448,6 +448,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 +@@ -56,7 +56,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 { diff --git a/queue-5.15/staging-media-tegra-video-fix-device_node-use-after-free.patch b/queue-5.15/staging-media-tegra-video-fix-device_node-use-after-free.patch new file mode 100644 index 00000000000..ff8a928cb9e --- /dev/null +++ b/queue-5.15/staging-media-tegra-video-fix-device_node-use-after-free.patch @@ -0,0 +1,58 @@ +From c4d344163c3a7f90712525f931a6c016bbb35e18 Mon Sep 17 00:00:00 2001 +From: Luca Ceresoli +Date: Wed, 2 Nov 2022 12:01:02 +0100 +Subject: staging: media: tegra-video: fix device_node use after free + +From: Luca Ceresoli + +commit c4d344163c3a7f90712525f931a6c016bbb35e18 upstream. + +At probe time this code path is followed: + + * tegra_csi_init + * tegra_csi_channels_alloc + * for_each_child_of_node(node, channel) -- iterates over channels + * automatically gets 'channel' + * tegra_csi_channel_alloc() + * saves into chan->of_node a pointer to the channel OF node + * automatically gets and puts 'channel' + * now the node saved in chan->of_node has refcount 0, can disappear + * tegra_csi_channels_init + * iterates over channels + * tegra_csi_channel_init -- uses chan->of_node + +After that, chan->of_node keeps storing the node until the device is +removed. + +of_node_get() the node and of_node_put() it during teardown to avoid any +risk. + +Fixes: 1ebaeb09830f ("media: tegra-video: Add support for external sensor capture") +Cc: stable@vger.kernel.org +Cc: Sowjanya Komatineni +Signed-off-by: Luca Ceresoli +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/staging/media/tegra-video/csi.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/staging/media/tegra-video/csi.c ++++ b/drivers/staging/media/tegra-video/csi.c +@@ -433,7 +433,7 @@ static int tegra_csi_channel_alloc(struc + for (i = 0; i < chan->numgangports; i++) + chan->csi_port_nums[i] = port_num + i * CSI_PORTS_PER_BRICK; + +- chan->of_node = node; ++ chan->of_node = of_node_get(node); + chan->numpads = num_pads; + if (num_pads & 0x2) { + chan->pads[0].flags = MEDIA_PAD_FL_SINK; +@@ -641,6 +641,7 @@ static void tegra_csi_channels_cleanup(s + media_entity_cleanup(&subdev->entity); + } + ++ of_node_put(chan->of_node); + list_del(&chan->list); + kfree(chan); + } diff --git a/queue-5.15/tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch b/queue-5.15/tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch new file mode 100644 index 00000000000..a80f5ac8f6b --- /dev/null +++ b/queue-5.15/tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch @@ -0,0 +1,180 @@ +From e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +Date: Tue, 6 Dec 2022 23:18:01 +0900 +Subject: tracing: Fix complicated dependency of CONFIG_TRACER_MAX_TRACE + +From: Masami Hiramatsu (Google) + +commit e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f upstream. + +Both CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER partially enables the +CONFIG_TRACER_MAX_TRACE code, but that is complicated and has +introduced a bug; It declares tracing_max_lat_fops data structure outside +of #ifdefs, but since it is defined only when CONFIG_TRACER_MAX_TRACE=y +or CONFIG_HWLAT_TRACER=y, if only CONFIG_OSNOISE_TRACER=y, that +declaration comes to a definition(!). + +To fix this issue, and do not repeat the similar problem, makes +CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER enables the +CONFIG_TRACER_MAX_TRACE always. It has there benefits; +- Fix the tracing_max_lat_fops bug +- Simplify the #ifdefs +- CONFIG_TRACER_MAX_TRACE code is fully enabled, or not. + +Link: https://lore.kernel.org/linux-trace-kernel/167033628155.4111793.12185405690820208159.stgit@devnote3 + +Fixes: 424b650f35c7 ("tracing: Fix missing osnoise tracer on max_latency") +Cc: Daniel Bristot de Oliveira +Cc: stable@vger.kernel.org +Reported-by: David Howells +Reported-by: kernel test robot +Signed-off-by: Masami Hiramatsu (Google) +Link: https://lore.kernel.org/all/166992525941.1716618.13740663757583361463.stgit@warthog.procyon.org.uk/ (original thread and v1) +Link: https://lore.kernel.org/all/202212052253.VuhZ2ulJ-lkp@intel.com/T/#u (v1 error report) +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/Kconfig | 2 ++ + kernel/trace/trace.c | 23 +++++++++++++---------- + kernel/trace/trace.h | 8 +++----- + 3 files changed, 18 insertions(+), 15 deletions(-) + +--- a/kernel/trace/Kconfig ++++ b/kernel/trace/Kconfig +@@ -328,6 +328,7 @@ config SCHED_TRACER + config HWLAT_TRACER + bool "Tracer to detect hardware latencies (like SMIs)" + select GENERIC_TRACER ++ select TRACER_MAX_TRACE + help + This tracer, when enabled will create one or more kernel threads, + depending on what the cpumask file is set to, which each thread +@@ -363,6 +364,7 @@ config HWLAT_TRACER + config OSNOISE_TRACER + bool "OS Noise tracer" + select GENERIC_TRACER ++ select TRACER_MAX_TRACE + help + In the context of high-performance computing (HPC), the Operating + System Noise (osnoise) refers to the interference experienced by an +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -1409,6 +1409,7 @@ int tracing_snapshot_cond_disable(struct + return false; + } + EXPORT_SYMBOL_GPL(tracing_snapshot_cond_disable); ++#define free_snapshot(tr) do { } while (0) + #endif /* CONFIG_TRACER_SNAPSHOT */ + + void tracer_tracing_off(struct trace_array *tr) +@@ -1679,6 +1680,8 @@ static ssize_t trace_seq_to_buffer(struc + } + + unsigned long __read_mostly tracing_thresh; ++ ++#ifdef CONFIG_TRACER_MAX_TRACE + static const struct file_operations tracing_max_lat_fops; + + #ifdef LATENCY_FS_NOTIFY +@@ -1735,18 +1738,14 @@ void latency_fsnotify(struct trace_array + irq_work_queue(&tr->fsnotify_irqwork); + } + +-#elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \ +- || defined(CONFIG_OSNOISE_TRACER) ++#else /* !LATENCY_FS_NOTIFY */ + + #define trace_create_maxlat_file(tr, d_tracer) \ + trace_create_file("tracing_max_latency", TRACE_MODE_WRITE, \ + d_tracer, &tr->max_latency, &tracing_max_lat_fops) + +-#else +-#define trace_create_maxlat_file(tr, d_tracer) do { } while (0) + #endif + +-#ifdef CONFIG_TRACER_MAX_TRACE + /* + * Copy the new maximum trace into the separate maximum-trace + * structure. (this way the maximum trace is permanently saved, +@@ -1821,14 +1820,15 @@ update_max_tr(struct trace_array *tr, st + ring_buffer_record_off(tr->max_buffer.buffer); + + #ifdef CONFIG_TRACER_SNAPSHOT +- if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data)) +- goto out_unlock; ++ if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data)) { ++ arch_spin_unlock(&tr->max_lock); ++ return; ++ } + #endif + swap(tr->array_buffer.buffer, tr->max_buffer.buffer); + + __update_max_tr(tr, tsk, cpu); + +- out_unlock: + arch_spin_unlock(&tr->max_lock); + } + +@@ -1875,6 +1875,7 @@ update_max_tr_single(struct trace_array + __update_max_tr(tr, tsk, cpu); + arch_spin_unlock(&tr->max_lock); + } ++ + #endif /* CONFIG_TRACER_MAX_TRACE */ + + static int wait_on_pipe(struct trace_iterator *iter, int full) +@@ -6536,7 +6537,7 @@ out: + return ret; + } + +-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) ++#ifdef CONFIG_TRACER_MAX_TRACE + + static ssize_t + tracing_max_lat_read(struct file *filp, char __user *ubuf, +@@ -7560,7 +7561,7 @@ static const struct file_operations trac + .llseek = generic_file_llseek, + }; + +-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) ++#ifdef CONFIG_TRACER_MAX_TRACE + static const struct file_operations tracing_max_lat_fops = { + .open = tracing_open_generic, + .read = tracing_max_lat_read, +@@ -9549,7 +9550,9 @@ init_tracer_tracefs(struct trace_array * + + create_trace_options_dir(tr); + ++#ifdef CONFIG_TRACER_MAX_TRACE + trace_create_maxlat_file(tr, d_tracer); ++#endif + + if (ftrace_create_function_files(tr, d_tracer)) + MEM_FAIL(1, "Could not allocate function filter files"); +--- a/kernel/trace/trace.h ++++ b/kernel/trace/trace.h +@@ -309,8 +309,7 @@ struct trace_array { + struct array_buffer max_buffer; + bool allocated_snapshot; + #endif +-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \ +- || defined(CONFIG_OSNOISE_TRACER) ++#ifdef CONFIG_TRACER_MAX_TRACE + unsigned long max_latency; + #ifdef CONFIG_FSNOTIFY + struct dentry *d_max_latency; +@@ -688,12 +687,11 @@ void update_max_tr(struct trace_array *t + void *cond_data); + void update_max_tr_single(struct trace_array *tr, + struct task_struct *tsk, int cpu); +-#endif /* CONFIG_TRACER_MAX_TRACE */ + +-#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \ +- || defined(CONFIG_OSNOISE_TRACER)) && defined(CONFIG_FSNOTIFY) ++#ifdef CONFIG_FSNOTIFY + #define LATENCY_FS_NOTIFY + #endif ++#endif /* CONFIG_TRACER_MAX_TRACE */ + + #ifdef LATENCY_FS_NOTIFY + void latency_fsnotify(struct trace_array *tr); diff --git a/queue-5.15/tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch b/queue-5.15/tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch new file mode 100644 index 00000000000..7978d4905a4 --- /dev/null +++ b/queue-5.15/tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch @@ -0,0 +1,48 @@ +From c1ac03af6ed45d05786c219d102f37eb44880f28 Mon Sep 17 00:00:00 2001 +From: Yang Jihong +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 + +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 +Cc: stable@vger.kernel.org +Fixes: 088b1e427dbba ("ftrace: pipe fixes") +Signed-off-by: Yang Jihong +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 15 ++++++++++++++- + 1 file changed, 14 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -6764,7 +6764,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; + } diff --git a/queue-5.15/tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch b/queue-5.15/tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch new file mode 100644 index 00000000000..b9e7f3846fc --- /dev/null +++ b/queue-5.15/tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch @@ -0,0 +1,43 @@ +From d5f30a7da8ea8e6450250275cec5670cee3c4264 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Thu, 17 Nov 2022 21:42:49 -0500 +Subject: tracing: Fix race where eprobes can be called before the event + +From: Steven Rostedt (Google) + +commit d5f30a7da8ea8e6450250275cec5670cee3c4264 upstream. + +The flag that tells the event to call its triggers after reading the event +is set for eprobes after the eprobe is enabled. This leads to a race where +the eprobe may be triggered at the beginning of the event where the record +information is NULL. The eprobe then dereferences the NULL record causing +a NULL kernel pointer bug. + +Test for a NULL record to keep this from happening. + +Link: https://lore.kernel.org/linux-trace-kernel/20221116192552.1066630-1-rafaelmendsr@gmail.com/ +Link: https://lore.kernel.org/all/20221117214249.2addbe10@gandalf.local.home/ + +Cc: stable@vger.kernel.org +Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events") +Reported-by: Rafael Mendonca +Signed-off-by: Steven Rostedt (Google) +Acked-by: Masami Hiramatsu (Google) +Signed-off-by: Masami Hiramatsu (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_eprobe.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/trace/trace_eprobe.c ++++ b/kernel/trace/trace_eprobe.c +@@ -570,6 +570,9 @@ static void eprobe_trigger_func(struct e + if (unlikely(!rec)) + return; + ++ if (unlikely(!rec)) ++ return; ++ + __eprobe_trace_func(edata, rec); + } + diff --git a/queue-5.15/tracing-hist-fix-wrong-return-value-in-parse_action_params.patch b/queue-5.15/tracing-hist-fix-wrong-return-value-in-parse_action_params.patch new file mode 100644 index 00000000000..cd7dfdd727d --- /dev/null +++ b/queue-5.15/tracing-hist-fix-wrong-return-value-in-parse_action_params.patch @@ -0,0 +1,35 @@ +From 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 Mon Sep 17 00:00:00 2001 +From: Zheng Yejian +Date: Wed, 7 Dec 2022 11:46:35 +0800 +Subject: tracing/hist: Fix wrong return value in parse_action_params() + +From: Zheng Yejian + +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: +Cc: +Cc: stable@vger.kernel.org +Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support") +Signed-off-by: Zheng Yejian +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -3190,6 +3190,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; + } + diff --git a/queue-5.15/tracing-probes-handle-system-names-with-hyphens.patch b/queue-5.15/tracing-probes-handle-system-names-with-hyphens.patch new file mode 100644 index 00000000000..f9069d584f4 --- /dev/null +++ b/queue-5.15/tracing-probes-handle-system-names-with-hyphens.patch @@ -0,0 +1,85 @@ +From 575b76cb885532aae13a9d979fd476bb2b156cb9 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Tue, 22 Nov 2022 12:23:45 -0500 +Subject: tracing/probes: Handle system names with hyphens + +From: Steven Rostedt (Google) + +commit 575b76cb885532aae13a9d979fd476bb2b156cb9 upstream. + +When creating probe names, a check is done to make sure it matches basic C +standard variable naming standards. Basically, starts with alphabetic or +underline, and then the rest of the characters have alpha-numeric or +underline in them. + +But system names do not have any true naming conventions, as they are +created by the TRACE_SYSTEM macro and nothing tests to see what they are. +The "xhci-hcd" trace events has a '-' in the system name. When trying to +attach a eprobe to one of these trace points, it fails because the system +name does not follow the variable naming convention because of the +hyphen, and the eprobe checks fail on this. + +Allow hyphens in the system name so that eprobes can attach to the +"xhci-hcd" trace events. + +Link: https://lore.kernel.org/all/Y3eJ8GiGnEvVd8%2FN@macondo/ +Link: https://lore.kernel.org/linux-trace-kernel/20221122122345.160f5077@gandalf.local.home + +Cc: Masami Hiramatsu +Cc: stable@vger.kernel.org +Fixes: 5b7a96220900e ("tracing/probe: Check event/group naming rule at parsing") +Reported-by: Rafael Mendonca +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.h | 19 ++++++++++++++++--- + kernel/trace/trace_probe.c | 2 +- + 2 files changed, 17 insertions(+), 4 deletions(-) + +--- a/kernel/trace/trace.h ++++ b/kernel/trace/trace.h +@@ -1939,17 +1939,30 @@ static __always_inline void trace_iterat + } + + /* Check the name is good for event/group/fields */ +-static inline bool is_good_name(const char *name) ++static inline bool __is_good_name(const char *name, bool hash_ok) + { +- if (!isalpha(*name) && *name != '_') ++ if (!isalpha(*name) && *name != '_' && (!hash_ok || *name != '-')) + return false; + while (*++name != '\0') { +- if (!isalpha(*name) && !isdigit(*name) && *name != '_') ++ if (!isalpha(*name) && !isdigit(*name) && *name != '_' && ++ (!hash_ok || *name != '-')) + return false; + } + return true; + } + ++/* Check the name is good for event/group/fields */ ++static inline bool is_good_name(const char *name) ++{ ++ return __is_good_name(name, false); ++} ++ ++/* Check the name is good for system */ ++static inline bool is_good_system_name(const char *name) ++{ ++ return __is_good_name(name, true); ++} ++ + /* Convert certain expected symbols into '_' when generating event names */ + static inline void sanitize_event_name(char *name) + { +--- a/kernel/trace/trace_probe.c ++++ b/kernel/trace/trace_probe.c +@@ -246,7 +246,7 @@ int traceprobe_parse_event_name(const ch + return -EINVAL; + } + strlcpy(buf, event, slash - event + 1); +- if (!is_good_name(buf)) { ++ if (!is_good_system_name(buf)) { + trace_probe_log_err(offset, BAD_GROUP_NAME); + return -EINVAL; + } diff --git a/queue-5.15/x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch b/queue-5.15/x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch new file mode 100644 index 00000000000..de666c51663 --- /dev/null +++ b/queue-5.15/x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch @@ -0,0 +1,66 @@ +From 1993bf97992df2d560287f3c4120eda57426843d Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +Date: Mon, 19 Dec 2022 23:35:10 +0900 +Subject: x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK + +From: Masami Hiramatsu (Google) + +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 +Signed-off-by: Masami Hiramatsu (Google) +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/167146051026.1374301.392728975473572291.stgit@devnote3 +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + #include + #include + #include +@@ -289,12 +290,15 @@ static int can_probe(unsigned long paddr + if (ret < 0) + return 0; + ++#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; + } + diff --git a/queue-5.15/x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch b/queue-5.15/x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch new file mode 100644 index 00000000000..1e0c2477875 --- /dev/null +++ b/queue-5.15/x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch @@ -0,0 +1,84 @@ +From 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +Date: Mon, 19 Dec 2022 23:35:19 +0900 +Subject: x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK + +From: Masami Hiramatsu (Google) + +commit 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 upstream. + +Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping +speculative execution after function return, kprobe jump optimization +always fails on the functions with such INT3 inside the function body. +(It already checks the INT3 padding between functions, but not inside + the function) + +To avoid this issue, as same as kprobes, check whether the INT3 comes +from 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 +Signed-off-by: Masami Hiramatsu (Google) +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/167146051929.1374301.7419382929328081706.stgit@devnote3 +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/kprobes/opt.c | 28 ++++++++-------------------- + 1 file changed, 8 insertions(+), 20 deletions(-) + +--- a/arch/x86/kernel/kprobes/opt.c ++++ b/arch/x86/kernel/kprobes/opt.c +@@ -15,6 +15,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -272,19 +273,6 @@ static int insn_is_indirect_jump(struct + return ret; + } + +-static bool is_padding_int3(unsigned long addr, unsigned long eaddr) +-{ +- unsigned char ops; +- +- for (; addr < eaddr; addr++) { +- if (get_kernel_nofault(ops, (void *)addr) < 0 || +- ops != INT3_INSN_OPCODE) +- return false; +- } +- +- return true; +-} +- + /* Decode whole function to ensure any instructions don't jump into target */ + static int can_optimize(unsigned long paddr) + { +@@ -327,15 +315,15 @@ static int can_optimize(unsigned long pa + ret = insn_decode_kernel(&insn, (void *)recovered_insn); + if (ret < 0) + return 0; +- ++#ifdef CONFIG_KGDB + /* +- * In the case of detecting unknown breakpoint, this could be +- * a padding INT3 between functions. Let's check that all the +- * rest of the bytes are also INT3. ++ * If there is a dynamically installed kgdb sw breakpoint, ++ * this function should not be probed. + */ +- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE) +- return is_padding_int3(addr, paddr - offset + size) ? 1 : 0; +- ++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE && ++ kgdb_has_hit_break(addr)) ++ return 0; ++#endif + /* Recover address */ + insn.kaddr = (void *)addr; + insn.next_byte = (void *)(addr + insn.length); diff --git a/queue-5.15/x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch b/queue-5.15/x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch new file mode 100644 index 00000000000..9eb19ab62eb --- /dev/null +++ b/queue-5.15/x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch @@ -0,0 +1,51 @@ +From be1b670f61443aa5d0d01782e9b8ea0ee825d018 Mon Sep 17 00:00:00 2001 +From: Ashok Raj +Date: Tue, 29 Nov 2022 13:08:27 -0800 +Subject: x86/microcode/intel: Do not retry microcode reloading on the APs + +From: Ashok Raj + +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 +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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)