Changes in binfmt_elf.c

11854fe2 - binfmt_elf: Move brk for static PIE even if ASLR disabled

Fri, 25 Apr 2025 22:45:06 +0000

binfmt_elf: Move brk for static PIE even if ASLR disabledIn commit bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doingdirect loader exec"), the brk was moved out of the mmap region whenloading static PIE binaries (ET_DYN without INTERP). The common casefor these binaries was testing new ELF loaders, so the brk needed tobe away from mmap to avoid colliding with stack, future mmaps (of theloader-loaded binary), etc. But this was only done when ASLR was enabled,in an attempt to minimize changes to memory layouts.After adding support to respect alignment requirements for static PIEbinaries in commit 3545deff0ec7 ("binfmt_elf: Honor PT_LOAD alignmentfor static PIE"), it became possible to have a large gap after thefinal PT_LOAD segment and the top of the mmap region. This means thatfuture mmap allocations might go after the last PT_LOAD segment (wherebrk might be if ASLR was disabled) instead of before them (where theytraditionally ended up).On arm64, running with ASLR disabled, Ubuntu 22.04's "ldconfig" binary,a static PIE, has alignment requirements that leaves a gap large enoughafter the last PT_LOAD segment to fit the vdso and vvar, but still leaveenough space for the brk (which immediately follows the last PT_LOADsegment) to be allocated by the binary.fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.realfffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.realfffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0***[brk will go here at fffff7ffa000]***fffff7ffc000-fffff7ffe000 r--p 00000000 00:00 0 [vvar]fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso]fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack]After commit 0b3bc3354eb9 ("arm64: vdso: Switch to generic storageimplementation"), the arm64 vvar grew slightly, and suddenly the brkcollided with the allocation.fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.realfffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.realfffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0***[oops, no room any more, vvar is at fffff7ffa000!]***fffff7ffa000-fffff7ffe000 r--p 00000000 00:00 0 [vvar]fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso]fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack]The solution is to unconditionally move the brk out of the mmap regionfor static PIE binaries. Whether ASLR is enabled or not does not change ifthere may be future mmap allocation collisions with a growing brk region.Update memory layout comments (with kernel-doc headings), consolidatethe setting of mm->brk to later (it isn't needed early), move static PIEbrk out of mmap unconditionally, and make sure brk(2) knows to base brkposition off of mm->start_brk not mm->end_data no matter what the cause ofmoving it is (via current->brk_randomized).For the CONFIG_COMPAT_BRK case, though, leave the logic unchanged, as wecan never safely move the brk. These systems, however, are not usingspecially aligned static PIE binaries.Reported-by: Ryan Roberts Closes: https://lore.kernel.org/lkml/f93db308-4a0e-4806-9faf-98f890f5a5e6@arm.com/Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")Link: https://lore.kernel.org/r/20250425224502.work.520-kees@kernel.orgReviewed-by: Ryan Roberts Tested-by: Ryan Roberts Signed-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

2fc4947b - binfmt_elf: Use note name macros

Wed, 15 Jan 2025 05:47:59 +0000

binfmt_elf: Use note name macrosUse note name macros to match with the userspace's expectation.Signed-off-by: Akihiko Odaki Acked-by: Baoquan He Reviewed-by: Dave Martin Link: https://lore.kernel.org/r/20250115-elf-v5-2-0f9e55bbb2fc@daynix.comSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

0357ef03 - fs: don't block write during exec on pre-content watched files

Thu, 28 Nov 2024 14:25:32 +0000

fs: don't block write during exec on pre-content watched filesCommit 2a010c412853 ("fs: don't block i_writecount during exec") removedthe legacy behavior of getting ETXTBSY on attempt to open and executablefile for write while it is being executed.This commit was reverted because an application that depends on thislegacy behavior was broken by the change.We need to allow HSM writing into executable files while executed tofill their content on-the-fly.To that end, disable the ETXTBSY legacy behavior for files that arewatched by pre-content events.This change is not expected to cause regressions with existing systemswhich do not have any pre-content event listeners.Signed-off-by: Amir Goldstein Acked-by: Christian Brauner Signed-off-by: Jan Kara Link: https://patch.msgid.link/20241128142532.465176-1-amir73il@gmail.com List of files: /linux-6.15/fs/binfmt_elf.c

3b832035 - Revert "fs: don't block i_writecount during exec"

Wed, 27 Nov 2024 11:45:02 +0000

