* [PATCH] binfmt_elf_fdpic: reject PT_LOAD segments with p_filesz > p_memsz
@ 2026-07-10 12:14 Daniel Palmer
0 siblings, 0 replies; only message in thread
From: Daniel Palmer @ 2026-07-10 12:14 UTC (permalink / raw)
To: kees, linux-mm; +Cc: linux-kernel, Daniel Palmer
Both fdpic loaders assume every PT_LOAD segment satisfies
p_filesz <= p_memsz, but this is never validated after the program
headers are read.
A malformed ELF with p_filesz > p_memsz misbehaves in both paths:
- elf_fdpic_map_file_constdisp_on_uclinux() sizes its single
anonymous mapping from p_memsz, then read_code()s p_filesz bytes
into each segment, overrunning the reserved space.
- elf_fdpic_map_file_by_direct_mmap() computes
excess = p_memsz - p_filesz as an unsigned value, which underflows
and drives an oversized anonymous mapping / clear_user().
Validate the invariant once in elf_fdpic_fetch_phdrs(), which is the
common path for both the executable and the interpreter, so every
loader is covered. Do it in a dedicated loop rather than the existing
stack-size loop, which breaks early on PT_GNU_STACK and could skip
later PT_LOAD segments.
Link: https://github.com/fifteenhex/fdpicloaderbug_20260710 # reproducer
Assisted-by: Claude:claude-fable-5 # Discovery of bug, review/rework of patch, reproducer
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
Backstory:
When I got access to fable again I thought I'd let it
recheck all of the nommu related files to see if there were any
horrible bugs.
This is 1 of about 3 bugs that seem legit.
fable did most of the hard work here so I'm not going to claim
to have found this bug. I wrote an initial patch and fable told
me to put the check in a different place to cover another issue
and rewrote the commit message. It knows best. :)
I have checked in my m68k nommu environment that this bug is
valid and allows a bad ELF to corrupt memory using a reproducer
fable helped create. Link is in the commit message. I also checked
this fixes blocks a bad ELF from loading.
fs/binfmt_elf_fdpic.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 7e3108489c83..69aa0e04543b 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -157,6 +157,22 @@ static int elf_fdpic_fetch_phdrs(struct elf_fdpic_params *params,
if (unlikely(retval != size))
return retval < 0 ? retval : -ENOEXEC;
+ /* reject any PT_LOAD segment that claims to hold more data in the file
+ * than it reserves in memory; the loaders below assume
+ * p_filesz <= p_memsz and overrun/underflow their size arithmetic
+ * otherwise
+ */
+ phdr = params->phdrs;
+ for (loop = 0; loop < params->hdr.e_phnum; loop++, phdr++) {
+ if (phdr->p_type != PT_LOAD)
+ continue;
+
+ if (phdr->p_filesz > phdr->p_memsz) {
+ kdebug("Bad segment %d: p_filesz > p_memsz", loop);
+ return -ENOEXEC;
+ }
+ }
+
/* determine stack size for this binary */
phdr = params->phdrs;
for (loop = 0; loop < params->hdr.e_phnum; loop++, phdr++) {
--
2.53.0
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2026-07-10 12:15 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-10 12:14 [PATCH] binfmt_elf_fdpic: reject PT_LOAD segments with p_filesz > p_memsz Daniel Palmer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox