22 Aug, 2020

1 commit

  • romfs has a superblock field that limits the size of the filesystem; data
    beyond that limit is never accessed.

    romfs_dev_read() fetches a caller-supplied number of bytes from the
    backing device. It returns 0 on success or an error code on failure;
    therefore, its API can't represent short reads, it's all-or-nothing.

    However, when romfs_dev_read() detects that the requested operation would
    cross the filesystem size limit, it currently silently truncates the
    requested number of bytes. This e.g. means that when the content of a
    file with size 0x1000 starts one byte before the filesystem size limit,
    ->readpage() will only fill a single byte of the supplied page while
    leaving the rest uninitialized, leaking that uninitialized memory to
    userspace.

    Fix it by returning an error code instead of truncating the read when the
    requested read operation would go beyond the end of the filesystem.

    Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly")
    Signed-off-by: Jann Horn
    Signed-off-by: Andrew Morton
    Reviewed-by: Greg Kroah-Hartman
    Cc: David Howells
    Cc:
    Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com
    Signed-off-by: Linus Torvalds

    Jann Horn
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

27 Mar, 2012

1 commit


12 Oct, 2009

1 commit

  • An interestingly corrupted romfs file system exposed a problem with the
    romfs_dev_strnlen function: it's passing the wrong value to its helpers.
    Rather than limit the string to the length passed in by the callers, it
    uses the size of the device as the limit.

    Signed-off-by: Bernd Schmidt
    Signed-off-by: Mike Frysinger
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Bernd Schmidt
     

25 Apr, 2009

2 commits


24 Mar, 2009

1 commit

  • Change RomFS so that it can use MTD devices directly - without the intercession
    of the block layer - as well as using block devices.

    This permits RomFS:

    (1) to use the MTD direct mapping facility available under NOMMU conditions if
    the underlying device is directly accessible by the CPU (including XIP);

    (2) and thus to be used when the block layer is disabled.

    RomFS can be configured with support just for MTD devices, just for Block
    devices or for both. If RomFS is configured for both, then it will treat
    mtdblock device files as MTD backing stores, not block layer backing stores.

    I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV
    board with a RomFS image installed on the mtdram test device. I see my test
    program being run XIP:

    # cat /proc/maps
    ...
    c0c000b0-c0c01f8c r-xs 00000000 1f:00 144 /mnt/doshm
    ...

    GDB on the kernel can be used to show that these addresses are within the
    set-aside RAM space.

    Signed-off-by: David Howells
    Tested-by: Bernd Schmidt
    Signed-off-by: David Woodhouse

    David Howells