[PATCH v2 0/7] KVM: arm64: Fix missing ESR_ELx.IL in syndrome injection

[PATCH v2 0/7] KVM: arm64: Fix missing ESR_ELx.IL in syndrome injection

[Fuad Tabba]

Hi folks,

After sashiko caught the missing IL bug [1], I did an audit of all ESR
syndrome construction sites in KVM/arm64 as Marc suggested. This series
is the result of that audit.

The ARM architecture mandates ESR_ELx.IL=1 for several exception
classes regardless of instruction length: EC=Unknown, Instruction
Aborts, Data Aborts with ISV=0, and SError. For FPAC (EC=0x1C), IL
reflects instruction length, but FPAC can only be generated by A64
instructions, so IL must also be 1.

Patch 1 is the bug sashiko found: inject_undef64() in the pKVM hyp (EL2)
path never set IL. Patch 2 makes the same fix to inject_undef64() in the
normal host path, where IL was derived from the triggering trap's
instruction length. No instruction that reaches undef injection has a
16-bit encoding, so patch 2 has no functional change today.
Patch 3 makes the matching fix to inject_abt64(). Unlike undef
injection, abort injection is reachable from a 16-bit T32 instruction (a
32-bit EL0 task under an AArch64 EL1 guest), so the old code there
injects an abort with IL=0.
Patch 4 fixes the FPAC syndrome constructed during nested ERET
emulation, which did not set IL.
Patches 5-6 fix SError injection in the emulated and nested paths,
neither of which set IL.
Patch 7 fixes a fake ESR used to exit to the host. The host does not
read IL there, so it is not guest-visible.

Changes since v1 [2]:
- Patch 4: keep IL by masking it through from the trapped ERET's ESR
  instead of OR-ing the bit in. The ERET trap (EC=0x1A) always reports
  IL=1, so this preserves the source syndrome rather than adding the
  bit unconditionally (Marc).
- Rebased on v7.1.

Cheers,
/fuad

[1] https://lore.kernel.org/all/87pl1t8q24.wl-maz@kernel.org/
[2] https://lore.kernel.org/all/20260614163336.3490925-1-tabba@google.com/

Signed-off-by: Fuad Tabba <tabba@google.com>

Fuad Tabba (7):
  KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
  KVM: arm64: Unconditionally set IL for injected undefined exceptions
  KVM: arm64: Unconditionally set IL for injected abort exceptions
  KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
  KVM: arm64: Set IL for emulated SError injection
  KVM: arm64: Set IL for nested SError injection
  KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit

 arch/arm64/kvm/emulate-nested.c    |  4 ++--
 arch/arm64/kvm/hyp/nvhe/pkvm.c     |  3 ++-
 arch/arm64/kvm/hyp/nvhe/sys_regs.c |  2 +-
 arch/arm64/kvm/inject_fault.c      | 18 +++++-------------
 4 files changed, 10 insertions(+), 17 deletions(-)

-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 1/7] KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2

[Fuad Tabba]

inject_undef64() constructs an ESR with EC=0 (Unknown) but does not set
IL. The architecture mandates IL=1 for EC=0 unconditionally (ARM DDI
0487, ESR_ELx.IL description), so the injected syndrome is one that
conforming hardware cannot produce.

Set ESR_ELx_IL in the constructed syndrome.

Fixes: e5d40a5a97c1 ("KVM: arm64: pkvm: Add a generic synchronous exception injection primitive")
Reported-by: sashiko <sashiko@sashiko.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
index 8c3fbb413a06..9767adf1f73e 100644
--- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
+++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
@@ -278,7 +278,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
  */
 static void inject_undef64(struct kvm_vcpu *vcpu)
 {
-	inject_sync64(vcpu, (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT));
+	inject_sync64(vcpu, (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL);
 }
 
 static u64 read_id_reg(const struct kvm_vcpu *vcpu,
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions

[Fuad Tabba]

inject_undef64() derives IL from the triggering trap's instruction
length (kvm_vcpu_trap_il_is32bit()), but the IL of the injected
exception is fixed by its EC, not by the triggering instruction. The
architecture mandates IL=1 for EC=0 (Unknown) unconditionally, so the
conditional is wrong. The undef-injection paths are not reached from
16-bit instructions, so there is no functional change today, but the
logic should not rely on that.

Set ESR_ELx_IL unconditionally.

Fixes: aa8eff9bfbd5 ("arm64: KVM: fault injection into a guest")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/inject_fault.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 89982bd3345f..9dfae1bcdf99 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -170,14 +170,7 @@ void kvm_inject_sync(struct kvm_vcpu *vcpu, u64 esr)
 
 static void inject_undef64(struct kvm_vcpu *vcpu)
 {
-	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
-
-	/*
-	 * Build an unknown exception, depending on the instruction
-	 * set.
-	 */
-	if (kvm_vcpu_trap_il_is32bit(vcpu))
-		esr |= ESR_ELx_IL;
+	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
 
 	kvm_inject_sync(vcpu, esr);
 }
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 3/7] KVM: arm64: Unconditionally set IL for injected abort exceptions

[Fuad Tabba]

inject_abt64() derives IL from the triggering trap's instruction length
(kvm_vcpu_trap_il_is32bit()), but the IL of the injected abort is fixed
by its EC, not by the triggering instruction. The architecture mandates
IL=1 for Instruction Aborts unconditionally and for Data Aborts with
ISV=0, and this function never sets ISV (the FSC is always EXTABT or
SEA_TTW). For a 16-bit T32 trap (a 32-bit EL0 task under an AArch64 EL1
guest) the trap has IL=0, so the abort is injected with the wrong IL.

Set ESR_ELx_IL unconditionally.

Fixes: aa8eff9bfbd5 ("arm64: KVM: fault injection into a guest")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/inject_fault.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 9dfae1bcdf99..444d219b0217 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -138,11 +138,10 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
 		pend_sync_exception(vcpu);
 
 	/*
-	 * Build an {i,d}abort, depending on the level and the
-	 * instruction set. Report an external synchronous abort.
+	 * Build an {i,d}abort, depending on the level.
+	 * Report an external synchronous abort.
 	 */
-	if (kvm_vcpu_trap_il_is32bit(vcpu))
-		esr |= ESR_ELx_IL;
+	esr |= ESR_ELx_IL;
 
 	/*
 	 * Here, the guest runs in AArch64 mode when in EL1. If we get
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[Fuad Tabba]

The FPAC syndrome constructed during nested ERET emulation does not set
IL. For FPAC (EC=0x1C), IL reflects the instruction length. ERET and
its authenticated variants are always A64 32-bit instructions, so IL
must be 1.

Fixes: 213b3d1ea161 ("KVM: arm64: nv: Handle ERETA[AB] instructions")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/emulate-nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index dba7ced74ca5..b74369e9ad7f 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
 		 * ERET handling, and the guest will have a little surprise.
 		 */
 		if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
-			esr &= ESR_ELx_ERET_ISS_ERETA;
+			esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
 			esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
 			kvm_inject_nested_sync(vcpu, esr);
 			return;
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 5/7] KVM: arm64: Set IL for emulated SError injection

