From: Greg Kroah-Hartman Date: Wed, 4 Jan 2023 14:22:09 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v6.1.4~53 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c5ee569453e3ebc77728ee346b01ecd2ada8337a;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch cifs-fix-confusing-debug-message.patch media-dvb-core-fix-double-free-in-dvb_register_device.patch media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch --- diff --git a/queue-4.14/arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch b/queue-4.14/arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch new file mode 100644 index 00000000000..62e6c27f417 --- /dev/null +++ b/queue-4.14/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-4.14/cifs-fix-confusing-debug-message.patch b/queue-4.14/cifs-fix-confusing-debug-message.patch new file mode 100644 index 00000000000..50f830166fc --- /dev/null +++ b/queue-4.14/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 +@@ -2693,7 +2693,7 @@ cifs_set_cifscreds(struct smb_vol *vol _ + static 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; +@@ -2735,6 +2735,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-4.14/media-dvb-core-fix-double-free-in-dvb_register_device.patch b/queue-4.14/media-dvb-core-fix-double-free-in-dvb_register_device.patch new file mode 100644 index 00000000000..9080a2bd244 --- /dev/null +++ b/queue-4.14/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 +@@ -322,6 +322,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-4.14/media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch b/queue-4.14/media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch new file mode 100644 index 00000000000..9b485304aa5 --- /dev/null +++ b/queue-4.14/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 +@@ -738,6 +738,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; +@@ -1253,7 +1258,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-4.14/series b/queue-4.14/series index 2094f1bb058..c6b4affb341 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -279,3 +279,9 @@ dm-thin-use-last-transaction-s-pmd-root-when-commit-failed.patch dm-thin-fix-uaf-in-run_timer_softirq.patch dm-cache-fix-uaf-in-destroy.patch dm-cache-set-needs_check-flag-after-aborting-metadata.patch +x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch +tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.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 diff --git a/queue-4.14/tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch b/queue-4.14/tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch new file mode 100644 index 00000000000..8e34a5fb32b --- /dev/null +++ b/queue-4.14/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 +@@ -5798,7 +5798,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-4.14/x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch b/queue-4.14/x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch new file mode 100644 index 00000000000..0aa1e9a51c6 --- /dev/null +++ b/queue-4.14/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 +@@ -662,7 +662,6 @@ void load_ucode_intel_ap(void) + else + iup = &intel_ucode_patch; + +-reget: + if (!*iup) { + patch = __load_ucode_intel(&uci); + if (!patch) +@@ -673,12 +672,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)