Revert "fs: don't block i_writecount during exec"This reverts commit 2a010c41285345da60cece35575b4e0af7e7bf44.Rui Ueyama writes:> I'm the creator and the maintainer of the mold linker> (https://github.com/rui314/mold). Recently, we discovered that mold> started causing process crashes in certain situations due to a change> in the Linux kernel. Here are the details:>> - In general, overwriting an existing file is much faster than> creating an empty file and writing to it on Linux, so mold attempts to> reuse an existing executable file if it exists.>> - If a program is running, opening the executable file for writing> previously failed with ETXTBSY. If that happens, mold falls back to> creating a new file.>> - However, the Linux kernel recently changed the behavior so that> writing to an executable file is now always permitted> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853).>> That caused mold to write to an executable file even if there's a> process running that file. Since changes to mmap'ed files are> immediately visible to other processes, any processes running that> file would almost certainly crash in a very mysterious way.> Identifying the cause of these random crashes took us a few days.>> Rejecting writes to an executable file that is currently running is a> well-known behavior, and Linux had operated that way for a very long> time. So, I don’t believe relying on this behavior was our mistake;> rather, I see this as a regression in the Linux kernel.Quoting myself from commit 2a010c412853 ("fs: don't block i_writecount during exec")> Yes, someone in userspace could potentially be relying on this. It's not> completely out of the realm of possibility but let's find out if that's> actually the case and not guess.It seems we found out that someone is relying on this obscure behavior.So revert the change.Link: https://github.com/rui314/mold/issues/1361Link: https://lore.kernel.org/r/4a2bc207-76be-4715-8e12-7fc45a76a125@leemhuis.infoCc: Signed-off-by: Christian Brauner List of files: /linux-6.15/fs/binfmt_elf.c

4e6e8c2b - binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4

Fri, 04 Oct 2024 20:26:29 +0000

binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4AT_HWCAP3 and AT_HWCAP4 were recently defined for use on PowerPC in commit3281366a8e79 ("uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector,entries"). Since we want to start using AT_HWCAP3 on arm64 add support forexposing both these new hwcaps via binfmt_elf.Signed-off-by: Mark Brown Acked-by: Kees Cook Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20241004-arm64-elf-hwcap3-v2-1-799d1daad8b0@kernel.orgSigned-off-by: Catalin Marinas List of files: /linux-6.15/fs/binfmt_elf.c

a78282e2 - Revert "binfmt_elf, coredump: Log the reason of the failed core dumps"

Thu, 26 Sep 2024 18:39:02 +0000

Revert "binfmt_elf, coredump: Log the reason of the failed core dumps"This reverts commit fb97d2eb542faf19a8725afbd75cbc2518903210.The logging was questionable to begin with, but it seems to activelydeadlock on the task lock. "On second thought, let's not log core dump failures. 'Tis a silly place"because if you can't tell your core dump is truncated, maybe you shouldjust fix your debugger instead of adding bugs to the kernel.Reported-by: Vegard Nossum Link: https://lore.kernel.org/all/d122ece6-3606-49de-ae4d-8da88846bef2@oracle.com/Signed-off-by: Linus Torvalds List of files: /linux-6.15/fs/binfmt_elf.c

44f65d90 - binfmt_elf: mseal address zero

Tue, 06 Aug 2024 21:49:27 +0000

binfmt_elf: mseal address zeroIn load_elf_binary as part of the execve(), when the currenttask’s personality has MMAP_PAGE_ZERO set, the kernel allocatesone page at address 0. According to the comment:/* Why this, you ask??? Well SVr4 maps page 0 as read-only, and some applications "depend" upon this behavior. Since we do not have the power to recompile these, we emulate the SVr4 behavior. Sigh. */At one point, Linus suggested removing this [1].Code search in debian didn't see much use of MMAP_PAGE_ZERO [2],it exists in util and test (rr).Sealing this is probably safe, the comment doesn't saythe app ever wanting to change the mapping to rwx. Sealingalso ensures that never happens.If there is a complaint, we can make this configurable.Link: https://lore.kernel.org/lkml/CAHk-=whVa=nm_GW=NVfPHqcxDbWt4JjjK1YWb0cLjO4ZSGyiDA@mail.gmail.com/ [1]Link: https://codesearch.debian.net/search?q=MMAP_PAGE_ZERO&literal=1&perpkg=1&page=1 [2]Signed-off-by: Jeff Xu Link: https://lore.kernel.org/r/20240806214931.2198172-2-jeffxu@google.comSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

fb97d2eb - binfmt_elf, coredump: Log the reason of the failed core dumps