[Fuad Tabba]

kvm_inject_serror_esr() constructs an SError syndrome without IL. The
architecture mandates IL=1 for SError unconditionally.

Fixes: f6e2262dfa1a ("KVM: arm64: Populate ESR_ELx.EC for emulated SError injection")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/inject_fault.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 444d219b0217..d6c4fc16f879 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -381,7 +381,7 @@ int kvm_inject_serror_esr(struct kvm_vcpu *vcpu, u64 esr)
 	 */
 	if (!serror_is_masked(vcpu)) {
 		pend_serror_exception(vcpu);
-		esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
+		esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
 		vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
 		return 1;
 	}
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 6/7] KVM: arm64: Set IL for nested SError injection

[Fuad Tabba]

kvm_inject_nested_serror() constructs an SError syndrome without IL.
The architecture mandates IL=1 for SError unconditionally.

Fixes: 77ee70a07357 ("KVM: arm64: nv: Honor SError exception routing / masking")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/emulate-nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index b74369e9ad7f..6f12496cae81 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2938,6 +2938,6 @@ int kvm_inject_nested_serror(struct kvm_vcpu *vcpu, u64 esr)
 	 * vSError injection. Manually populate EC for an emulated SError
 	 * exception.
 	 */
-	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
+	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
 	return kvm_inject_nested(vcpu, esr, except_type_serror);
 }
-- 
2.54.0.1189.g8c84645362-goog

[PATCH v2 7/7] KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit

[Fuad Tabba]

__pkvm_memshare_page_req() constructs a fake DABT ESR_EL2 to exit to
the host without setting IL. The ESR has ISV=0, so IL must be 1 per the
architecture. The host does not read IL on this path, but the
constructed syndrome should still be architecturally valid.

Set ESR_ELx_IL.

Fixes: 03313efed5e2 ("KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..c982a3a04c37 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -1054,7 +1054,8 @@ static u64 __pkvm_memshare_page_req(struct kvm_vcpu *vcpu, u64 ipa)
 
 	/* Fake up a data abort (level 3 translation fault on write) */
 	vcpu->arch.fault.esr_el2 = (ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT) |
-				   ESR_ELx_WNR | ESR_ELx_FSC_FAULT |
+				   ESR_ELx_IL | ESR_ELx_WNR |
+				   ESR_ELx_FSC_FAULT |
 				   FIELD_PREP(ESR_ELx_FSC_LEVEL, 3);
 
 	/* Shuffle the IPA around into the HPFAR */
-- 
2.54.0.1189.g8c84645362-goog

Re: [PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The constructed FPAC exception syndrome incorrectly maps the ERET ISS encoding directly to the FPAC ISS encoding, resulting in malformed ISS[2:0] bits being injected into the guest.
--

commit 27996a8004c4285e2d114067b3fc644f3f649d64
Author: Fuad Tabba <tabba@google.com>
KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

This commit sets the IL (Instruction Length) bit for the FPAC syndrome
constructed during nested ERET emulation. Since ERET and its authenticated
variants are always A64 32-bit instructions, the IL bit must be set to 1.

> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index dba7ced74ca5e..b74369e9ad7ff 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
>  		 * ERET handling, and the guest will have a little surprise.
>  		 */
>  		if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> -			esr &= ESR_ELx_ERET_ISS_ERETA;
> +			esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);

[Severity: High]
This isn't a bug introduced by this patch, but does this mapping of the ERET
ISS to the FPAC ISS result in malformed ISS[2:0] bits being injected into
the guest?

For an ERET trap (EC=0x1A), ISS[0] indicates the key used (0 for ERETAA,
1 for ERETAB). For an FPAC exception (EC=0x1C), ISS[0] is the Instruction
Type (must be 1 for a branch/return instruction), and ISS[2:1] indicates
the Authentication Key.

By retaining the ERET ISS[0] bit and clearing the rest, it appears KVM
inadvertently maps the ERET key type directly into the FPAC Instruction
Type bit, while leaving the FPAC key type (ISS[2:1]) always at 00.

Consequently, wouldn't ERETAA be injected with an FPAC ISS of 0 (wrong
instruction type), and ERETAB get an FPAC ISS of 1 (wrong key type)?

