[PATCH] binfmt_flat: Fix corruption when not offsetting data start

[Kees Cook]

On Wed, Aug 07, 2024 at 07:05:11AM -0700, Palmer Dabbelt wrote:
> On Wed, 24 Apr 2024 13:44:31 PDT (-0700), alex at ghiti.fr wrote:
> > Hi Stefan,
> > 
> > On 26/03/2024 04:20, Stefan O'Rear wrote:
> > > Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
> > > introduced a RISC-V specific variant of the FLAT format which does not
> > > allocate any space for the (obsolescent) array of shared library
> > > pointers. However, it did not disable the code which initializes the
> > > array, resulting in the corruption of sizeof(long) bytes before the DATA
> > > segment, generally the end of the TEXT segment.
> > > 
> > > Use CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard initialization the
> > > shared library pointer region so that it will only be initialized if
> > > space is reserved for it.
> > > 
> > > Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
> > > Signed-off-by: Stefan O'Rear <sorear at fastmail.com>
> > > Tested-by: Waldemar Brodkorb <wbx at openadk.org>
> > > ---
> > >   fs/binfmt_flat.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> > > index c26545d71d39..70c2b68988f4 100644
> > > --- a/fs/binfmt_flat.c
> > > +++ b/fs/binfmt_flat.c
> > > @@ -879,6 +879,7 @@ static int load_flat_binary(struct linux_binprm *bprm)
> > >   	if (res < 0)
> > >   		return res;
> > > 
> > > +#ifndef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET
> > >   	/* Update data segment pointers for all libraries */
> > >   	for (i = 0; i < MAX_SHARED_LIBS; i++) {
> > >   		if (!libinfo.lib_list[i].loaded)
> > > @@ -893,6 +894,7 @@ static int load_flat_binary(struct linux_binprm *bprm)
> > >   				return -EFAULT;
> > >   		}
> > >   	}
> > > +#endif
> > > 
> > >   	set_binfmt(&flat_format);
> > > 
> > 
> > I have this fix on my list for quite some time, will you respin a new
> > version for 6.9?
> 
> IIRC we asked on IRC and Sorear wasn't going to respin the patch, so unless
> someone else wants to pick it up I think it's just going to get lost.

I took a look at this and sent a v2 just now.

-- 
Kees Cook