Re: [PATCH] binfmt_elf_fdpic: reject PT_LOAD with filesz larger than memsz

["Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>]

Hello Jori,

On 2026-08-21 13:45, Jori Koolstra wrote:
> On Thu, Aug 20, 2026 at 10:28:26PM +0000, Jérémy Jean wrote:
>> The ELF specification requires p_filesz to be no larger than p_memsz 
>> for
>> PT_LOAD segments.
>> 
>> elf_fdpic_map_file_constdisp_on_uclinux() sizes its contiguous 
>> allocation
>> from p_memsz, then read_code() copies p_filesz bytes into it. A 
>> malformed
>> segment can therefore copy file contents past the allocation on NOMMU
>> systems. The direct-mmap path also subtracts p_filesz from p_memsz 
>> without
>> first validating the relationship.
>> 
>> Validate every PT_LOAD immediately after fetching the program headers.
>> This covers both executable and interpreter headers before
>> begin_new_exec() makes execution irreversible.
>> 
>> On RV32 NOMMU, an ET_DYN with an 8192-byte p_filesz and 4096-byte 
>> p_memsz
>> copied a marker from the second file page past its one-page mapping.
>> After this change execve() rejects it with -EINVAL, while an 8192/8192
>> control still executes.
>> 
>> The flaw dates back to the driver's introduction in the pre-git 
>> history
>> tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC 
>> ELF
>> binary format driver").
> 
> I came across this about a month ago. But I wonder if this is even 
> worth
> fixing. You are on a non-MMU system, so running a malicious ELF kinda
> means gameover anyhow, doesn't it?

Well, this would act as defense in depth, no? I agree that cases where 
this
matters are probably rare, if any, but I don't see why this should not 
be fixed
anyway. Isn't it best not to assume anything about the use cases? The 
patch is
only a suggestion to start discussions: I'm merely raising this to your
attention but you guys (maintainers) are obviously in the best place to 
check
whether there are better options.

Regards,
Jérémy