1. 31 Jul, 2018 1 commit
  2. 30 Jul, 2018 5 commits
  3. 29 Jul, 2018 5 commits
    • Linus Torvalds's avatar
      Linux 4.18-rc7 · acb18725
      Linus Torvalds authored
      acb18725
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 3cfb6772
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Some miscellaneous ext4 fixes for 4.18; one fix is for a regression
        introduced in 4.18-rc4.
      
        Sorry for the late-breaking pull. I was originally going to wait for
        the next merge window, but Eric Whitney found a regression introduced
        in 4.18-rc4, so I decided to push out the regression plus the other
        fixes now. (The other commits have been baking in linux-next since
        early July)"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix check to prevent initializing reserved inodes
        ext4: check for allocation block validity with block group locked
        ext4: fix inline data updates with checksums enabled
        ext4: clear mmp sequence number when remounting read-only
        ext4: fix false negatives *and* false positives in ext4_check_descriptors()
      3cfb6772
    • Linus Torvalds's avatar
      squashfs: be more careful about metadata corruption · 01cfb793
      Linus Torvalds authored
      Anatoly Trosinenko reports that a corrupted squashfs image can cause a
      kernel oops.  It turns out that squashfs can end up being confused about
      negative fragment lengths.
      
      The regular squashfs_read_data() does check for negative lengths, but
      squashfs_read_metadata() did not, and the fragment size code just
      blindly trusted the on-disk value.  Fix both the fragment parsing and
      the metadata reading code.
      Reported-by: default avatarAnatoly Trosinenko <anatoly.trosinenko@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      01cfb793
    • Theodore Ts'o's avatar
      ext4: fix check to prevent initializing reserved inodes · 50122847
      Theodore Ts'o authored
      Commit 8844618d: "ext4: only look at the bg_flags field if it is
      valid" will complain if block group zero does not have the
      EXT4_BG_INODE_ZEROED flag set.  Unfortunately, this is not correct,
      since a freshly created file system has this flag cleared.  It gets
      almost immediately after the file system is mounted read-write --- but
      the following somewhat unlikely sequence will end up triggering a
      false positive report of a corrupted file system:
      
         mkfs.ext4 /dev/vdc
         mount -o ro /dev/vdc /vdc
         mount -o remount,rw /dev/vdc
      
      Instead, when initializing the inode table for block group zero, test
      to make sure that itable_unused count is not too large, since that is
      the case that will result in some or all of the reserved inodes
      getting cleared.
      
      This fixes the failures reported by Eric Whiteney when running
      generic/230 and generic/231 in the the nojournal test case.
      
      Fixes: 8844618d ("ext4: only look at the bg_flags field if it is valid")
      Reported-by: default avatarEric Whitney <enwlinux@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      50122847
    • Linus Torvalds's avatar
      Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random · a26fb01c
      Linus Torvalds authored
      Pull random fixes from Ted Ts'o:
       "In reaction to the fixes to address CVE-2018-1108, some Linux
        distributions that have certain systemd versions in some cases
        combined with patches to libcrypt for FIPS/FEDRAMP compliance, have
        led to boot-time stalls for some hardware.
      
        The reaction by some distros and Linux sysadmins has been to install
        packages that try to do complicated things with the CPU and hope that
        leads to randomness.
      
        To mitigate this, if RDRAND is available, mix it into entropy provided
        by userspace. It won't hurt, and it will probably help"
      
      * tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
        random: mix rdrand with entropy sent in from userspace
      a26fb01c
  4. 28 Jul, 2018 3 commits
  5. 27 Jul, 2018 23 commits
  6. 26 Jul, 2018 3 commits