- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 2725/2725] kismet: WARNING: unmet direct dependencies detected for RESCTRL_FS when selected by ARM64_MPAM
by kernel test robot 26 Aug '25

26 Aug '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 90c9bda5f31a94a3097afa522e7d2c94de817288 commit: c5a4bf91167c714de74c47f5cd6d888c66e9860d [2725/2725] arm64: mpam: Select ARCH_HAS_CPU_RESCTRL config: arm64-kismet-CONFIG_RESCTRL_FS-CONFIG_ARM64_MPAM-0-0 (https://download.01.org/0day-ci/archive/20250826/202508260331.bV3mRcFF-lkp@…) reproduce: (https://download.01.org/0day-ci/archive/20250826/202508260331.bV3mRcFF-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202508260331.bV3mRcFF-lkp@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for RESCTRL_FS when selected by ARM64_MPAM WARNING: unmet direct dependencies detected for RESCTRL_FS Depends on [n]: MISC_FILESYSTEMS [=n] && ARCH_HAS_CPU_RESCTRL [=y] Selected by [y]: - ARM64_MPAM [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1761/1761] kismet: WARNING: unmet direct dependencies detected for SPI_PHYTIUM when selected by SPI_PHYTIUM_PLAT
by kernel test robot 26 Aug '25

26 Aug '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6140b9e22a5c2bec953454ba4737dd9cd2a1f754 commit: e8483fcd43fc1dbb8d21bb7eacce804cbab6a7c6 [1761/1761] spi: add phytium spi support config: arm64-kismet-CONFIG_SPI_PHYTIUM-CONFIG_SPI_PHYTIUM_PLAT-0-0 (https://download.01.org/0day-ci/archive/20250826/202508260240.ljnQN4yK-lkp@…) reproduce: (https://download.01.org/0day-ci/archive/20250826/202508260240.ljnQN4yK-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202508260240.ljnQN4yK-lkp@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for SPI_PHYTIUM when selected by SPI_PHYTIUM_PLAT WARNING: unmet direct dependencies detected for HARDLOCKUP_DETECTOR Depends on [n]: DEBUG_KERNEL [=n] && !S390 && (HAVE_HARDLOCKUP_DETECTOR_PERF [=n] || HAVE_HARDLOCKUP_DETECTOR_ARCH [=y]) Selected by [y]: - SDEI_WATCHDOG [=y] && <choice> && ARM_SDE_INTERFACE [=y] && !HARDLOCKUP_CHECK_TIMESTAMP [=n] WARNING: unmet direct dependencies detected for SPI_PHYTIUM Depends on [n]: SPI [=y] && SPI_MASTER [=y] && (ARCH_PHYTIUM [=n] || COMPILE_TEST [=n]) Selected by [y]: - SPI_PHYTIUM_PLAT [=y] && SPI [=y] && SPI_MASTER [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1761/1761] kismet: WARNING: unmet direct dependencies detected for SPI_PHYTIUM when selected by SPI_PHYTIUM_PCI
by kernel test robot 26 Aug '25

26 Aug '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6140b9e22a5c2bec953454ba4737dd9cd2a1f754 commit: e8483fcd43fc1dbb8d21bb7eacce804cbab6a7c6 [1761/1761] spi: add phytium spi support config: arm64-kismet-CONFIG_SPI_PHYTIUM-CONFIG_SPI_PHYTIUM_PCI-0-0 (https://download.01.org/0day-ci/archive/20250826/202508260038.ZjYGT3xz-lkp@…) reproduce: (https://download.01.org/0day-ci/archive/20250826/202508260038.ZjYGT3xz-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202508260038.ZjYGT3xz-lkp@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for SPI_PHYTIUM when selected by SPI_PHYTIUM_PCI WARNING: unmet direct dependencies detected for SPI_PHYTIUM Depends on [n]: SPI [=y] && SPI_MASTER [=y] && (ARCH_PHYTIUM [=n] || COMPILE_TEST [=n]) Selected by [y]: - SPI_PHYTIUM_PCI [=y] && SPI [=y] && SPI_MASTER [=y] && PCI [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
by Li Lingfeng 25 Aug '25

25 Aug '25