>  			esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
>  			kvm_inject_nested_sync(vcpu, esr);
>  			return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=4

Re: [PATCH v2 3/7] KVM: arm64: Unconditionally set IL for injected abort exceptions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional IL=1 in inject_abt64() creates invalid ESR state for Address Size faults.
--

commit 5d93cc0ddb43cdfa88e555d446e07e55b7334637
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Unconditionally set IL for injected abort exceptions

This commit unconditionally sets the ESR_ELx_IL bit to 1 for injected
aborts, assuming the FSC is always EXTABT or SEA_TTW.

> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 9dfae1bcdf992..444d219b02174 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c

[ ... ]

> @@ -138,11 +138,10 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
>  		pend_sync_exception(vcpu);
>  
>  	/*
> -	 * Build an {i,d}abort, depending on the level and the
> -	 * instruction set. Report an external synchronous abort.
> +	 * Build an {i,d}abort, depending on the level.
> +	 * Report an external synchronous abort.
>  	 */
> -	if (kvm_vcpu_trap_il_is32bit(vcpu))
> -		esr |= ESR_ELx_IL;
> +	esr |= ESR_ELx_IL;

[Severity: High]
Does this unconditional setting of IL=1 cause an architecturally invalid
syndrome for Address Size faults?

If a guest executing in AArch32 EL0 issues a 16-bit instruction (such as a
16-bit LDR) that triggers a Stage-2 Address Size fault, the IL bit should
accurately reflect the size of the trapped instruction (0 for 16-bit).

Looking at kvm_inject_size_fault(), it injects the abort by calling
inject_abt64() via the __kvm_inject_sea() call chain, and then modifies the
FSC to 0 (Address Size Fault):

arch/arm64/kvm/inject_fault.c:kvm_inject_size_fault() {
    ...
    /* inject_abt64() forces IL=1 earlier in the call chain */
    ...
    esr &= ~GENMASK_ULL(5, 0);
    vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
    ...
}

Will KVM now inject the Address Size fault with IL=1 instead of IL=0,
potentially causing the guest OS exception handler to incorrectly advance
the Program Counter by 4 bytes instead of 2 during fault unwinding?

>  
>  	/*
>  	 * Here, the guest runs in AArch64 mode when in EL1. If we get

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=3

Re: [PATCH v2 2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Nested SError exception injection silently drops the ESR_EL2 value.
--

commit e7d1337c1e8d6db55c7b9ce2682f4c52e85c3f44
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Unconditionally set IL for injected undefined exceptions

This commit simplifies the inject_undef64() exception injection path by
unconditionally setting the IL bit, as the architecture mandates IL=1 for
EC=0 (Unknown).

> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 89982bd3345f6..9dfae1bcdf992 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -170,14 +170,7 @@ void kvm_inject_sync(struct kvm_vcpu *vcpu, u64 esr)
>  
>  static void inject_undef64(struct kvm_vcpu *vcpu)
>  {
> -	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
> -
> -	/*
> -	 * Build an unknown exception, depending on the instruction
> -	 * set.
> -	 */
> -	if (kvm_vcpu_trap_il_is32bit(vcpu))
> -		esr |= ESR_ELx_IL;
> +	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
>  
>  	kvm_inject_sync(vcpu, esr);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the exception
injection changes, I noticed a pre-existing issue in the nested SError
injection path.

In arch/arm64/kvm/emulate-nested.c, kvm_inject_nested_serror() constructs
the ESR for the nested SError and passes it down to kvm_inject_nested():

arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_serror() {
	...
	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
	return kvm_inject_nested(vcpu, esr, except_type_serror);
}

However, when this esr reaches kvm_inject_el2_exception(), the value is
silently discarded:

arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception() {
	...
	switch (type) {
	case except_type_sync:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SYNC);
		vcpu_write_sys_reg(vcpu, esr_el2, ESR_EL2);
		break;
	case except_type_irq:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_IRQ);
		break;
	case except_type_serror:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
		break;
	...
}

Because the except_type_serror case breaks without writing esr_el2 to
ESR_EL2 (unlike the except_type_sync case), the constructed syndrome is
completely dropped.

Since enter_exception64() does not dynamically update ESR_ELx, will the
guest hypervisor observe a stale ESR_EL2 when handling the injected SError?

Could this cause the guest to misinterpret the error, potentially leading
to incorrect functional behavior or a guest panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=2

Re: [PATCH v2 5/7] KVM: arm64: Set IL for emulated SError injection

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] kvm_inject_nested_sea() passes an Instruction/Data Abort EC instead of an SError EC when FEAT_EASE converts a Synchronous External Abort into an SError.
- [High] The constructed ESR for a nested SError is discarded during injection because kvm_inject_el2_exception() never writes it to the guest's ESR_EL2.
--

commit da891cfcd9b452feacd8b631f8c20dae39b009fc
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Set IL for emulated SError injection

