CVE-2023-53749

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]