linux-cve-announce - CVE-2023-53642: x86: fix clear_user_rep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025100716-CVE-2023-53642-a8f8@gregkh>
Date: Tue,  7 Oct 2025 17:19:47 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2023-53642: x86: fix clear_user_rep_good() exception handling annotation

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

x86: fix clear_user_rep_good() exception handling annotation

This code no longer exists in mainline, because it was removed in
commit d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory
clearing") upstream.

However, rather than backport the full range of x86 memory clearing and
copying cleanups, fix the exception table annotation placement for the
final 'rep movsb' in clear_user_rep_good(): rather than pointing at the
actual instruction that did the user space access, it pointed to the
register move just before it.

That made sense from a code flow standpoint, but not from an actual
usage standpoint: it means that if user access takes an exception, the
exception handler won't actually find the instruction in the exception
tables.

As a result, rather than fixing it up and returning -EFAULT, it would
then turn it into a kernel oops report instead, something like:

    BUG: unable to handle page fault for address: 0000000020081000
    #PF: supervisor write access in kernel mode
    #PF: error_code(0x0002) - not-present page
    ...
    RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147
    ...
    Call Trace:
      __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]
      clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]
      iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800
      iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]
      iomap_dio_iter fs/iomap/direct-io.c:440 [inline]
      __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601
      iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689
      ext4_dio_read_iter fs/ext4/file.c:94 [inline]
      ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145
      call_read_iter include/linux/fs.h:2183 [inline]
      do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733
      do_iter_read+0x2f2/0x750 fs/read_write.c:796
      vfs_readv+0xe5/0x150 fs/read_write.c:916
      do_preadv+0x1b6/0x270 fs/read_write.c:1008
      __do_sys_preadv2 fs/read_write.c:1070 [inline]
      __se_sys_preadv2 fs/read_write.c:1061 [inline]
      __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd

which then looks like a filesystem bug rather than the incorrect
exception annotation that it is.

[ The alternative to this one-liner fix is to take the upstream series
  that cleans this all up:

    68674f94ffc9 ("x86: don't use REP_GOOD or ERMS for small memory copies")
    20f3337d350c ("x86: don't use REP_GOOD or ERMS for small memory clearing")
    adfcf4231b8c ("x86: don't use REP_GOOD or ERMS for user memory copies")
  * d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory clearing")
    3639a535587d ("x86: move stac/clac from user copy routines into callers")
    577e6a7fd50d ("x86: inline the 'rep movs' in user copies for the FSRM case")
    8c9b6a88b7e2 ("x86: improve on the non-rep 'clear_user' function")
    427fda2c8a49 ("x86: improve on the non-rep 'copy_user' function")
  * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")
    e1f2750edc4a ("x86: remove 'zerorest' argument from __copy_user_nocache()")
    034ff37d3407 ("x86: rewrite '__copy_user_nocache' function")

  with either the whole series or at a minimum the two marked commits
  being needed to fix this issue ]

The Linux kernel CVE team has assigned CVE-2023-53642 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.1 with commit 0db7058e8e23e6bbab1b4747ecabd1784c34f50b and fixed in 6.1.29 with commit 76ce32682635fe907e0f8e64e039e773e5c7508f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-53642
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/x86/lib/clear_page_64.S


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/76ce32682635fe907e0f8e64e039e773e5c7508f