linux-kernel - Increasing the vm.max_map

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <a2b2c557-c46e-6236-24a1-d605758e87f2@gmail.com>
Date:   Tue, 23 May 2023 16:15:54 +0200
From:   Alessandro Astone <ales.astone@...il.com>
To:     akpm@...ux-foundation.org
Cc:     kamezawa.hiroyu@...fujitsu.com, hughd@...gle.com, jakub@...hat.com,
        ales.astone@...il.com, linux-kernel@...r.kernel.org
Subject: Increasing the vm.max_map_count value

We are seeing userspace requiring more than the default 65330 mappings,
specifically some Windows games running through wine. We are looking into
changing the default in Fedora, but the source code includes a scary comment
about the current value:

 > Default maximum number of active map areas, this limits the number of 
vmas
 > per mm struct. Users can overwrite this number by sysctl but there is a
 > problem.
 >
 > When a program's coredump is generated as ELF format, a section is 
created
 > per a vma. In ELF, the number of sections is represented in unsigned 
short.
 > This means the number of sections should be smaller than 65535 at 
coredump.
 > Because the kernel adds some informative sections to a image of 
program at
 > generating coredump, we need some margin. The number of extra sections is
 > 1-3 now and depends on arch. We use "5" as safe margin, here.

It seems that going over 16 bits would at least break ELF coredumps (for
programs actually requesting as many mappings).

Do you think it is otherwise safe to increase this value arbitrarily?