From: wangzijie <wangzijie1(a)honor.com> mainline inclusion from mainline-v6.17-rc1 commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICUC9Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in proc_get_inode()"). Followed by AI Viro's suggestion, fix it in same manner. Link: https://lkml.kernel.org/r/20250607021353.1127963-1-wangzijie1@honor.com Fixes: 3f61631d47f1 ("take care to handle NULL ->proc_lseek()") Signed-off-by: wangzijie <wangzijie1(a)honor.com> Reviewed-by: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: "Edgecombe, Rick P" <rick.p.edgecombe(a)intel.com> Cc: Kirill A. Shuemov <kirill.shutemov(a)linux.intel.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: fs/proc/inode.c [Commit 133097647206 ("proc: use __auto_type more") removed the definition of release in proc_reg_open().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/proc/generic.c | 2 ++ fs/proc/inode.c | 2 +- fs/proc/internal.h | 5 +++++ include/linux/proc_fs.h | 1 + 4 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/proc/generic.c b/fs/proc/generic.c index c8785d68e870..2187d9ca351c 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -567,6 +567,8 @@ static void pde_set_flags(struct proc_dir_entry *pde) if (pde->proc_ops->proc_compat_ioctl) pde->flags |= PROC_ENTRY_proc_compat_ioctl; #endif + if (pde->proc_ops->proc_lseek) + pde->flags |= PROC_ENTRY_proc_lseek; } struct proc_dir_entry *proc_create_data(const char *name, umode_t mode, diff --git a/fs/proc/inode.c b/fs/proc/inode.c index 897c71077a0f..957021784026 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -494,7 +494,7 @@ static int proc_reg_open(struct inode *inode, struct file *file) typeof_member(struct proc_ops, proc_release) release; struct pde_opener *pdeo; - if (!pde->proc_ops->proc_lseek) + if (!pde_has_proc_lseek(pde)) file->f_mode &= ~FMODE_LSEEK; if (pde_is_permanent(pde)) { diff --git a/fs/proc/internal.h b/fs/proc/internal.h index d5509cb5019c..464d729ab0c8 100644 --- a/fs/proc/internal.h +++ b/fs/proc/internal.h @@ -98,6 +98,11 @@ static inline bool pde_has_proc_compat_ioctl(const struct proc_dir_entry *pde) #endif } +static inline bool pde_has_proc_lseek(const struct proc_dir_entry *pde) +{ + return pde->flags & PROC_ENTRY_proc_lseek; +} + extern struct kmem_cache *proc_dir_entry_cache; void pde_free(struct proc_dir_entry *pde); diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h index fdab1d93a5d1..48359f484de0 100644 --- a/include/linux/proc_fs.h +++ b/include/linux/proc_fs.h @@ -27,6 +27,7 @@ enum { PROC_ENTRY_proc_read_iter = 1U << 1, PROC_ENTRY_proc_compat_ioctl = 1U << 2, + PROC_ENTRY_proc_lseek = 1U << 3, }; struct proc_ops { -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2025-38180
by Yongqiang Liu 25 Aug '25

25 Aug '25

Eric Dumazet (2): net: atm: add lec_mutex net: atm: fix /proc/net/atm/lec handling net/atm/lec.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[openeuler:openEuler-1.0-LTS 1761/1761] include/uapi/../../drivers/scsi/isci/isci.h:531:1: error: attempted to randomize userland API struct sci_base_state
by kernel test robot 25 Aug '25

25 Aug '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6140b9e22a5c2bec953454ba4737dd9cd2a1f754 commit: 28617d9631dc65be773b8a28718e8614558caa5f [1761/1761] scsi: libsas: Abort all in-flight requests when device is gone config: arm64-randconfig-001-20250825 (https://download.01.org/0day-ci/archive/20250825/202508252122.UpJYI1df-lkp@…) compiler: aarch64-linux-gcc (GCC) 7.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250825/202508252122.UpJYI1df-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202508252122.UpJYI1df-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from include/uapi/../../drivers/scsi/isci/remote_node_context.h:67:0, from include/uapi/../../drivers/scsi/isci/remote_device.h:61, from drivers/scsi/libsas/sas_discover.c:36: >> include/uapi/../../drivers/scsi/isci/isci.h:531:1: error: attempted to randomize userland API struct sci_base_state }; ^ In file included from drivers/scsi/libsas/sas_discover.c:30:0: drivers/scsi/libsas/sas_discover.c: In function 'sas_discover_domain': drivers/scsi/libsas/sas_internal.h:37:31: warning: this statement may fall through [-Wimplicit-fallthrough=] #define SAS_DPRINTK(fmt, ...) printk(KERN_DEBUG "sas: " fmt, ## __VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/libsas/sas_discover.c:512:3: note: in expansion of macro 'SAS_DPRINTK' SAS_DPRINTK("ATA device seen but CONFIG_SCSI_SAS_ATA=N so cannot attach\n"); ^~~~~~~~~~~ drivers/scsi/libsas/sas_discover.c:515:2: note: here default: ^~~~~~~ vim +531 include/uapi/../../drivers/scsi/isci/isci.h 12ef65444de9d3 Edmund Nadolski 2011-06-02 527 12ef65444de9d3 Edmund Nadolski 2011-06-02 528 struct sci_base_state { 12ef65444de9d3 Edmund Nadolski 2011-06-02 529 sci_state_transition_t enter_state; /* Called on state entry */ 12ef65444de9d3 Edmund Nadolski 2011-06-02 530 sci_state_transition_t exit_state; /* Called on state exit */ 12ef65444de9d3 Edmund Nadolski 2011-06-02 @531 }; 12ef65444de9d3 Edmund Nadolski 2011-06-02 532 :::::: The code at line 531 was first introduced by commit :::::: 12ef65444de9d387a383b9991960848bed5bbe74 isci: additional state machine cleanup :::::: TO: Edmund Nadolski <edmund.nadolski(a)intel.com> :::::: CC: Dan Williams <dan.j.williams(a)intel.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] arm64/mpam: Add mb_only boot option
by Zeng Heng 25 Aug '25

