Bug 28784 - x86: crash in 32bit memset-sse2.s when the cache size can not be determined
Summary: x86: crash in 32bit memset-sse2.s when the cache size can not be determined
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.35
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-15 10:12 UTC by Aurelien Jarno
Modified: 2023-01-24 20:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aurelien Jarno 2022-01-15 10:12:42 UTC
In some cases (e.g QEMU, non-Intel/AMD CPU like VIA C7) the cache information can not be retrieved and the corresponding values are set to 0.

Commit 2d651eb9265d ("x86: Move x86 processor cache info to cpu_features") changed the behaviour in such case by defining the __x86_shared_cache_size and __x86_data_cache_size variables to 0 instead of using the default values. This cause an issue with the i686 SSE2 optimized bzero/routine which assumes that the cache size is at least 128 bytes, and otherwise tries to zero/set the whole address space minus 128 bytes.
Comment 1 Aurelien Jarno 2022-01-15 10:17:45 UTC
Patch available here: https://sourceware.org/pipermail/libc-alpha/2022-January/135358.html
Comment 2 Sourceware Commits 2022-01-17 18:43:11 UTC
The master branch has been updated by Aurelien Jarno <aurel32@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c242fcce06e3102ca663b2f992611d0bda4f2668

commit c242fcce06e3102ca663b2f992611d0bda4f2668
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Mon Jan 17 19:41:40 2022 +0100

    x86: use default cache size if it cannot be determined [BZ #28784]
    
    In some cases (e.g QEMU, non-Intel/AMD CPU) the cache information can
    not be retrieved and the corresponding values are set to 0.
    
    Commit 2d651eb9265d ("x86: Move x86 processor cache info to
    cpu_features") changed the behaviour in such case by defining the
    __x86_shared_cache_size and __x86_data_cache_size variables to 0 instead
    of using the default values. This cause an issue with the i686 SSE2
    optimized bzero/routine which assumes that the cache size is at least
    128 bytes, and otherwise tries to zero/set the whole address space minus
    128 bytes.
    
    Fix that by restoring the original code to only update
    __x86_shared_cache_size and __x86_data_cache_size variables if the
    corresponding cache sizes are not zero.
    
    Fixes bug 28784
    Fixes commit 2d651eb9265d
    
    Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Comment 3 Aurelien Jarno 2022-01-17 18:44:28 UTC
Fixed for glibc 2.35
Comment 4 Sourceware Commits 2022-01-17 18:47:35 UTC
The release/2.34/master branch has been updated by Aurelien Jarno <aurel32@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1d401d1fccb85046402089268b94d86d822070e6

commit 1d401d1fccb85046402089268b94d86d822070e6
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Mon Jan 17 19:41:40 2022 +0100

    x86: use default cache size if it cannot be determined [BZ #28784]
    
    In some cases (e.g QEMU, non-Intel/AMD CPU) the cache information can
    not be retrieved and the corresponding values are set to 0.
    
    Commit 2d651eb9265d ("x86: Move x86 processor cache info to
    cpu_features") changed the behaviour in such case by defining the
    __x86_shared_cache_size and __x86_data_cache_size variables to 0 instead
    of using the default values. This cause an issue with the i686 SSE2
    optimized bzero/routine which assumes that the cache size is at least
    128 bytes, and otherwise tries to zero/set the whole address space minus
    128 bytes.
    
    Fix that by restoring the original code to only update
    __x86_shared_cache_size and __x86_data_cache_size variables if the
    corresponding cache sizes are not zero.
    
    Fixes bug 28784
    Fixes commit 2d651eb9265d
    
    Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
    (cherry picked from commit c242fcce06e3102ca663b2f992611d0bda4f2668)
Comment 5 Sourceware Commits 2022-01-18 06:45:07 UTC
The release/2.33/master branch has been updated by Aurelien Jarno <aurel32@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a51b76b71e8190a50b0e0c0b32f313888b930108

commit a51b76b71e8190a50b0e0c0b32f313888b930108
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Mon Jan 17 19:41:40 2022 +0100

    x86: use default cache size if it cannot be determined [BZ #28784]
    
    In some cases (e.g QEMU, non-Intel/AMD CPU) the cache information can
    not be retrieved and the corresponding values are set to 0.
    
    Commit 2d651eb9265d ("x86: Move x86 processor cache info to
    cpu_features") changed the behaviour in such case by defining the
    __x86_shared_cache_size and __x86_data_cache_size variables to 0 instead
    of using the default values. This cause an issue with the i686 SSE2
    optimized bzero/routine which assumes that the cache size is at least
    128 bytes, and otherwise tries to zero/set the whole address space minus
    128 bytes.
    
    Fix that by restoring the original code to only update
    __x86_shared_cache_size and __x86_data_cache_size variables if the
    corresponding cache sizes are not zero.
    
    Fixes bug 28784
    Fixes commit 2d651eb9265d
    
    Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
    (cherry picked from commit c242fcce06e3102ca663b2f992611d0bda4f2668)
Comment 6 Dexuan Cui 2023-01-24 20:33:00 UTC
(In reply to Aurelien Jarno from comment #3)
> Fixed for glibc 2.35

Hi Aurelien and all, could you please take a look at this new bug I just reported:
https://sourceware.org/bugzilla/show_bug.cgi?id=30037