From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCCE5421F07 for ; Fri, 10 Jul 2026 12:15:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783685710; cv=none; b=MoOikieOn08ylte1x4AL/w6/2w5mJkri3c3mxvEunZmSt+sFqPSU0k7r8R1hahLybrs4t0uPs/Qnej4AQ+KuSbRfOYvUyargYNa/VNeXiTpQwvWWGUtIJndKCY5q87iu4gvWQZFMmYqxT3giqw6T0GUXXL+xOr8V2vceGjVGwQc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783685710; c=relaxed/simple; bh=ZGvIV9GzcCplS82W6tqWnTbeLYL5QGOSWoggSSczRJI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=qrrv+VjLKGD8CvIWTWnaG7HMyvkjhA1MP2gww5AB3jJKtIEc8eGDXXmYL85YkzH9p0KwU7pblcvUAXhOjAivyQ/BCraN+6PnIKV+kCzcFe7sndmt7Qyy2Ij+0PpwX1sO0zMV0LMZXLu4ybgksX+BzT5rF5iNJiD5VArx/wDYkKI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=thingy.jp; spf=pass smtp.mailfrom=0x0f.com; dkim=pass (1024-bit key) header.d=thingy.jp header.i=@thingy.jp header.b=n3kuT2mz; arc=none smtp.client-ip=209.85.210.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=thingy.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=0x0f.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=thingy.jp header.i=@thingy.jp header.b="n3kuT2mz" Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-845b6d9bf39so849095b3a.1 for ; Fri, 10 Jul 2026 05:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thingy.jp; s=google; t=1783685707; x=1784290507; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=NSF9C7wUF75t6WkNCETBYi+2NyVN+aPspNLqRNlAJLM=; b=n3kuT2mz0Rc1F/XJNj32pfFKji+0bChvFMe6lhdjlOF/b1I+2G0x6Y16aUL4YDlTg3 zx1UvvIQBStulGqpdmodlqRNBKb+SRhrSjyStqGU/p0w20lYterJpgHf7gc35x6Zc88T Sdmi5raHQ67h//eoyxtcORCgc9syculZb5wM4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783685707; x=1784290507; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NSF9C7wUF75t6WkNCETBYi+2NyVN+aPspNLqRNlAJLM=; b=igNAuhBBZfS/HDDVh9/iI7E0Bytfu6U6VVm0b03saWKxjBDVKbDhUYyr1Iap455m1h cP0142HgmkiVnMjvdT3FAtwAIh8DOSBdJHLLQrPucJbYtYvXBdTyGuOUzHh6vZxzjC3y aMzP96w2Bhavc6ZC76W/yVg5gnMVBE+0WVETkMHX4x6BldbX11R8MeZ/LNZVD5R+uUnF I7gyyqGBPikroQjwWgEXeYGE7/kebD8F1MW5h70vOgGlOSJKI15z6KgwmtdPGf+FFokm mln4fy5HlgMZLO38BuHC9nZkyGM+NJflWc2AnAVC3NS+dULjM19UBqeLlWQ18vsSvcnl DwJA== X-Gm-Message-State: AOJu0YwAcPbQo27KXEm2wrEu7ZWpdBxBzZ3+cbL/RH/acxjVh8+lx+fH iRlqUK9s28tR5mUBHgSnhlQA1REMnl9e3X7JHX6elTXtq8Srl1ZO+7ORQd2VIi4Oc24= X-Gm-Gg: AfdE7cnQd5/DipNKsQzrvL8GPtlkxH5zg/o7stvAn8lVLA9Pi/yq4fE5XRor4qv7hys JLPMwt0UC4WkMbG0kzZihUi79ANMEYRpo5lcss05PvA1g6p6zZgGKhKrfTEvEYgZevuDe12q64h gj96x/avYup+ZAm7YtoF/yp+CJum3dUrRKrsmh3Phqkc2e5t0V0Q6P8dhj1JvWO8FB5dNVwv4cL A0JYSlXynD6YI23w+5nFL7PVtQUumNnwcpB4xfBpysDmI7VHeCxC/+LPUT/mOoCgVUK1NCVVuzt g9QI/+T2CdUQffeC5gGVXtLJL4fExj/wzAC5UXHVWI6tEbZBuEbjHqDn3Np+h/JGECP10gpmj+G EyJ/TPiUhOxcuzbW6lQ+c4i4ksaplVdrcYeqTJ2LrIALOdDh346nAyMYuX6d54qOxGIWYebZs2+ LtpMI7a47L5soUdrs0PeMQrz5y0w== X-Received: by 2002:a05:6a00:218f:b0:848:2ef5:50d9 with SMTP id d2e1a72fcca58-84870ba48d2mr2707433b3a.33.1783685706911; Fri, 10 Jul 2026 05:15:06 -0700 (PDT) Received: from kinako.work.home.arpa ([2400:4162:2428:2ffe:a973:53e4:1a28:8545]) by smtp.googlemail.com with ESMTPSA id d2e1a72fcca58-848593a591asm2600405b3a.26.2026.07.10.05.15.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 05:15:05 -0700 (PDT) From: Daniel Palmer To: kees@kernel.org, linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Daniel Palmer Subject: [PATCH] binfmt_elf_fdpic: reject PT_LOAD segments with p_filesz > p_memsz Date: Fri, 10 Jul 2026 21:14:43 +0900 Message-ID: <20260710121443.1059549-1-daniel@thingy.jp> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- 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