linux-kernel - Re: [PATCH] KVM: arm64: fix u64_replace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4befb9eb-96e6-4a7c-9746-286144564f4e@app.fastmail.com>
Date: Fri, 11 Jul 2025 10:44:23 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Marc Zyngier" <maz@...nel.org>, "Arnd Bergmann" <arnd@...nel.org>
Cc: "Oliver Upton" <oliver.upton@...ux.dev>,
 "Catalin Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 "Joey Gouly" <joey.gouly@....com>,
 "Suzuki K Poulose" <suzuki.poulose@....com>,
 "Zenghui Yu" <yuzenghui@...wei.com>, "Mark Brown" <broonie@...nel.org>,
 "James Morse" <james.morse@....com>, "Sebastian Ott" <sebott@...hat.com>,
 linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: fix u64_replace_bits() usage

On Fri, Jul 11, 2025, at 10:36, Marc Zyngier wrote:
> On Fri, 11 Jul 2025 08:27:47 +0100, Arnd Bergmann <arnd@...nel.org> wrote:
>>  	if (hpmn > vcpu->kvm->arch.nr_pmu_counters) {
>>  		hpmn = vcpu->kvm->arch.nr_pmu_counters;
>> -		u64_replace_bits(val, hpmn, MDCR_EL2_HPMN);
>> +		val = u64_replace_bits(val, hpmn, MDCR_EL2_HPMN);
>>  	}
>>  
>>  	__vcpu_assign_sys_reg(vcpu, MDCR_EL2, val);
>
> This is only in -next, right? Because I have a fix for this already
> queued for 6.16, as per [1].

Yes, as far as I can tell, the warning only showed up in linux-next
after f66f9c3d09c1 ("bitfield: Ensure the return values of helper
functions are checked").

As far as I can tell, Ben added the check in linux/bitfield.h
when he sent you his version of the fix, they just ended up
in linux-next in the wrong order, so I ended up recreating his
original fix slightly differently.

      Arnd