25 Aug '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/ICUMVC -------------------------------- Within MPAM's shared-resource pool, different types frequently vary in quantity and specification. To present a uniform partition and monitoring interface, the driver traditionally constrains every resource set to the smallest common denominator, leaving much of the underlying hardware idle and wasted. To maximize utilization of a designated resource for single-type scenarios, allow enabling that resource exclusively. Therefore, we extend the boot parameter to initialize only specified resource type while ignoring all others. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/include/asm/cpufeature.h | 1 + arch/arm64/kernel/cpufeature.c | 10 ++++++++++ drivers/acpi/arm64/mpam.c | 5 +++++ fs/resctrl/monitor.c | 25 ++++++++++++++++++------- 4 files changed, 34 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h index 859236125cb1..c4d4ab854e81 100644 --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -880,6 +880,7 @@ static inline bool cpus_support_mpam(void) } bool mpam_detect_is_enabled(void); +bool mpam_only_enable_mb(void); static inline bool system_supports_haft(void) { diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 672accbd5b4a..f8c225c90439 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2363,9 +2363,19 @@ bool mpam_detect_is_enabled(void) return mpam_force_enabled; } +static bool __read_mostly mpam_mb_only; +bool mpam_only_enable_mb(void) +{ + return mpam_mb_only; +} + static int __init mpam_setup(char *str) { mpam_force_enabled = true; + + if (str && !strcmp(str, "mb_only")) + mpam_mb_only = true; + return 0; } early_param("arm64.mpam", mpam_setup); diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c index de866e711be2..277e7d2bc58b 100644 --- a/drivers/acpi/arm64/mpam.c +++ b/drivers/acpi/arm64/mpam.c @@ -120,6 +120,11 @@ static int acpi_mpam_parse_resource(struct acpi_mpam_msc_node *tbl_msc, off_t offset; int level; + if (mpam_only_enable_mb()) { + if (res->locator_type != ACPI_MPAM_LOCATION_TYPE_MEMORY) + return 0; + } + /* * Class IDs are somewhat arbitrary, but need to be co-ordinated. * 0-N are caches, diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 66ebfaa26e28..d10497013638 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -790,9 +790,6 @@ static int dom_data_init(struct rdt_resource *r) static void dom_data_exit(struct rdt_resource *r) { - if (!r->mon_capable) - return; - mutex_lock(&rdtgroup_mutex); if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) { kfree(closid_num_dirty_rmid); @@ -807,10 +804,15 @@ static void dom_data_exit(struct rdt_resource *r) int resctrl_mon_resource_init(void) { - struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3); - int ret; + struct rdt_resource *r; + int i, ret; - if (!r->mon_capable) + for (i = 0; i < RDT_NUM_RESOURCES; i++) { + r = resctrl_arch_get_resource(i); + if (r->mon_capable) + break; + } + if (i == RDT_NUM_RESOURCES) return 0; ret = dom_data_init(r); @@ -822,7 +824,16 @@ int resctrl_mon_resource_init(void) void resctrl_mon_resource_exit(void) { - struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3); + struct rdt_resource *r; + int i; + + for (i = 0; i < RDT_NUM_RESOURCES; i++) { + r = resctrl_arch_get_resource(i); + if (r->mon_capable) + break; + } + if (i == RDT_NUM_RESOURCES) + return; dom_data_exit(r); } -- 2.25.1

2 1

[PATCH OLK-6.6] arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
by Jinjie Ruan 25 Aug '25

25 Aug '25

From: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> stable inclusion from stable-v6.6.101 commit 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICUCAD CVE: CVE-2025-38670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb upstream. `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> Reported-by: Cristian Prundeanu <cpru(a)amazon.com> Fixes: 59b37fe52f49 ("arm64: Stash shadow stack pointer in the task struct on interrupt") Tested-by: Cristian Prundeanu <cpru(a)amazon.com> Acked-by: Will Deacon <will(a)kernel.org> Link: https://lore.kernel.org/r/20250718142814.133329-1-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 5 +++++ arch/arm64/kernel/entry.S | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 38b23786aeb4..f6f92c582e0f 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -63,6 +63,11 @@ alternative_else_nop_endif /* * Save/restore interrupts. */ + .macro save_and_disable_daif, flags + mrs \flags, daif + msr daifset, #0xf + .endm + .macro save_and_disable_irq, flags mrs \flags, daif msr daifset, #3 diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 62b59d67b27e..5648a3119f90 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -1048,6 +1048,7 @@ SYM_CODE_END(__bp_harden_el1_vectors) * */ SYM_FUNC_START(cpu_switch_to) + save_and_disable_daif x11 mov x10, #THREAD_CPU_CONTEXT add x8, x0, x10 mov x9, sp @@ -1071,6 +1072,7 @@ SYM_FUNC_START(cpu_switch_to) ptrauth_keys_install_kernel x1, x8, x9, x10 scs_save x0 scs_load_current + restore_irq x11 ret SYM_FUNC_END(cpu_switch_to) NOKPROBE(cpu_switch_to) @@ -1097,6 +1099,7 @@ NOKPROBE(ret_from_fork) * Calls func(regs) using this CPU's irq stack and shadow irq stack. */ SYM_FUNC_START(call_on_irq_stack) + save_and_disable_daif x9 #ifdef CONFIG_SHADOW_CALL_STACK get_current_task x16 scs_save x16 @@ -1111,8 +1114,10 @@ SYM_FUNC_START(call_on_irq_stack) /* Move to the new stack and call the function there */ add sp, x16, #IRQ_STACK_SIZE + restore_irq x9 blr x1 + save_and_disable_daif x9 /* * Restore the SP from the FP, and restore the FP and LR from the frame * record. @@ -1120,6 +1125,7 @@ SYM_FUNC_START(call_on_irq_stack) mov sp, x29 ldp x29, x30, [sp], #16 scs_load_current + restore_irq x9 ret SYM_FUNC_END(call_on_irq_stack) NOKPROBE(call_on_irq_stack) -- 2.34.1

2 1

[PATCH OLK-6.6] arm64: Fix actlr_el1 can not set problem in guest
by Jinjie Ruan 25 Aug '25

25 Aug '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/release-management/issues/IBV2E4 -------------------------------- During the initialization of the vCPU, the vcpu->arch.hcr_el2 is set to HCR_GUEST_FLAGS, which include HCR_TACR, so regardless of whether the host has configured HCR_EL2, accessing ACTLR_EL1 in the guest virtual machine will trap to EL2. However, the current implementation of KVM ignores writes to ACTLR_EL1, so it is currently not possible to set this register in the guest, hardware xcall/xint can not take effect anyway, so modify the state of actlr based on the written value in access_actlr(). Fixes: 7f2e02718bba ("arm64: entry: Support hardware xcall and xint") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/kernel/cpufeature.c | 4 ---- arch/arm64/kvm/sys_regs.c | 6 ++++-- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 672accbd5b4a..053a95cdcec7 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2523,10 +2523,6 @@ static void cpu_enable_arch_xcall_xint(const struct arm64_cpu_capabilities *__un el = read_sysreg(CurrentEL); if (el == CurrentEL_EL2) { - /* - * Enable EL2 trap when access ACTLR_EL1 in guest kernel. - */ - write_sysreg_s(read_sysreg_s(SYS_HCR_EL2) | HCR_TACR, SYS_HCR_EL2); actlr_el2 = read_sysreg(actlr_el2); actlr_el2 |= ACTLR_ELx_XINT; write_sysreg(actlr_el2, actlr_el2); diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index ff00ad782d7d..9a404daeb2ff 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -281,8 +281,10 @@ static bool access_actlr(struct kvm_vcpu *vcpu, { u64 mask, shift; - if (p->is_write) - return ignore_write(vcpu, p); + if (p->is_write) { + vcpu_write_sys_reg(vcpu, p->regval, r->reg); + return true; + } get_access_mask(r, &mask, &shift); p->regval = (vcpu_read_sys_reg(vcpu, r->reg) & mask) >> shift; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2025-38006
by Wang Liang 25 Aug '25

25 Aug '25

Eric Dumazet (1): mctp: no longer rely on net->dev_index_head[] Matt Johnston (1): net: mctp: Don't access ifa_index when missing net/mctp/device.c | 65 ++++++++++++++++++++++------------------------- 1 file changed, 30 insertions(+), 35 deletions(-) -- 2.33.0

2 3