Thu, 18 Jul 2024 18:27:25 +0000

binfmt_elf, coredump: Log the reason of the failed core dumpsMissing, failed, or corrupted core dumps might impede crashinvestigations. To improve reliability of that process and consequentlythe programs themselves, one needs to trace the path from producinga core dumpfile to analyzing it. That path starts from the core dump filewritten to the disk by the kernel or to the standard input of a usermode helper program to which the kernel streams the coredump contents.There are cases where the kernel will interrupt writing the core out orproduce a truncated/not-well-formed core dump without leaving a note.Add logging for the core dump collection failure paths to be able to reasonwhat has gone wrong when the core dump is malformed or missing.Report the size of the data written to aid in diagnosing the user modehelper.Signed-off-by: Roman Kisel Link: https://lore.kernel.org/r/20240718182743.1959160-3-romank@linux.microsoft.comSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

ba386777 - x86/elf: Add a new FPU buffer layout info to x86 core files

Thu, 25 Jul 2024 16:10:18 +0000

x86/elf: Add a new FPU buffer layout info to x86 core filesAdd a new .note section containing type, size, offset and flags of everyxfeature that is present.This information will be used by debuggers to understand the XSAVE layout ofthe machine where the core file has been dumped, and to read XSAVE registers,especially during cross-platform debugging.The XSAVE layouts of modern AMD and Intel CPUs differ, especially sinceMemory Protection Keys and the AVX-512 features have been inculcated intothe AMD CPUs.Since AMD never adopted (and hence never left room in the XSAVE layout for)the Intel MPX feature, tools like GDB had assumed a fixed XSAVE layoutmatching that of Intel (based on the XCR0 mask).Hence, core dumps from AMD CPUs didn't match the known size for the XCR0 mask.This resulted in GDB and other tools not being able to access the values ofthe AVX-512 and PKRU registers on AMD CPUs.To solve this, an interim solution has been accepted into GDB, and is alreadya part of GDB 14, see https://sourceware.org/pipermail/gdb-patches/2023-March/198081.html.But it depends on heuristics based on the total XSAVE register set sizeand the XCR0 mask to infer the layouts of the various register blocksfor core dumps, and hence, is not a foolproof mechanism to determine thelayout of the XSAVE area.Therefore, add a new core dump note in order to allow GDB/LLDB and otherrelevant tools to determine the layout of the XSAVE area of the machine wherethe corefile was dumped.The new core dump note (which is being proposed as a per-process .notesection), NT_X86_XSAVE_LAYOUT (0x205) contains an array of structures.Each structure describes an individual extended feature containingoffset, size and flags in this format: struct x86_xfeat_component { u32 type; u32 size; u32 offset; u32 flags; };and in an independent manner, allowing for future extensions without dependingon hw arch specifics like CPUID etc. [ bp: Massage commit message, zap trailing whitespace. ]Co-developed-by: Jini Susan George Signed-off-by: Jini Susan George Co-developed-by: Borislav Petkov (AMD) Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Vignesh Balasubramanian Link: https://lore.kernel.org/r/20240725161017.112111-2-vigbalas@amd.com List of files: /linux-6.15/fs/binfmt_elf.c

b6f5ee4d - execve: Move KUnit tests to tests/ subdirectory

Sat, 20 Jul 2024 17:03:14 +0000

execve: Move KUnit tests to tests/ subdirectoryMove the exec KUnit tests into a separate directory to avoid pollutingthe local directory namespace. Additionally update MAINTAINERS for thenew files.Reviewed-by: David Gow Reviewed-by: SeongJae Park Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20240720170310.it.942-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

2a97388a - ELF: fix kernel.randomize_va_space double read

Fri, 21 Jun 2024 18:54:50 +0000

ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.Signed-off-by: Alexey Dobriyan Link: https://lore.kernel.org/r/3329905c-7eb8-400a-8f0a-d87cff979b5b@p183Signed-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

3545deff - binfmt_elf: Honor PT_LOAD alignment for static PIE

Wed, 08 May 2024 17:31:48 +0000