kvm_inject_serror_esr() constructs an SError syndrome without IL. The
architecture mandates IL=1 for SError unconditionally.

> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 444d219b02174..d6c4fc16f8795 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -381,7 +381,7 @@ int kvm_inject_serror_esr(struct kvm_vcpu *vcpu, u64 esr)
>  	 */
>  	if (!serror_is_masked(vcpu)) {
>  		pend_serror_exception(vcpu);
> -		esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
> +		esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
>  		vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
>  		return 1;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this SError
injection logic, I noticed an issue in how ESR is constructed for nested
SErrors. When SCTLR2_ELx.EASE is set and a Synchronous External Abort is
converted to an SError, does kvm_inject_nested_sea() pass an incorrect
Exception Class?

In arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_sea():

	if (__vcpu_sys_reg(vcpu, SCTLR2_EL2) & SCTLR2_EL1_EASE)
		return kvm_inject_nested(vcpu, esr, except_type_serror);

The esr variable retains the previously constructed IABT/DABT Exception
Class instead of being reconstructed with ESR_ELx_EC_SERROR. Does this
present an invalid syndrome to the nested guest hypervisor, since the
architecture mandates that ESR_ELx.EC must be 0x2F (SError) when an
External abort is treated as an SError? 

Also, does this unconditionally update FAR_EL2, which is architecturally
incorrect for an SError?

[Severity: High]
This is also a pre-existing issue, but there appears to be a problem where
the constructed ESR for a nested SError is discarded during injection. Does
kvm_inject_el2_exception() fail to write the esr_el2 argument to ESR_EL2?

In arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception():

	case except_type_serror:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
		break;

Unlike the synchronous exception case, the esr_el2 argument isn't written
to the guest's ESR_EL2. Since the downstream exception entry path
enter_exception64() does not write ESR_ELx, does this result in the nested
guest hypervisor receiving an SError with a stale, unmodified ESR_EL2?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=5

Re: [PATCH v2 6/7] KVM: arm64: Set IL for nested SError injection

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The SError syndrome constructed by `kvm_inject_nested_serror()` (including the newly added IL bit) is a dead store because the downstream injection logic silently drops the syndrome.
- [High] When a Synchronous External Abort is routed to an SError via FEAT_DoubleFault2 (`EASE`), KVM incorrectly populates the ESR with an IABT or DABT Exception Class (EC) instead of the architectural SError EC.
--

commit 889dc0193654a25a0ce52006ebe91e58fc4c4ed8
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Set IL for nested SError injection

This patch modifies kvm_inject_nested_serror() to unconditionally set the IL
bit in the SError syndrome, as mandated by the architecture.

> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index b74369e9ad7ff..6f12496cae815 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2938,6 +2938,6 @@ int kvm_inject_nested_serror(struct kvm_vcpu *vcpu, u64 esr)
>  	 * vSError injection. Manually populate EC for an emulated SError
>  	 * exception.
>  	 */
> -	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
> +	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
>  	return kvm_inject_nested(vcpu, esr, except_type_serror);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but does the constructed syndrome
value get silently dropped downstream?

Looking at kvm_inject_nested(), it forwards the esr to
kvm_inject_el2_exception():

arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception() {
    ...
    case except_type_serror:
        kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
        break;
    ...
}

The except_type_serror case doesn't write esr_el2 to ESR_EL2 (unlike the
except_type_sync case), and downstream exception entry code doesn't write
it either.

The constructed payload appears to be entirely discarded.

Would the nested hypervisor observe a stale ESR_EL2 value when taking the
SError, rendering this fix functionally ineffective?

[Severity: High]
This is a pre-existing issue, but when a Synchronous External Abort is routed
to an SError via EASE (FEAT_DoubleFault2), does KVM incorrectly populate the
ESR with an Abort Exception Class instead of SError?

In kvm_inject_nested_sea(), if SCTLR2_EL1_EASE is set, an SError is requested
using an ESR constructed with an Abort EC:

arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_sea() {
    ...
    if (__vcpu_sys_reg(vcpu, SCTLR2_EL2) & SCTLR2_EL1_EASE)
        return kvm_inject_nested(vcpu, esr, except_type_serror);
    ...
}

Similarly in arch/arm64/kvm/inject_fault.c:inject_abt64(), the ESR is
populated with ESR_ELx_EC_IABT_* or ESR_ELx_EC_DABT_* before being written.

Architecturally, all SError interrupts must have an SError Exception Class,
even when representing a routed SEA.

Does supplying an Abort EC violate the architecture and provide the guest with
a malformed exception syndrome?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=6

Re: [PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:28, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The constructed FPAC exception syndrome incorrectly maps the ERET ISS encoding directly to the FPAC ISS encoding, resulting in malformed ISS[2:0] bits being injected into the guest.
> --
>
> commit 27996a8004c4285e2d114067b3fc644f3f649d64
> Author: Fuad Tabba <tabba@google.com>
> KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
>
> This commit sets the IL (Instruction Length) bit for the FPAC syndrome
> constructed during nested ERET emulation. Since ERET and its authenticated
> variants are always A64 32-bit instructions, the IL bit must be set to 1.
>
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5e..b74369e9ad7ff 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> >                * ERET handling, and the guest will have a little surprise.
> >                */
> >               if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> > -                     esr &= ESR_ELx_ERET_ISS_ERETA;
> > +                     esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does this mapping of the ERET
> ISS to the FPAC ISS result in malformed ISS[2:0] bits being injected into
> the guest?
>
> For an ERET trap (EC=0x1A), ISS[0] indicates the key used (0 for ERETAA,
> 1 for ERETAB). For an FPAC exception (EC=0x1C), ISS[0] is the Instruction
> Type (must be 1 for a branch/return instruction), and ISS[2:1] indicates
> the Authentication Key.
>
> By retaining the ERET ISS[0] bit and clearing the rest, it appears KVM
> inadvertently maps the ERET key type directly into the FPAC Instruction
> Type bit, while leaving the FPAC key type (ISS[2:1]) always at 00.
>
> Consequently, wouldn't ERETAA be injected with an FPAC ISS of 0 (wrong
> instruction type), and ERETAB get an FPAC ISS of 1 (wrong key type)?

