Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 10月, 2016 8 次提交
  3. 07 10月, 2016 6 次提交
  5. 01 10月, 2016 2 次提交
  7. 22 9月, 2016 2 次提交
  9. 21 9月, 2016 2 次提交
  11. 20 9月, 2016 10 次提交
  13. 16 9月, 2016 4 次提交
    • P
      configfs: Return -EFBIG from configfs_write_bin_file. · 42857cf5
      由 Phil Turnbull 提交于 
      The check for writing more than cb_max_size bytes does not 'goto out' so
it is a no-op which allows users to vmalloc an arbitrary amount.

Fixes: 03607ace ("configfs: implement binary attributes")
Cc: stable@kernel.org
Signed-off-by: NPhil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      42857cf5
    • J
      aio: mark AIO pseudo-fs noexec · 22f6b4d3
      由 Jann Horn 提交于 
      This ensures that do_mmap() won't implicitly make AIO memory mappings
executable if the READ_IMPLIES_EXEC personality flag is set.  Such
behavior is problematic because the security_mmap_file LSM hook doesn't
catch this case, potentially permitting an attacker to bypass a W^X
policy enforced by SELinux.

I have tested the patch on my machine.

To test the behavior, compile and run this:

    #define _GNU_SOURCE
    #include <unistd.h>
    #include <sys/personality.h>
    #include <linux/aio_abi.h>
    #include <err.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <sys/syscall.h>

    int main(void) {
        personality(READ_IMPLIES_EXEC);
        aio_context_t ctx = 0;
        if (syscall(__NR_io_setup, 1, &ctx))
            err(1, "io_setup");

        char cmd[1000];
        sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'",
            (int)getpid());
        system(cmd);
        return 0;
    }

In the output, "rw-s" is good, "rwxs" is bad.
Signed-off-by: NJann Horn <jann@thejh.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      22f6b4d3
    • D
      vfs: cap dedupe request structure size at PAGE_SIZE · b71dbf10
      由 Darrick J. Wong 提交于 
      Kirill A Shutemov reports that the kernel doesn't try to cap dest_count
in any way, and uses the number to allocate kernel memory.  This causes
high order allocation warnings in the kernel log if someone passes in a
big enough value.  We should clamp the allocation at PAGE_SIZE to avoid
stressing the VM.

The two existing users of the dedupe ioctl never send more than 120
requests, so we can safely clamp dest_range at PAGE_SIZE, because with
4k pages we can handle up to 127 dedupe candidates.  Given the max
extent length of 16MB, we can end up doing 2GB of IO which is plenty.

[ Note: the "offsetof()" can't overflow, because 'count' is just a
  16-bit integer.  That's not obvious in the limited context of the
  patch, so I'm noting it here because it made me go look.  - Linus ]
Reported-by: N"Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b71dbf10
    • D
      vfs: fix return type of ioctl_file_dedupe_range · 5297e0f0
      由 Darrick J. Wong 提交于 
      All the VFS functions in the dedupe ioctl path return int status, so
the ioctl handler ought to as well.

Found by Coverity, CID 1350952.
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5297e0f0
  15. 12 9月, 2016 1 次提交
  17. 10 9月, 2016 5 次提交