binfmt_elf: Honor PT_LOAD alignment for static PIEThe p_align values in PT_LOAD were ignored for static PIE executables(i.e. ET_DYN without PT_INTERP). This is because there is no way torequest a non-fixed mmap region with a specific alignment. ET_DYN withPT_INTERP uses a separate base address (ELF_ET_DYN_BASE) and binfmt_elfperforms the ASLR itself, which means it can also apply alignment. Forthe mmap region, the address selection happens deep within the vm_mmap()implementation (when the requested address is 0).The earlier attempt to implement this: commit 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE") commit 925346c129da ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders")did not take into account the different base address origins, and wereeventually reverted: aeb7923733d1 ("revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE"")In order to get the correct alignment from an mmap base, binfmt_elf mustperform a 0-address load first, then tear down the mapping and performalignment on the resulting address. Since this is slightly more overhead,only do this when it is needed (i.e. the alignment is not the defaultELF alignment). This does, however, have the benefit of being able touse MAP_FIXED_NOREPLACE, to avoid potential collisions.With this fixed, enable the static PIE self tests again.Reported-by: H.J. Lu Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215275Link: https://lore.kernel.org/r/20240508173149.677910-3-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

2d4cf7b1 - binfmt_elf: Calculate total_size earlier

Wed, 08 May 2024 17:31:47 +0000

binfmt_elf: Calculate total_size earlierIn preparation to support PT_LOAD with large p_align values onnon-PT_INTERP ET_DYN executables (i.e. "static pie"), we'll need to usethe total_size details earlier. Move this separately now to make thenext patch more readable. As total_size and load_bias are currentlycalculated separately, this has no behavioral impact.Link: https://lore.kernel.org/r/20240508173149.677910-2-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

2a010c41 - fs: don't block i_writecount during exec

Fri, 31 May 2024 13:01:43 +0000

fs: don't block i_writecount during execBack in 2021 we already discussed removing deny_write_access() forexecutables. Back then I was hesistant because I thought that this mightcause issues in userspace. But even back then I had started taking somenotes on what could potentially depend on this and I didn't come up witha lot so I've changed my mind and I would like to try this.Here are some of the notes that I took:(1) The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.(2) There are userspace attacks that rely on overwriting the binary of a running process. These attacks are _mitigated_ but _not at all prevented_ from ocurring by the deny_write_access() mechanism. I'll go over some details. The clearest example of such attacks was the attack against runC in CVE-2019-5736 (cf. [3]). An attack could compromise the runC host binary from inside a _privileged_ runC container. The malicious binary could then be used to take over the host. (It is crucial to note that this attack is _not_ possible with unprivileged containers. IOW, the setup here is already insecure.) The attack can be made when attaching to a running container or when starting a container running a specially crafted image. For example, when runC attaches to a container the attacker can trick it into executing itself. This could be done by replacing the target binary inside the container with a custom binary pointing back at the runC binary itself. As an example, if the target binary was /bin/bash, this could be replaced with an executable script specifying the interpreter path #!/proc/self/exe. As such when /bin/bash is executed inside the container, instead the target of /proc/self/exe will be executed. That magic link will point to the runc binary on the host. The attacker can then proceed to write to the target of /proc/self/exe to try and overwrite the runC binary on the host. However, this will not succeed because of deny_write_access(). Now, one might think that this would prevent the attack but it doesn't. To overcome this, the attacker has multiple ways: * Open a file descriptor to /proc/self/exe using the O_PATH flag and then proceed to reopen the binary as O_WRONLY through /proc/self/fd/ and try to write to it in a busy loop from a separate process. Ultimately it will succeed when the runC binary exits. After this the runC binary is compromised and can be used to attack other containers or the host itself. * Use a malicious shared library annotating a function in there with the constructor attribute making the malicious function run as an initializor. The malicious library will then open /proc/self/exe for creating a new entry under /proc/self/fd/. It'll then call exec to a) force runC to exit and b) hand the file descriptor off to a program that then reopens /proc/self/fd/ for writing (which is now possible because runC has exited) and overwriting that binary. To sum up: the deny_write_access() mechanism doesn't prevent such attacks in insecure setups. It just makes them minimally harder. That's all. The only way back then to prevent this is to create a temporary copy of the calling binary itself when it starts or attaches to containers. So what I did back then for LXC (and Aleksa for runC) was to create an anonymous, in-memory file using the memfd_create() system call and to copy itself into the temporary in-memory file, which is then sealed to prevent further modifications. This sealed, in-memory file copy is then executed instead of the original on-disk binary. Any compromising write operations from a privileged container to the host binary will then write to the temporary in-memory binary and not to the host binary on-disk, preserving the integrity of the host binary. Also as the temporary, in-memory binary is sealed, writes to this will also fail. The point is that deny_write_access() is uselss to prevent these attacks.(3) Denying write access to an inode because it's currently used in an exec path could easily be done on an LSM level. It might need an additional hook but that should be about it.(4) The MAP_DENYWRITE flag for mmap() has been deprecated a long time ago so while we do protect the main executable the bigger portion of the things you'd think need protecting such as the shared libraries aren't. IOW, we let anyone happily overwrite shared libraries.(5) We removed all remaining uses of VM_DENYWRITE in [2]. That means: (5.1) We removed the legacy uselib() protection for preventing overwriting of shared libraries. Nobody cared in 3 years. (5.2) We allow write access to the elf interpreter after exec completed treating it on a par with shared libraries.Yes, someone in userspace could potentially be relying on this. It's notcompletely out of the realm of possibility but let's find out if that'sactually the case and not guess.Link: https://github.com/golang/go/issues/22315 [1]Link: 49624efa65ac ("Merge tag 'denywrite-for-5.15' of git://github.com/davidhildenbrand/linux") [2]Link: https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736 [3]Link: https://lwn.net/Articles/866493Link: https://github.com/golang/go/issues/22220Link: https://github.com/golang/go/blob/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/cmd/go/internal/work/buildid.go#L724Link: https://github.com/golang/go/blob/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/cmd/go/internal/work/exec.go#L1493Link: https://github.com/golang/go/blob/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/cmd/go/internal/script/cmds.go#L457Link: https://github.com/golang/go/blob/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/cmd/go/internal/test/test.go#L1557Link: https://github.com/golang/go/blob/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/os/exec/lp_linux_test.go#L61Link: https://github.com/buildkite/agent/pull/2736Link: https://github.com/rust-lang/rust/issues/114554Link: https://bugs.openjdk.org/browse/JDK-8068370Link: https://github.com/dotnet/runtime/issues/58964Link: https://lore.kernel.org/r/20240531-vfs-i_writecount-v1-1-a17bea7ee36b@kernel.orgReviewed-by: Josef Bacik Signed-off-by: Christian Brauner List of files: /linux-6.15/fs/binfmt_elf.c

4bbf9c3b - fs/coredump: Enable dynamic configuration of max file note size

Mon, 06 May 2024 19:37:00 +0000

fs/coredump: Enable dynamic configuration of max file note sizeIntroduce the capability to dynamically configure the maximum filenote size for ELF core dumps via sysctl.Why is this being done?We have observed that during a crash when there are more than 65k mmapsin memory, the existing fixed limit on the size of the ELF notes sectionbecomes a bottleneck. The notes section quickly reaches its capacity,leading to incomplete memory segment information in the resulting coredump.This truncation compromises the utility of the coredumps, as crucialinformation about the memory state at the time of the crash might beomitted.This enhancement removes the previous static limit of 4MB, allowingsystem administrators to adjust the size based on system-specificrequirements or constraints.Eg:$ sysctl -a | grep core_file_note_size_limitkernel.core_file_note_size_limit = 4194304$ sysctl -n kernel.core_file_note_size_limit4194304$echo 519304 > /proc/sys/kernel/core_file_note_size_limit$sysctl -n kernel.core_file_note_size_limit519304Attempting to write beyond the ceiling value of 16MB$echo 17194304 > /proc/sys/kernel/core_file_note_size_limitbash: echo: write error: Invalid argumentSigned-off-by: Vijay Nag Signed-off-by: Allen Pais Link: https://lore.kernel.org/r/20240506193700.7884-1-apais@linux.microsoft.comSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

6b839b3b - regset: use kvzalloc() for regset_get_alloc()

Mon, 05 Feb 2024 17:26:30 +0000

regset: use kvzalloc() for regset_get_alloc()While browsing through ChromeOS crash reports, I found one with anallocation failure that looked like this: chrome: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=urgent,mems_allowed=0 CPU: 7 PID: 3295 Comm: chrome Not tainted 5.15.133-20574-g8044615ac35c #1 (HASH:1162 1) Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT) Call trace: ... warn_alloc+0x104/0x174 __alloc_pages+0x5f0/0x6e4 kmalloc_order+0x44/0x98 kmalloc_order_trace+0x34/0x124 __kmalloc+0x228/0x36c __regset_get+0x68/0xcc regset_get_alloc+0x1c/0x28 elf_core_dump+0x3d8/0xd8c do_coredump+0xeb8/0x1378 get_signal+0x14c/0x804 ...An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's nota surprise that this allocation failed on a system that's been runningfor a while.More digging showed that it was fairly easy to see the order 7allocation by just sending a SIGQUIT to chrome (or other processes) togenerate a core dump. The actual amount being allocated was 279,584bytes and it was for "core_note_type" NT_ARM_SVE.There was quite a bit of discussion [1] on the mailing lists inresponse to my v1 patch attempting to switch to vmalloc. The overallconclusion was that we could likely reduce the 279,584 byte allocationby quite a bit and Mark Brown has sent a patch to that effect [2].However even with the 279,584 byte allocation gone there are still65,552 byte allocations. These are just barely more than the 65,536bytes and thus would require an order 5 allocation.An order 5 allocation is still something to avoid unless necessary andnothing needs the memory here to be contiguous. Change the allocationto kvzalloc() which should still be efficient for small allocationsbut doesn't force the memory subsystem to work hard (and maybe fail)at getting a large contiguous chunk.[1] https://lore.kernel.org/r/20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid[2] https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.orgLink: https://lkml.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeidSigned-off-by: Douglas Anderson Reviewed-by: Catalin Marinas Cc: Al Viro Cc: Christian Brauner Cc: Dave Martin Cc: Eric Biederman Cc: Jan Kara Cc: Kees Cook Cc: Mark Brown Cc: Matthew Wilcox (Oracle) Cc: Oleg Nesterov Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/fs/binfmt_elf.c

2a5eb999 - binfmt_elf: Leave a gap between .bss and brk

Sat, 17 Feb 2024 06:25:44 +0000

binfmt_elf: Leave a gap between .bss and brkCurrently the brk starts its randomization immediately after .bss,which means there is a chance that when the random offset is 0, linearoverflows from .bss can reach into the brk area. Leave at least a singlepage gap between .bss and brk (when it has not already been explicitlyrelocated into the mmap range).Reported-by: Closes: https://lore.kernel.org/linux-hardening/CA+2EKTVLvc8hDZc+2Yhwmus=dzOUG5E4gV7ayCbu0MPJTZzWkw@mail.gmail.com/Link: https://lore.kernel.org/r/20240217062545.1631668-2-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

f9c0a39d - binfmt_elf: Only report padzero() errors when PROT_WRITE

Fri, 29 Sep 2023 03:24:33 +0000

binfmt_elf: Only report padzero() errors when PROT_WRITEErrors with padzero() should be caught unless we're expecting apathological (non-writable) segment. Report -EFAULT only when PROT_WRITEis present.Additionally add some more documentation to padzero(), elf_map(), andelf_load().Cc: Eric Biederman Cc: Alexander Viro Cc: Christian Brauner Cc: linux-fsdevel@vger.kernel.orgCc: linux-mm@kvack.orgSuggested-by: Eric Biederman Tested-by: Pedro Falcato Signed-off-by: Sebastian Ott Link: https://lore.kernel.org/r/20230929032435.2391507-5-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

d5ca24f6 - binfmt_elf: Use elf_load() for library

Fri, 29 Sep 2023 03:24:32 +0000

binfmt_elf: Use elf_load() for libraryWhile load_elf_library() is a libc5-ism, we can still replace most ofits contents with elf_load() as well, further simplifying the code.Some historical context:- libc4 was a.out and used uselib (a.out support has been removed)- libc5 was ELF and used uselib (there may still be users)- libc6 is ELF and has never used uselibCc: Alexander Viro Cc: Christian Brauner Cc: linux-fsdevel@vger.kernel.orgCc: linux-mm@kvack.orgSuggested-by: Eric Biederman Tested-by: Pedro Falcato Signed-off-by: Sebastian Ott Link: https://lore.kernel.org/r/20230929032435.2391507-4-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c

8b04d326 - binfmt_elf: Use elf_load() for interpreter

Fri, 29 Sep 2023 03:24:31 +0000

binfmt_elf: Use elf_load() for interpreterHandle arbitrary memsz>filesz in interpreter ELF segments, instead ofonly supporting it in the last segment (which is expected to be theBSS).Cc: Eric Biederman Cc: Alexander Viro Cc: Christian Brauner Cc: linux-fsdevel@vger.kernel.orgCc: linux-mm@kvack.orgReported-by: Pedro Falcato Closes: https://lore.kernel.org/lkml/20221106021657.1145519-1-pedro.falcato@gmail.com/Tested-by: Pedro Falcato Signed-off-by: Sebastian Ott Link: https://lore.kernel.org/r/20230929032435.2391507-3-keescook@chromium.orgSigned-off-by: Kees Cook List of files: /linux-6.15/fs/binfmt_elf.c