The FPAC (EC=0x1C) ISS encoding is two bits, not three:

  ISS[0] (BnA): 0 = A-key, 1 = B-key
  ISS[1] (DnI): 0 = Instruction key, 1 = Data key

The mask (ESR_ELx_ERET_ISS_ERETA = 0x1) keeps ISS[0], which has the
same A-vs-B semantics in both the ERET and FPAC encodings, and clears
ISS[1], giving DnI=0 (Instruction key), which is correct since
ERETAA/ERETAB always use instruction keys.

Thanks,
/fuad


>
> >                       esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
> >                       kvm_inject_nested_sync(vcpu, esr);
> >                       return;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=4

Re: [PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[Marc Zyngier]

On Thu, 18 Jun 2026 13:28:07 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The constructed FPAC exception syndrome incorrectly maps the ERET ISS encoding directly to the FPAC ISS encoding, resulting in malformed ISS[2:0] bits being injected into the guest.
> --
> 
> commit 27996a8004c4285e2d114067b3fc644f3f649d64
> Author: Fuad Tabba <tabba@google.com>
> KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
> 
> This commit sets the IL (Instruction Length) bit for the FPAC syndrome
> constructed during nested ERET emulation. Since ERET and its authenticated
> variants are always A64 32-bit instructions, the IL bit must be set to 1.
> 
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5e..b74369e9ad7ff 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> >  		 * ERET handling, and the guest will have a little surprise.
> >  		 */
> >  		if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> > -			esr &= ESR_ELx_ERET_ISS_ERETA;
> > +			esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but does this mapping of the ERET
> ISS to the FPAC ISS result in malformed ISS[2:0] bits being injected into
> the guest?
> 
> For an ERET trap (EC=0x1A), ISS[0] indicates the key used (0 for ERETAA,
> 1 for ERETAB). For an FPAC exception (EC=0x1C), ISS[0] is the Instruction
> Type (must be 1 for a branch/return instruction), and ISS[2:1] indicates
> the Authentication Key.

No. Not at all. ESR_ELx_EC_FPAC (0x1C) defines ISS[0] as BnA. Which
matches the definition for ERET. On purpose. See ARM DDI 0487, version
M.b, D24-8777.

>
> By retaining the ERET ISS[0] bit and clearing the rest, it appears KVM
> inadvertently maps the ERET key type directly into the FPAC Instruction
> Type bit, while leaving the FPAC key type (ISS[2:1]) always at 00.
> 
> Consequently, wouldn't ERETAA be injected with an FPAC ISS of 0 (wrong
> instruction type), and ERETAB get an FPAC ISS of 1 (wrong key type)?

Yes, and that'd be correct.

I don't know who told Sashiko about the ARM ARM, but it doesn't seem
to parse it correctly.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:48, Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 18 Jun 2026 13:28:07 +0100,
> sashiko-bot@kernel.org wrote:
> >
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> >
> > Pre-existing issues:
> > - [High] The constructed FPAC exception syndrome incorrectly maps the ERET ISS encoding directly to the FPAC ISS encoding, resulting in malformed ISS[2:0] bits being injected into the guest.
> > --
> >
> > commit 27996a8004c4285e2d114067b3fc644f3f649d64
> > Author: Fuad Tabba <tabba@google.com>
> > KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
> >
> > This commit sets the IL (Instruction Length) bit for the FPAC syndrome
> > constructed during nested ERET emulation. Since ERET and its authenticated
> > variants are always A64 32-bit instructions, the IL bit must be set to 1.
> >
> > > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > > index dba7ced74ca5e..b74369e9ad7ff 100644
> > > --- a/arch/arm64/kvm/emulate-nested.c
> > > +++ b/arch/arm64/kvm/emulate-nested.c
> > > @@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> > >              * ERET handling, and the guest will have a little surprise.
> > >              */
> > >             if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> > > -                   esr &= ESR_ELx_ERET_ISS_ERETA;
> > > +                   esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
> >
> > [Severity: High]
> > This isn't a bug introduced by this patch, but does this mapping of the ERET
> > ISS to the FPAC ISS result in malformed ISS[2:0] bits being injected into
> > the guest?
> >
> > For an ERET trap (EC=0x1A), ISS[0] indicates the key used (0 for ERETAA,
> > 1 for ERETAB). For an FPAC exception (EC=0x1C), ISS[0] is the Instruction
> > Type (must be 1 for a branch/return instruction), and ISS[2:1] indicates
> > the Authentication Key.
>
> No. Not at all. ESR_ELx_EC_FPAC (0x1C) defines ISS[0] as BnA. Which
> matches the definition for ERET. On purpose. See ARM DDI 0487, version
> M.b, D24-8777.
>
> >
> > By retaining the ERET ISS[0] bit and clearing the rest, it appears KVM
> > inadvertently maps the ERET key type directly into the FPAC Instruction
> > Type bit, while leaving the FPAC key type (ISS[2:1]) always at 00.
> >
> > Consequently, wouldn't ERETAA be injected with an FPAC ISS of 0 (wrong
> > instruction type), and ERETAB get an FPAC ISS of 1 (wrong key type)?
>
> Yes, and that'd be correct.
>
> I don't know who told Sashiko about the ARM ARM, but it doesn't seem
> to parse it correctly.

