Created attachment 16123 [details] Use volatile registers for 32B path The Power 10 implementation of strcmp in sysdeps/powerpc/powerpc64/le/power10/strcmp.S failed to save/restore nonvolatile vector registers in the 32-byte aligned loop path: L(32B_aligned_loop): COMPARE_32(v14,v16,0,tail1,tail2) COMPARE_32(v18,v20,32,tail3,tail4) COMPARE_32(v22,v24,64,tail5,tail6) COMPARE_32(v26,v28,96,tail7,tail8) addi r3,r3,128 addi r4,r4,128 b L(32B_aligned_loop) L(tail1): TAIL(v15,v17) L(tail2): TAIL(v14,v16) L(tail3): TAIL(v19,v21) L(tail4): TAIL(v18,v20) L(tail5): TAIL(v23,v25) L(tail6): TAIL(v22,v24) L(tail7): TAIL(v27,v29) L(tail8): TAIL(v26,v28) This results in callers reading content from those registers in a different context, potentially altering program logic. This has a security impact: there could be a scenario where a user controlled string could leak through strcmp into program code, thus altering its logic. There is also a potential for sensitive strings passed into strcmp leaking through the clobbered registers into parts of the calling program that should otherwise not have had access to those strings. The impact of this flaw is limited to applications running on Power 10 systems, using glibc 2.39 or later and using the nonvolatile vector registers, i.e. v20 to v31. It is possible to trivially work around the issue for those specific applications by setting the glibc.cpu.hwcaps tunable to "-arch_3_1" like so: export GLIBC_TUNABLES=glibc.cpu.hwcaps=-arch_3_1 Additional notes: While in the strcmp assembly, I also noticed this instruction: vspltisb v19,-1 which appears to be of no use since the value is not even read anywhere. It looks like a closer review of the entire function would be useful. The attached patch seems to work OK, but I haven't really run it through the wringer to verify that it is correct.
One option is to revert the feature and that would fix it right away while we work to add it back with proper testing around the procedure call standard registers like we do on other arches.
I don't consider my opinion as having particular weight on this, but that's my preference.
It seems that new memchr implementation from the same series clobbers vector registers as well: mtvsrd v18+32,r4 /* matching char in v18 */ mtvsrd v19+32,r6 /* non matching char in v19 */ vspltb v18,v18,7 /* replicate */ vspltb v19,v19,7 /* replicate */ vspltisb M_VREG_ZERO,0 But as far as I can see, this clobbers registers with the character being searched, so the risk of information leakage is greatly reduced.
And likewise we need to revert sysdeps/powerpc/powerpc64/le/power10/strncmp.S also ???
(In reply to Florian Weimer from comment #3) > It seems that new memchr implementation from the same series clobbers vector > registers as well: > > mtvsrd v18+32,r4 /* matching char in v18 */ > mtvsrd v19+32,r6 /* non matching char in v19 */ > > vspltb v18,v18,7 /* replicate */ > vspltb v19,v19,7 /* replicate */ > vspltisb M_VREG_ZERO,0 > > But as far as I can see, this clobbers registers with the character being > searched, so the risk of information leakage is greatly reduced. Those are volatile registers though, except maybe M_VREG_ZERO, i.e. v20. That one (I think) should have been saved/restored before being used as the 0 array. There's no information leakage here though, just a good old bug IMO.
I've filed separate bugs for strncmp and memchr since they need to be tracked separately.
Created attachment 16126 [details] Revert Patch Attached the revert patch just for reference.
Reviewed by Siddhesh Poyarekar. Still needs fixing on 2.41, 2.40, and 2.39. commit 15808c77b35319e67ee0dc8f984a9a1a434701bc Author: Carlos O'Donell <carlos@redhat.com> Date: Mon Jun 16 13:09:57 2025 -0400 ppc64le: Revert "powerpc: Optimized strcmp for power10" (CVE-2025-5702) This reverts commit 3367d8e180848030d1646f088759f02b8dfe0d6f Reason for revert: Power10 strcmp clobbers non-volatile vector registers (Bug 33056) Tested on ppc64le without regression.
Fixed on all relevant branches. Fix-Commit: 15808c77b35319e67ee0dc8f984a9a1a434701bc (2.42) Fix-Commit: 0c76c951620f9e12df2a89b2c684878b55bb6795 (2.41-60) Fix-Commit: 7e12550b8e3a11764a4a9090ce6bd3fc23fc8a8e (2.40-139) Fix-Commit: 06a70769fd0b2e1f2a3085ad50ab620282bd77b3 (2.39-209)