CVE-2026-43073

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86-64: rename misleadingly named &amp;#39;__copy_user_nocache()&amp;#39; function<br /> <br /> This function was a masterclass in bad naming, for various historical<br /> reasons.<br /> <br /> It claimed to be a non-cached user copy. It is literally _neither_ of<br /> those things. It&amp;#39;s a specialty memory copy routine that uses<br /> non-temporal stores for the destination (but not the source), and that<br /> does exception handling for both source and destination accesses.<br /> <br /> Also note that while it works for unaligned targets, any unaligned parts<br /> (whether at beginning or end) will not use non-temporal stores, since<br /> only words and quadwords can be non-temporal on x86.<br /> <br /> The exception handling means that it _can_ be used for user space<br /> accesses, but not on its own - it needs all the normal "start user space<br /> access" logic around it.<br /> <br /> But typically the user space access would be the source, not the<br /> non-temporal destination. That was the original intention of this,<br /> where the destination was some fragile persistent memory target that<br /> needed non-temporal stores in order to catch machine check exceptions<br /> synchronously and deal with them gracefully.<br /> <br /> Thus that non-descriptive name: one use case was to copy from user space<br /> into a non-cached kernel buffer. However, the existing users are a mix<br /> of that intended use-case, and a couple of random drivers that just did<br /> this as a performance tweak.<br /> <br /> Some of those random drivers then actively misused the user copying<br /> version (with STAC/CLAC and all) to do kernel copies without ever even<br /> caring about the exception handling, _just_ for the non-temporal<br /> destination.<br /> <br /> Rename it as a first small step to actually make it halfway sane, and<br /> change the prototype to be more normal: it doesn&amp;#39;t take a user pointer<br /> unless the caller has done the proper conversion, and the argument size<br /> is the full size_t (it still won&amp;#39;t actually copy more than 4GB in one<br /> go, but there&amp;#39;s also no reason to silently truncate the size argument in<br /> the caller).<br /> <br /> Finally, use this now sanely named function in the NTB code, which<br /> mis-used a user copy version (with STAC/CLAC and all) of this interface<br /> despite it not actually being a user copy at all.