The problem is that it _doesn't_ have the ARM ARM, so it hallucinates
it. I'll reply to the other ones, and then see if I can write up a PR
to review-prompts to fix this.

Cheers,
/fuad

>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Re: [PATCH v2 2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:30, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Nested SError exception injection silently drops the ESR_EL2 value.
> --
>
> commit e7d1337c1e8d6db55c7b9ce2682f4c52e85c3f44
> Author: Fuad Tabba <tabba@google.com>
>
> KVM: arm64: Unconditionally set IL for injected undefined exceptions
>
> This commit simplifies the inject_undef64() exception injection path by
> unconditionally setting the IL bit, as the architecture mandates IL=1 for
> EC=0 (Unknown).
>
> > diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 89982bd3345f6..9dfae1bcdf992 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -170,14 +170,7 @@ void kvm_inject_sync(struct kvm_vcpu *vcpu, u64 esr)
> >
> >  static void inject_undef64(struct kvm_vcpu *vcpu)
> >  {
> > -     u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
> > -
> > -     /*
> > -      * Build an unknown exception, depending on the instruction
> > -      * set.
> > -      */
> > -     if (kvm_vcpu_trap_il_is32bit(vcpu))
> > -             esr |= ESR_ELx_IL;
> > +     u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
> >
> >       kvm_inject_sync(vcpu, esr);
> >  }
>
> [Severity: High]
> This isn't a bug introduced by this patch, but while reviewing the exception
> injection changes, I noticed a pre-existing issue in the nested SError
> injection path.
>
> In arch/arm64/kvm/emulate-nested.c, kvm_inject_nested_serror() constructs
> the ESR for the nested SError and passes it down to kvm_inject_nested():
>
> arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_serror() {
>         ...
>         esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
>         return kvm_inject_nested(vcpu, esr, except_type_serror);
> }
>
> However, when this esr reaches kvm_inject_el2_exception(), the value is
> silently discarded:
>
> arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception() {
>         ...
>         switch (type) {
>         case except_type_sync:
>                 kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SYNC);
>                 vcpu_write_sys_reg(vcpu, esr_el2, ESR_EL2);
>                 break;
>         case except_type_irq:
>                 kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_IRQ);
>                 break;
>         case except_type_serror:
>                 kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
>                 break;
>         ...
> }
>
> Because the except_type_serror case breaks without writing esr_el2 to
> ESR_EL2 (unlike the except_type_sync case), the constructed syndrome is
> completely dropped.
>
> Since enter_exception64() does not dynamically update ESR_ELx, will the
> guest hypervisor observe a stale ESR_EL2 when handling the injected SError?
>
> Could this cause the guest to misinterpret the error, potentially leading
> to incorrect functional behavior or a guest panic?

IL=1 is correct here. The architecture mandates IL=1 for any
Instruction Abort unconditionally, and for any Data Abort where ISV=0
(ARM ARM, ESR_ELx IL bit definition). IL only reflects the faulting
instruction length when ISV=1.

This function never sets ISV. The FSC is always EXTABT or SEA_TTW, and
FEAT_RAS mandates ISV=0 for any synchronous external abort. The
Address Size Fault case (kvm_inject_size_fault overwriting FSC to 0)
also has ISV=0 since address size faults are detected during
translation table walks with no valid instruction syndrome.

The old code copying IL from the hardware trap ESR was the bug: it
produced IL=0 for a 16-bit Thumb instruction, which is wrong for an
ISV=0 data abort.

Cheers,
/fuad


>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=2

Re: [PATCH v2 3/7] KVM: arm64: Unconditionally set IL for injected abort exceptions

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:29, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Unconditional IL=1 in inject_abt64() creates invalid ESR state for Address Size faults.
> --
>
> commit 5d93cc0ddb43cdfa88e555d446e07e55b7334637
> Author: Fuad Tabba <tabba@google.com>
>
> KVM: arm64: Unconditionally set IL for injected abort exceptions
>
> This commit unconditionally sets the ESR_ELx_IL bit to 1 for injected
> aborts, assuming the FSC is always EXTABT or SEA_TTW.
>
> > diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 9dfae1bcdf992..444d219b02174 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
>
> [ ... ]
>
> > @@ -138,11 +138,10 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
> >               pend_sync_exception(vcpu);
> >
> >       /*
> > -      * Build an {i,d}abort, depending on the level and the
> > -      * instruction set. Report an external synchronous abort.
> > +      * Build an {i,d}abort, depending on the level.
> > +      * Report an external synchronous abort.
> >        */
> > -     if (kvm_vcpu_trap_il_is32bit(vcpu))
> > -             esr |= ESR_ELx_IL;
> > +     esr |= ESR_ELx_IL;
>
> [Severity: High]
> Does this unconditional setting of IL=1 cause an architecturally invalid
> syndrome for Address Size faults?
>
> If a guest executing in AArch32 EL0 issues a 16-bit instruction (such as a
> 16-bit LDR) that triggers a Stage-2 Address Size fault, the IL bit should
> accurately reflect the size of the trapped instruction (0 for 16-bit).
>
> Looking at kvm_inject_size_fault(), it injects the abort by calling
> inject_abt64() via the __kvm_inject_sea() call chain, and then modifies the
> FSC to 0 (Address Size Fault):
>
> arch/arm64/kvm/inject_fault.c:kvm_inject_size_fault() {
>     ...
>     /* inject_abt64() forces IL=1 earlier in the call chain */
>     ...
>     esr &= ~GENMASK_ULL(5, 0);
>     vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
>     ...
> }
>
> Will KVM now inject the Address Size fault with IL=1 instead of IL=0,
> potentially causing the guest OS exception handler to incorrectly advance
> the Program Counter by 4 bytes instead of 2 during fault unwinding?

