- Aug 08, 2023
-
-
Greg Kroah-Hartman authored
Signed-off-by:Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Stable-tree-only change. Due to the way the GDS and SRSO patches flowed into the stable tree, it was a 50% chance that the merge of the which value GDS and SRSO should be. Of course, I lost that bet, and chose the opposite of what Linus chose in commit 64094e7e ("Merge tag 'gds-for-linus-2023-08-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" ) Fix this up by switching the values to match what is now in Linus's tree as that is the correct value to mirror. Signed-off-by:
-
Ross Lagerwall authored
commit 534fc31d upstream. It is possible that a guest can send a packet that contains a head + 18 slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots to underflow in xenvif_get_requests() which then causes the subsequent loop's termination condition to be wrong, causing a buffer overrun of queue->tx_map_ops. Rework the code to account for the extra frag_overflow slots. This is CVE-2023-34319 / XSA-432. Fixes: ad7f402a ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
Paul Durrant <paul@xen.org> Reviewed-by:
Wei Liu <wei.liu@kernel.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Dave Hansen authored
commit 1b0fc034 upstream These options clearly turn *off* XSAVE YMM support. Correct the typo. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Fixes: 553a5c03 ("x86/speculation: Add force option to GDS mitigation") Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
-
Juergen Gross authored
commit fe3e0a13 upstream. Moving the call of fpu__init_cpu() from cpu_init() to start_secondary() broke Xen PV guests, as those don't call start_secondary() for APs. Call fpu__init_cpu() in Xen's cpu_bringup(), which is the Xen PV replacement of start_secondary(). Fixes: b81fac90 ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()") Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230703130032.22916-1-jgross@suse.com Signed-off-by:
-
Daniel Sneddon authored
commit 81ac7e5d upstream Gather Data Sampling (GDS) is a transient execution attack using gather instructions from the AVX2 and AVX512 extensions. This attack allows malicious code to infer data that was previously stored in vector registers. Systems that are not vulnerable to GDS will set the GDS_NO bit of the IA32_ARCH_CAPABILITIES MSR. This is useful for VM guests that may think they are on vulnerable systems that are, in fact, not affected. Guests that are running on affected hosts where the mitigation is enabled are protected as if they were running on an unaffected system. On all hosts that are not affected or that are mitigated, set the GDS_NO bit. Signed-off-by:
Daniel Sneddon <daniel.sneddon@linux.intel.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by:
-
Daniel Sneddon authored
commit 53cf5797 upstream Gather Data Sampling (GDS) is mitigated in microcode. However, on systems that haven't received the updated microcode, disabling AVX can act as a mitigation. Add a Kconfig option that uses the microcode mitigation if available and disables AVX otherwise. Setting this option has no effect on systems not affected by GDS. This is the equivalent of setting gather_data_sampling=force. Signed-off-by:
-
Daniel Sneddon authored
commit 553a5c03 upstream The Gather Data Sampling (GDS) vulnerability allows malicious software to infer stale data previously stored in vector registers. This may include sensitive data such as cryptographic keys. GDS is mitigated in microcode, and systems with up-to-date microcode are protected by default. However, any affected system that is running with older microcode will still be vulnerable to GDS attacks. Since the gather instructions used by the attacker are part of the AVX2 and AVX512 extensions, disabling these extensions prevents gather instructions from being executed, thereby mitigating the system from GDS. Disabling AVX2 is sufficient, but we don't have the granularity to do this. The XCR0[2] disables AVX, with no option to just disable AVX2. Add a kernel parameter gather_data_sampling=force that will enable the microcode mitigation if available, otherwise it will disable AVX on affected systems. This option will be ignored if cmdline mitigations=off. This is a *big* hammer. It is known to break buggy userspace that uses incomplete, buggy AVX enumeration. Unfortunately, such userspace does exist in the wild: https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html [ dhansen: add some more ominous warnings about disabling AVX ] Signed-off-by:
-
Daniel Sneddon authored
commit 8974eb58 upstream Gather Data Sampling (GDS) is a hardware vulnerability which allows unprivileged speculative access to data which was previously stored in vector registers. Intel processors that support AVX2 and AVX512 have gather instructions that fetch non-contiguous data elements from memory. On vulnerable hardware, when a gather instruction is transiently executed and encounters a fault, stale data from architectural or internal vector registers may get transiently stored to the destination vector register allowing an attacker to infer the stale data using typical side channel techniques like cache timing attacks. This mitigation is different from many earlier ones for two reasons. First, it is enabled by default and a bit must be set to *DISABLE* it. This is the opposite of normal mitigation polarity. This means GDS can be mitigated simply by updating microcode and leaving the new control bit alone. Second, GDS has a "lock" bit. This lock bit is there because the mitigation affects the hardware security features KeyLocker and SGX. It needs to be enabled and *STAY* enabled for these features to be mitigated against GDS. The mitigation is enabled in the microcode by default. Disable it by setting gather_data_sampling=off or by disabling all mitigations with mitigations=off. The mitigation status can be checked by reading: /sys/devices/system/cpu/vulnerabilities/gather_data_sampling Signed-off-by:
-
Thomas Gleixner authored
commit b81fac90 upstream Initializing the FPU during the early boot process is a pointless exercise. Early boot is convoluted and fragile enough. Nothing requires that the FPU is set up early. It has to be initialized before fork_init() because the task_struct size depends on the FPU register buffer size. Move the initialization to arch_cpu_finalize_init() which is the perfect place to do so. No functional change. This allows to remove quite some of the custom early command line parsing, but that's subject to the next installment. Signed-off-by:
-
Thomas Gleixner authored
commit 1703db2b upstream No point in keeping them around. Signed-off-by:
-
Thomas Gleixner authored
commit 1f34bb2a upstream Nothing in the call chain requires it Signed-off-by:
-
Thomas Gleixner authored
commit 439e1757 upstream Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and remove the weak fallback from the core code. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit 9df9d2f0 upstream X86 is reworking the boot process so that initializations which are not required during early boot can be moved into the late boot process and out of the fragile and restricted initial boot phase. arch_cpu_finalize_init() is the obvious place to do such initializations, but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for initializing the FPU completely. fork_init() requires that the FPU is initialized as the size of task_struct on X86 depends on the size of the required FPU register buffer. Fortunately none of the init calls between calibrate_delay() and arch_cpu_finalize_init() is relevant for the functionality of arch_cpu_finalize_init(). Invoke it right after calibrate_delay() where everything which is relevant for arch_cpu_finalize_init() has been set up already. No functional change intended. Signed-off-by:
Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://lore.kernel.org/r/20230613224545.612182854@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
commit 61235b24 upstream Everything is converted over to arch_cpu_finalize_init(). Remove the check_bugs() leftovers including the empty stubs in asm-generic, alpha, parisc, powerpc and xtensa. Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20230613224545.553215951@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
commit 9349b5cd upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
Richard Weinberger <richard@nod.at> Link: https://lore.kernel.org/r/20230613224545.493148694@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
commit 44ade508 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://lore.kernel.org/r/20230613224545.431995857@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
commit 01eb454e upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit 7f066a22 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit 9ceecc25 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230613224545.254342916@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
commit 6c38e300 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit ee31bb05 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit 7c7077a7 upstream check_bugs() is a dumping ground for finalizing the CPU bringup. Only parts of it has to do with actual CPU bugs. Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations(). Fixup the bogus 32bit comments while at it. No functional change. Signed-off-by:
-
Thomas Gleixner authored
commit 7725acaa upstream check_bugs() has become a dumping ground for all sorts of activities to finalize the CPU initialization before running the rest of the init code. Most are empty, a few do actual bug checks, some do alternative patching and some cobble a CPU advertisement string together.... Aside of that the current implementation requires duplicated function declaration and mostly empty header files for them. Provide a new function arch_cpu_finalize_init(). Provide a generic declaration if CONFIG_ARCH_HAS_CPU_FINALIZE_INIT is selected and a stub inline otherwise. This requires a temporary #ifdef in start_kernel() which will be removed along with check_bugs() once the architectures are converted over. Signed-off-by:
-
- Jul 24, 2023
-
-
Greg Kroah-Hartman authored
Signed-off-by: -
Borislav Petkov (AMD) authored
Upstream commit: 522b1d69 Add a fix for the Zen2 VZEROUPPER data corruption bug where under certain circumstances executing VZEROUPPER can cause register corruption or leak data. The optimal fix is through microcode but in the case the proper microcode revision has not been applied, enable a fallback fix using a chicken bit. Signed-off-by:
-
Borislav Petkov (AMD) authored
Upstream commit: 8b6f6877 Avoid new and remove old forward declarations. No functional changes. Signed-off-by:
-
Borislav Petkov (AMD) authored
commit a32b0f0d upstream. Do the same as early loading - load on both threads. Signed-off-by:
-
- Jun 28, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20230626180736.243379844@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
-
Clark Wang authored
[ Upstream commit e69b9bc1 ] Claim clkhi and clklo as integer type to avoid possible calculation errors caused by data overflow. Fixes: a55fa9d0 ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by:
Clark Wang <xiaoning.wang@nxp.com> Signed-off-by:
Carlos Song <carlos.song@nxp.com> Reviewed-by:
Andi Shyti <andi.shyti@kernel.org> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dheeraj Kumar Srivastava authored
[ Upstream commit 85d38d58 ] When booting with "intremap=off" and "x2apic_phys" on the kernel command line, the physical x2APIC driver ends up being used even when x2APIC mode is disabled ("intremap=off" disables x2APIC mode). This happens because the first compound condition check in x2apic_phys_probe() is false due to x2apic_mode == 0 and so the following one returns true after default_acpi_madt_oem_check() having already selected the physical x2APIC driver. This results in the following panic: kernel BUG at arch/x86/kernel/apic/io_apic.c:2409! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-rc2-ver4.1rc2 #2 Hardware name: Dell Inc. PowerEdge R6515/07PXPY, BIOS 2.3.6 07/06/2021 RIP: 0010:setup_IO_APIC+0x9c/0xaf0 Call Trace: <TASK> ? native_read_msr apic_intr_mode_init x86_late_time_init start_kernel x86_64_start_reservations x86_64_start_kernel secondary_startup_64_no_verify </TASK> which is: setup_IO_APIC: apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n"); for_each_ioapic(ioapic) BUG_ON(mp_irqdomain_create(ioapic)); Return 0 to denote that x2APIC has not been enabled when probing the physical x2APIC driver. [ bp: Massage commit message heavily. ] Fixes: 9ebd680b ("x86, apic: Use probe routines to simplify apic selection") Signed-off-by:
Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com> Signed-off-by:
Kishon Vijay Abraham I <kvijayab@amd.com> Reviewed-by:
Vasant Hegde <vasant.hegde@amd.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@gmail.com> Reviewed-by:
-
Min Li authored
[ Upstream commit 982b173a ] Userspace can race to free the gobj(robj converted from), robj should not be accessed again after drm_gem_object_put, otherwith it will result in use-after-free. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Min Li <lm0963hack@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Min Li authored
[ Upstream commit 48bfd025 ] If it is async, runqueue_node is freed in g2d_runqueue_worker on another worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and then executes the following if statement, there will be use-after-free. Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Inki Dae authored
[ Upstream commit 4a059559 ] Fix a wrong error return by dropping an error return. When vidi driver is remvoed, if ctx->raw_edid isn't same as fake_edid_info then only what we have to is to free ctx->raw_edid so that driver removing can work correctly - it's not an error case. Signed-off-by:
-
Edson Juliano Drosdeck authored
[ Upstream commit e384dba0 ] Add entries for Positivo laptops: CW14Q01P, K1424G, N14ZP74G to the DMI table, so that active-high jack-detect will work properly on these laptops. Signed-off-by:
Edson Juliano Drosdeck <edson.drosdeck@gmail.com> Link: https://lore.kernel.org/r/20230529181911.632851-1-edson.drosdeck@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Vineeth Vijayan authored
[ Upstream commit 89c0c62e ] Currently, if the device is offline and all the channel paths are either configured or varied offline, the associated subchannel gets unregistered. Don't unregister the subchannel, instead unregister offline device. Signed-off-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 016da9c6 ] The "udc" pointer was never set in the probe() function so it will lead to a NULL dereference in udc_pci_remove() when we do: usb_del_gadget_udc(&udc->gadget); Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/ZG+A/dNpFWAlCChk@kili Signed-off-by:
-
Osama Muhammad authored
[ Upstream commit 9b9e46aa ] This patch fixes the error checking in nfcsim.c. The DebugFS kernel API is developed in a way that the caller can safely ignore the errors that occur during the creation of DebugFS nodes. Signed-off-by:
Osama Muhammad <osmtendev@gmail.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 73af6c75 ] When a message was received the last_initiator is set to 0xff. This will force the signal free time for the next transmit to that for a new initiator. However, if a new transmit is already in progress, then don't set last_initiator, since that's the initiator of the current transmit. Overwriting this would cause the signal free time of a following transmit to be that of the new initiator instead of a next transmit. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
-
Marc Zyngier authored
[ Upstream commit 8d0f019e ] Add the missing Set/Way CMOs that apply to tagged memory. Signed-off-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20230515204601.1270428-2-maz@kernel.org Signed-off-by:
-
