Re: [GIT PULL v1 16/23] KVM: s390: Fix leaking of PGM_ADDRESSING to userspace
[email protected] Mon, 03 Aug 2026 17:14:58 +0000
| Newsgroups | org.kernel.vger.linux-s390,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] 1-bit kernel stack memory leak to userspace via uninitialized bitf= ield in union skey. -- --- Patch [16]: [GIT PULL v1 16/23] KVM: s390: Fix leaking of PGM_ADDRESSIN= G to userspace --- commit 74696629bd13e2265747961c02030c7ac8a442d4 Author: Claudio Imbrenda <[email protected]> KVM: s390: Fix leaking of PGM_ADDRESSING to userspace =20 If kvm_s390_set_cmma_bits() is asked to set CMMA values outside of a memslot, PGM_ADDRESSING (5) is returned, instead of a negative error value. Fix by returning -EFAULT whenever the return value would be > 0. Link: https://lkml.kernel.org/r/[email protected].= com > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index 21574f57be72e..e162efaa35b8f 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c [ ... ] > @@ -571,7 +571,7 @@ static int kvm_s390_keyop(struct kvm_s390_mmu_cache *= mc, struct kvm *kvm, int op > switch (op) { > case KVM_S390_KEYOP_SSKE: > r =3D dat_cond_set_storage_key(mc, asce, gfn, skey, &skey, 0, 0, 0); > - if (r >=3D 0) > + if (r =3D=3D 0 || r =3D=3D 1) > return skey.skey; [Severity: High] This isn't a bug introduced by this patch, but does returning skey.skey here leak uninitialized kernel stack memory to userspace? Looking at dat_cond_set_storage_key() in arch/s390/kvm/dat.c, a local union skey prev is declared without initialization: union skey prev; When ptep->h.i is true, it assigns values to 4 of the 5 bitfields in prev, but the zero bitfield remains uninitialized and retains kernel stack garbag= e: } else { prev.acc =3D old.acc; prev.fp =3D old.fp; prev.c =3D old.gc; prev.r =3D old.gr; } This prev union is then copied to *oldkey: if (oldkey) *oldkey =3D prev; Since oldkey points to the local skey variable here in kvm_s390_keyop(), does returning skey.skey eventually leak this uninitialized zero bitfield to userspace when the result is copied via copy_to_user()? > break; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803160924.2368= [email protected]?part=3D16