See https://lore.kernel.org/all/CA+EHjTyiyCNV40z82=YTTMrx3BoR5gn5uh-xP80gFxX2PSUMAg@mail.gmail.com/

>
> >
> >       /*
> >        * Here, the guest runs in AArch64 mode when in EL1. If we get
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=3

Re: [PATCH v2 5/7] KVM: arm64: Set IL for emulated SError injection

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:32, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] kvm_inject_nested_sea() passes an Instruction/Data Abort EC instead of an SError EC when FEAT_EASE converts a Synchronous External Abort into an SError.

Not a bug. EASE does not convert the exception to an SError. It only
changes the vector offset. The EC remains the original abort EC. The
non-nested path in inject_abt64() does the same thing. FAR_EL2 is also
correct since the exception is still a synchronous abort.

> - [High] The constructed ESR for a nested SError is discarded during injection because kvm_inject_el2_exception() never writes it to the guest's ESR_EL2.

https://lore.kernel.org/all/20260615131116.390977-1-tabba@google.com/

Thanks,
/fuad

> --
>
> commit da891cfcd9b452feacd8b631f8c20dae39b009fc
> Author: Fuad Tabba <tabba@google.com>
>
> KVM: arm64: Set IL for emulated SError injection
>
> kvm_inject_serror_esr() constructs an SError syndrome without IL. The
> architecture mandates IL=1 for SError unconditionally.
>
> > diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 444d219b02174..d6c4fc16f8795 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -381,7 +381,7 @@ int kvm_inject_serror_esr(struct kvm_vcpu *vcpu, u64 esr)
> >        */
> >       if (!serror_is_masked(vcpu)) {
> >               pend_serror_exception(vcpu);
> > -             esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
> > +             esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
> >               vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
> >               return 1;
> >       }
>
> [Severity: High]
> This isn't a bug introduced by this patch, but while reviewing this SError
> injection logic, I noticed an issue in how ESR is constructed for nested
> SErrors. When SCTLR2_ELx.EASE is set and a Synchronous External Abort is
> converted to an SError, does kvm_inject_nested_sea() pass an incorrect
> Exception Class?
>
> In arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_sea():
>
>         if (__vcpu_sys_reg(vcpu, SCTLR2_EL2) & SCTLR2_EL1_EASE)
>                 return kvm_inject_nested(vcpu, esr, except_type_serror);
>
> The esr variable retains the previously constructed IABT/DABT Exception
> Class instead of being reconstructed with ESR_ELx_EC_SERROR. Does this
> present an invalid syndrome to the nested guest hypervisor, since the
> architecture mandates that ESR_ELx.EC must be 0x2F (SError) when an
> External abort is treated as an SError?
>
> Also, does this unconditionally update FAR_EL2, which is architecturally
> incorrect for an SError?
>
> [Severity: High]
> This is also a pre-existing issue, but there appears to be a problem where
> the constructed ESR for a nested SError is discarded during injection. Does
> kvm_inject_el2_exception() fail to write the esr_el2 argument to ESR_EL2?
>
> In arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception():
>
>         case except_type_serror:
>                 kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
>                 break;
>
> Unlike the synchronous exception case, the esr_el2 argument isn't written
> to the guest's ESR_EL2. Since the downstream exception entry path
> enter_exception64() does not write ESR_ELx, does this result in the nested
> guest hypervisor receiving an SError with a stale, unmodified ESR_EL2?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=5

Re: [PATCH v2 6/7] KVM: arm64: Set IL for nested SError injection

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:33, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The SError syndrome constructed by `kvm_inject_nested_serror()` (including the newly added IL bit) is a dead store because the downstream injection logic silently drops the syndrome.
> - [High] When a Synchronous External Abort is routed to an SError via FEAT_DoubleFault2 (`EASE`), KVM incorrectly populates the ESR with an IABT or DABT Exception Class (EC) instead of the architectural SError EC.

https://lore.kernel.org/all/CA+EHjTyJUrHZJiM9e2r20_1JLzWQg-+TAr9g720njugLMWTpGw@mail.gmail.com/

Cheers,
/fuad

