|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: kernel: ASLR broken on Tumbleweed 32bit / reduced on 64bit | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Alexander Bergmann <abergmann> |
| Component: | Incidents | Assignee: | Michal Hocko <mhocko> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | bwiedemann, jack, jsegitz, jslaby, martin.doucha, mhocko, smash_bz, tiwai, vbabka |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Detailed notes: https://zolutal.github.io/aslrnt/ Leap 15.6 is also affected. We may change CONFIG_ARCH_MMAP_RND_BITS and CONFIG_ARCH_MMAP_RND_COMPAT_BITS as well for TW and SLE15-SP6. But as I'm not sure about the impact, adding more people to Cc. Question for new LTP test: How much randomization do you expect from a fix? Should ASLR granularity be 1 pagesize again, or is anything larger than normal pagesize but strictly smaller than the smallest hugepage size good enough? Hmm, interesting. CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_HAVE_ARCH_MMAP_RND_BITS=y CONFIG_ARCH_MMAP_RND_BITS=28 CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 seems to be pretty consistent with what we have in 15sp5 which seems to be working just fine. Will look deeper See the details in comment 1 It points to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=1854bc6e2420472676c5c90d3d6b15f6cd640e40 as what triggered the issue. Together with very old https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=dbe6ec815641aa22b50775aaeb47fa3a8d04ccf1 (In reply to Bernhard Wiedemann from comment #6) > See the details in comment 1 > > It points to > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > commit?id=1854bc6e2420472676c5c90d3d6b15f6cd640e40 > as what triggered the issue. > Together with very old > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > commit?id=dbe6ec815641aa22b50775aaeb47fa3a8d04ccf1 Thanks for the hint. I haven't looked at the link in comment 1 previously. Somehow managed to miss it. Now I get what Takashi meant by changing the RND configuration (sorry for being dense here). Increasing the 32b randomization base is certainly an option but I am worried this could lead to regressions on larger 32b applications which might fail to load because of insufficient address space. Especially those with larger user stacks. I think we should bring this up upstream and ask whether the PMD alignment is really appropriate for 32b address space which is really tiny comparing to 64b. Let me talk to Matthew. https://lore.kernel.org/all/20240118133504.2910955-1-shy828301@gmail.com/T/#u I will wait couple of days before it gets to Linus tree and will backport the patch to affected branches. (In reply to Michal Hocko from comment #8) > https://lore.kernel.org/all/20240118133504.2910955-1-shy828301@gmail.com/T/#u > > I will wait couple of days before it gets to Linus tree and will backport > the patch to affected branches. We do not have this in any of our branches except for stable and that already has the fix. So closing now. Thanks to Jiri Slaby for pursuing this in parallel. *** Bug 1220944 has been marked as a duplicate of this bug. *** |
We have a problem in Tumbleweed with ASLR and 32-bit binaries. How to test: 1. Compile a 32-bit binary dummy. gcc<VERSION>-32bit needs to be installed. $ echo 'main(){}' | gcc -m32 -o test32 -x c /dev/stdin 2. Run the ldd command on that binary and check the address randomization. $ for i in $(seq 10) ; do ldd ./test32 | grep libc ; done Observed result: libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) libc.so.6 => /lib/libc.so.6 (0xf7c00000) Expected result: libc.so.6 => /lib/libc.so.6 (0xf7d81000) libc.so.6 => /lib/libc.so.6 (0xf7cda000) libc.so.6 => /lib/libc.so.6 (0xf7ce4000) libc.so.6 => /lib/libc.so.6 (0xf7d56000) libc.so.6 => /lib/libc.so.6 (0xf7da3000) libc.so.6 => /lib/libc.so.6 (0xf7d6f000) libc.so.6 => /lib/libc.so.6 (0xf7cdf000) libc.so.6 => /lib/libc.so.6 (0xf7d1b000) libc.so.6 => /lib/libc.so.6 (0xf7d90000) libc.so.6 => /lib/libc.so.6 (0xf7d71000)