2 min Security

Intel and AMD rescue Linux 6.13 after Microsoft developer mistakes

Intel and AMD rescue Linux 6.13 after Microsoft developer mistakes

Engineers from Intel and AMD have stepped in at the last minute to address a code bug from a Microsoft developer that could have broken Linux 6.13 on some systems.

The change, made in the fall, appeared to be a helpful improvement at first glance. It involved modifying Linux x86_64 to use large read-only executable (ROX) pages to cache executable pages. The theory was that this modification would provide better performance.

However, the code caused problems on some configurations, reports The Register. Intel engineer Peter Zijlstra applied a patch to disable the change. The stable release of the 6.13 kernel was scheduled for the coming weekend.

Zijlstra reports that the whole module_writable_address() made a huge mess of alternative.c. In addition, the module still contains bugs. In particular, some of the CFI variants crash and fail entirely, according to Zijlstra.

Anti-malware technology

Control Flow Integrity (CFI) is an anti-malware technology that prevents attackers from redirecting a program’s control flow. The change may cause problems on some CFI-enabled systems. And there have been reports of Intel Alder Lake systems that could no longer wake up from hibernation.

Zijlstra stated that the Microsoft engineer has been working on patches to clean this all up, but given the current situation, this code is not ready yet. He recommends not using the module and waiting for the next update cycle. The source code remains but will not be included in the upcoming stable kernel build.

Microsoft is known for questionable quality control in releases of its main operating system, Windows. Therefore, it is not surprising that one of their engineers would put dubious code into the Linux kernel. The developer in question is certainly not the first and will not be the last to do so, regardless of his or her employer.

Troubling situation

Still, it is worrisome that the processes allowed this to happen so close to public release. While it is ironic that both Intel and AMD engineers were involved in fixing the problems caused by a Microsoft engineer’s contribution, and the problem never reached a stable release, it is also troubling.