> --
>
> commit 889dc0193654a25a0ce52006ebe91e58fc4c4ed8
> Author: Fuad Tabba <tabba@google.com>
>
> KVM: arm64: Set IL for nested SError injection
>
> This patch modifies kvm_inject_nested_serror() to unconditionally set the IL
> bit in the SError syndrome, as mandated by the architecture.
>
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index b74369e9ad7ff..6f12496cae815 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2938,6 +2938,6 @@ int kvm_inject_nested_serror(struct kvm_vcpu *vcpu, u64 esr)
> >        * vSError injection. Manually populate EC for an emulated SError
> >        * exception.
> >        */
> > -     esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
> > +     esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
> >       return kvm_inject_nested(vcpu, esr, except_type_serror);
> >  }
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does the constructed syndrome
> value get silently dropped downstream?
>
> Looking at kvm_inject_nested(), it forwards the esr to
> kvm_inject_el2_exception():
>
> arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception() {
>     ...
>     case except_type_serror:
>         kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
>         break;
>     ...
> }
>
> The except_type_serror case doesn't write esr_el2 to ESR_EL2 (unlike the
> except_type_sync case), and downstream exception entry code doesn't write
> it either.
>
> The constructed payload appears to be entirely discarded.
>
> Would the nested hypervisor observe a stale ESR_EL2 value when taking the
> SError, rendering this fix functionally ineffective?
>
> [Severity: High]
> This is a pre-existing issue, but when a Synchronous External Abort is routed
> to an SError via EASE (FEAT_DoubleFault2), does KVM incorrectly populate the
> ESR with an Abort Exception Class instead of SError?
>
> In kvm_inject_nested_sea(), if SCTLR2_EL1_EASE is set, an SError is requested
> using an ESR constructed with an Abort EC:
>
> arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_sea() {
>     ...
>     if (__vcpu_sys_reg(vcpu, SCTLR2_EL2) & SCTLR2_EL1_EASE)
>         return kvm_inject_nested(vcpu, esr, except_type_serror);
>     ...
> }
>
> Similarly in arch/arm64/kvm/inject_fault.c:inject_abt64(), the ESR is
> populated with ESR_ELx_EC_IABT_* or ESR_ELx_EC_DABT_* before being written.
>
> Architecturally, all SError interrupts must have an SError Exception Class,
> even when representing a routed SEA.
>
> Does supplying an Abort EC violate the architecture and provide the guest with
> a malformed exception syndrome?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=6

Re: [PATCH v2 0/7] KVM: arm64: Fix missing ESR_ELx.IL in syndrome injection

[Fuad Tabba]

On Thu, 18 Jun 2026 at 13:16, Fuad Tabba <tabba@google.com> wrote:
>
> Hi folks,
>
> After sashiko caught the missing IL bug [1], I did an audit of all ESR
> syndrome construction sites in KVM/arm64 as Marc suggested. This series
> is the result of that audit.

FWIW, went through all the issues Sashiko raised [1]; the only real
bug it found is the one we already fixed [2].

Cheers,
/fuad

[1] https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com
[2] https://lore.kernel.org/all/20260615131116.390977-1-tabba@google.com/


>
> The ARM architecture mandates ESR_ELx.IL=1 for several exception
> classes regardless of instruction length: EC=Unknown, Instruction
> Aborts, Data Aborts with ISV=0, and SError. For FPAC (EC=0x1C), IL
> reflects instruction length, but FPAC can only be generated by A64
> instructions, so IL must also be 1.
>
> Patch 1 is the bug sashiko found: inject_undef64() in the pKVM hyp (EL2)
> path never set IL. Patch 2 makes the same fix to inject_undef64() in the
> normal host path, where IL was derived from the triggering trap's
> instruction length. No instruction that reaches undef injection has a
> 16-bit encoding, so patch 2 has no functional change today.
> Patch 3 makes the matching fix to inject_abt64(). Unlike undef
> injection, abort injection is reachable from a 16-bit T32 instruction (a
> 32-bit EL0 task under an AArch64 EL1 guest), so the old code there
> injects an abort with IL=0.
> Patch 4 fixes the FPAC syndrome constructed during nested ERET
> emulation, which did not set IL.
> Patches 5-6 fix SError injection in the emulated and nested paths,
> neither of which set IL.
> Patch 7 fixes a fake ESR used to exit to the host. The host does not
> read IL there, so it is not guest-visible.
>
> Changes since v1 [2]:
> - Patch 4: keep IL by masking it through from the trapped ERET's ESR
>   instead of OR-ing the bit in. The ERET trap (EC=0x1A) always reports
>   IL=1, so this preserves the source syndrome rather than adding the
>   bit unconditionally (Marc).
> - Rebased on v7.1.
>
> Cheers,
> /fuad
>
> [1] https://lore.kernel.org/all/87pl1t8q24.wl-maz@kernel.org/
> [2] https://lore.kernel.org/all/20260614163336.3490925-1-tabba@google.com/
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
>
> Fuad Tabba (7):
>   KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
>   KVM: arm64: Unconditionally set IL for injected undefined exceptions
>   KVM: arm64: Unconditionally set IL for injected abort exceptions
>   KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
>   KVM: arm64: Set IL for emulated SError injection
>   KVM: arm64: Set IL for nested SError injection
>   KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
>
>  arch/arm64/kvm/emulate-nested.c    |  4 ++--
>  arch/arm64/kvm/hyp/nvhe/pkvm.c     |  3 ++-
>  arch/arm64/kvm/hyp/nvhe/sys_regs.c |  2 +-
>  arch/arm64/kvm/inject_fault.c      | 18 +++++-------------
>  4 files changed, 10 insertions(+), 17 deletions(-)
>
> --
> 2.54.0.1189.g8c84645362-goog
>