Why aren’t Microsoft patches to the Linux kernel checked more rigorously?
https://www.theregister.com/2025/01/14/microsoft_linux_change_pulled/
‘Let’s not do this again please’… days before release date
By Richard Speed
Intel and AMD engineers have stepped in at the eleventh to deal with a code contribution from a Microsoft developer that could have broken Linux 6.13 on some systems.
The change, made in the autumn, was a useful improvement at face value. It was a modification to Linux x86_64 to use large read-only execute (ROX) pages for caching executable pages. The theory was that the alteration would result in increased performance.
However, the code caused problems on some setups and an urgent patch from Intel’s Peter Zijlstra was committed yesterday to disable it. The stable release of the 6.13 kernel was due this coming weekend.
Zijlstra wrote: “The whole module_writable_address() nonsense made a giant mess of alternative.c, not to mention it still contains bugs — notable (sic) some of the CFI variants crash and burn.
Control Flow Integrity (CFI) is an anti-malware technology aimed at preventing attackers from redirecting the control flow of a program. The change can cause issues on some CFI-enabled setups and reports have included Intel Alder Lake-powered machines failing to resume from hibernation.
Zijlstra said the Microsoft engineer “has been working on patches to clean all this up again, but given the current state of things, this stuff just isn’t ready. Disable for now, let’s try again next cycle.”
The offending source is still present, but won’t be included in the upcoming stable kernel build.
AMD engineer Borislav Petkov noted that the Linux x86_64 maintainers had not signed off on the change, commenting: “I just love it how this went in without a single x86 maintainer Ack, it broke a bunch of things and then it is still there instead of getting reverted. Let’s not do this again please.”
Microsoft is notable for dubious quality control standards regarding releases of its flagship operating system, Windows. That one of its engineers should drop some dodgy code into the Linux kernel is not hugely surprising, and the unfortunate individual is not the first and will not be the last to do so, regardless of their employer.
However, the processes that allowed it to remain in the build this close to public release will be a concern. While it is amusing that engineers from both Intel and AMD were involved in dealing with the issues arising from the contribution of a Microsoft engineer, and the problem never reached the stable release, it is concerning. Petkov will not be the only one wondering how the change made it in without a review by the Linux x86/x86_64 maintainers.