Re: [Qemu-stable] [PATCH 1/5] multiboot: Reject kernels exceeding the address space

[Kevin Wolf]

Am 15.03.2018 um 17:55 hat Jack Schwartz geschrieben:
> On 03/15/18 08:54, Kevin Wolf wrote:
> > Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
> > > Hi Kevin.
> > > 
> > > My comments are inline...
> > > 
> > > On 2018-03-14 10:32, Kevin Wolf wrote:
> > > > The code path with a manually set mh_load_addr in the Multiboot header
> > > > checks that load_end_addr <= load_addr, but the path where load_end_addr
> > > > is automatically detected if 0 is given in the header misses the
> > > > corresponding check.
> > > 1) The code checks that load_end_addr >= load_addr (before letting it
> > > through).
> > > 
> > > 2) load_end_addr is used only when it is read in as non-zero, so no check 
> > > is
> > > needed if zero.  (It gets debug-printed even when zero, but is used only 
> > > to
> > > calculate mb_load_size and only when non-zero.)
> > Oops, good point. I'll change the start of the commit message as follows:
> > 
> >      The code path with a manually set mh_load_end_addr in the Multiboot
> >      header checks that mh_load_end_addr >= mh_load_addr, but the path where
> >      mh_load_end_addr is 0 in the header and therefore automatically
> >      calculated from the file size misses the corresponding check.
> > 
> > Does this look better?
> 
> mb_load_size is calculated from the file size, not mh_load_end_addr, so
> I think you mean mb_load_size rather than mh_load_end_addr.  Do you intend
> to say:
> 
>   The code path where mh_load_end_addr is non-zero in the Multiboot
>   header checks that mh_load_end_addr >= mh_load_addr and so
>   mb_load_size ischecked.  However, mb_load_size is not checked when
>   calculated from thefile size, when mh_load_end_addr is 0.

Ok, technically that's more accurate.

> Also, if this is what you intend to say, would the following code change be
> more ofwhat you want:
> 
> Remove this:
> 
>             mb_load_size = kernel_file_size - mb_kernel_text_offset;
>         }
> -       if (mb_load_size > UINT32_MAX - mh_load_addr) {
> -           error_report("kernel does not fit in address space");
> -           exit(1);
> -       }
>         if (mh_bss_end_addr) {
> 
> and instead do this a few lines further down:
> 
>            mb_kernel_size = mh_bss_end_addr - mh_load_addr;
>         } else {
>             mb_kernel_size = mb_load_size;
>         }
> 
> +       if (mb_kernel_size > UINT32_MAX - mh_load_addr) {
> +           error_report("kernel does not fit in address space");
> +           exit(1);
> +       }
> 
>         mb_debug("multiboot: header_addr = %#x", mh_header_addr);
>         mb_debug("multiboot: load_addr = %#x", mh_load_addr);
> 
> The reason would be to include the bss area in the calculation, when
> mh_bss_end_addr is non-zero.

Ultimately, mb_load_size > mb_kernel_size is what kills us, so maybe we
could add an assertion for that.

But the reason why this condition could ever be true is the integer
overflow in this line:

    if (mh_bss_end_addr < (mh_load_addr + mb_load_size))

It's generally better to check for integer overflows before they happen
than trying to infer them from the result. In fact, your condition
wouldn't catch the error of test scenario 9:

    kernel_file_size        = 0x2035
    mh_header_addr          = 0xfffff000
    mh_load_addr            = 0xfffff000
    mh_load_end_addr        = 0
    mh_bss_end_addr         = 0xfffff001

    mb_kernel_text_offset   = i - (mh_header_addr - mh_load_addr)
                            = 0

    mb_load_size            = kernel_file_size - mb_kernel_text_offset
                            = 0x2035
                            > UINT32_MAX - mh_load_addr

    mb_kernel_size          = mh_bss_end_addr - mh_load_addr
                            = 1
                            < UINT32_MAX - mh_load_addr

Kevin