Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 11, 2024 at 1:10 PM Yves-Alexis Perez <corsac@xxxxxxxxxx> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, 2024-01-18 at 05:35 -0800, Yang Shi wrote:
> > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> > boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> > userspace.
> >
> > It doesn't make too much sense to force huge page alignment on 32 bit
> > system due to the constrained virtual address space.
>
> Hi people,
>
> sorry for beeing so late. I've looked at this following the OpenSSH issue
> (CVE-2024-6387 [1]) and especially the impact on IA-32 installations where
> ASLR is apparently broken.
>
> There was a recent thread [2] on oss-security discussing the issue.
>
> Looking at the commit log I think the intention was to fix this both for:
> - - 32 bit process running on 64 bit kernels: in_compat_syscall()
> - - all processes running on 32 bit kernels: IS_ENABLED(CONFIG_32BIT)

Yes. It is supposed to cover all 32 bit machines.

>
> Unfortunately, as far as I can tell, CONFIG_32BIT is not enabled on 32bit x86
> kernels. Maybe CONFIG_X86_32 would be the right one there?

I have not been working on 32 bit machine for years. I'm a little bit
surprised CONFIG_32BIT is not enough for x86_32. Sorry for overlooking
this.

The below patch should fix your problem.

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2120f7478e55..2944b3fc88a5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -857,7 +857,8 @@ static unsigned long
__thp_get_unmapped_area(struct file *filp,
        loff_t off_align = round_up(off, size);
        unsigned long len_pad, ret, off_sub;

-       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
+       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
+           in_compat_syscall())
                return 0;

        if (off_end <= off_align || (off_end - off_align) < size)

>
> [1] https://www.openwall.com/lists/oss-security/2024/07/01/3
> [2] https://www.openwall.com/lists/oss-security/2024/07/08/3
> - --
> Yves-Alexis
> -----BEGIN PGP SIGNATURE-----
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaQPCQACgkQ3rYcyPpX
> RFvSHQf/VE7td7scTTsrK7Cx0F3MmDLFgjUDbMDuyPq6lNQqnDbd2zc00JP1eeLs
> /mW1uZNbR92bn6xq2sPJu7c6tB3MJuiQme+ZqnPfIgyoWc89i6V6WUXTZN077lIl
> xJZxHLMei5KreHz66AYU66HdU89knMTcX362YyyI8dEZKXS3FlP0SLSoBM0UKY0G
> HYM6+GetE+fINhfNSMpHgqkTQB825Vqdq5UBsBjHYMg5RJ92/fDgUo5RD7qm/HVz
> SDDNSGwpVwYZ20RnnD+DOS9rsnyR4FcAP0m0dcTmQdM8GcY4SyjnEux5idvCicjy
> a1jmvsSLxCMZ9mZsrsipIZoNhSHlDA==
> =f0Lk
> -----END PGP SIGNATURE-----





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux