This project is mirrored from Pull mirroring updated .
  1. 07 Jul, 2017 7 commits
  2. 06 Jul, 2017 33 commits
    • Krishnankutty Kolathappilly's avatar
      msm: camera: fix bound check of offset to avoid overread overwrite · 1c9891ef
      Krishnankutty Kolathappilly authored
      fix bound check of hw_cmd_p->offset in msm_jpeg_hw_exec_cmds
      to avoid overread overwrite.
      CRs-Fixed: 1088824
      Change-Id: Ifaa4b5387d4285ddce16d8e745aa0500c64c568b
      Signed-off-by: default avatarKrishnankutty Kolathappilly <>
    • Jens Axboe's avatar
      BACKPORT: block: add blk_rq_set_block_pc() · d7979cd2
      Jens Axboe authored
      With the optimizations around not clearing the full request at alloc
      time, we are leaving some of the needed init for REQ_TYPE_BLOCK_PC
      up to the user allocating the request.
      Add a blk_rq_set_block_pc() that sets the command type to
      REQ_TYPE_BLOCK_PC, and properly initializes the members associated
      with this type of request. Update callers to use this function instead
      of manipulating rq->cmd_type directly.
      Includes fixes from Christoph Hellwig <> for my half-assed
      Change-Id: Ifc386dfb951c5d6adebf48ff38135dda28e4b1ce
      Signed-off-by: default avatarJens Axboe <>
    • Marcelo Ricardo Leitner's avatar
      sctp: deny peeloff operation on asocs with threads sleeping on it · 1e058b27
      Marcelo Ricardo Leitner authored
      commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      attempted to avoid a BUG_ON call when the association being used for a
      sendmsg() is blocked waiting for more sndbuf and another thread did a
      peeloff operation on such asoc, moving it to another socket.
      As Ben Hutchings noticed, then in such case it would return without
      locking back the socket and would cause two unlocks in a row.
      Further analysis also revealed that it could allow a double free if the
      application managed to peeloff the asoc that is created during the
      sendmsg call, because then sctp_sendmsg() would try to free the asoc
      that was created only for that call.
      This patch takes another approach. It will deny the peeloff operation
      if there is a thread sleeping on the asoc, so this situation doesn't
      exist anymore. This avoids the issues described above and also honors
      the syscalls that are already being handled (it can be multiple sendmsg
      Joint work with Xin Long.
      Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      Change-Id: Id4a7c9eeba08de25200bf73b7931c35683b6b450
      Cc: Alexander Popov <>
      Cc: Ben Hutchings <>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <>
      Signed-off-by: default avatarXin Long <>
      Signed-off-by: default avatarDavid S. Miller <>
    • David S. Miller's avatar
      irda: Fix lockdep annotations in hashbin_delete(). · c540e4a5
      David S. Miller authored
      A nested lock depth was added to the hasbin_delete() code but it
      doesn't actually work some well and results in tons of lockdep splats.
      Fix the code instead to properly drop the lock around the operation
      and just keep peeking the head of the hashbin queue.
      Change-Id: If21e82c2c9fc38beac61483390c247b2b24a8c7a
      Reported-by: default avatarDmitry Vyukov <>
      Tested-by: default avatarDmitry Vyukov <>
      Signed-off-by: default avatarDavid S. Miller <>
    • Eric Dumazet's avatar
      net/llc: avoid BUG_ON() in skb_orphan() · 65c03053
      Eric Dumazet authored
      It seems nobody used LLC since linux-3.12.
      Fortunately fuzzers like syzkaller still know how to run this code,
      otherwise it would be no fun.
      Setting skb->sk without skb->destructor leads to all kinds of
      bugs, we now prefer to be very strict about it.
      Ideally here we would use skb_set_owner() but this helper does not exist yet,
      only CAN seems to have a private helper for that.
      Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()")
      Signed-off-by: default avatarEric Dumazet <>
      Reported-by: default avatarAndrey Konovalov <>
      Signed-off-by: default avatarDavid S. Miller <>
      (cherry picked from commit 8b74d439e1697110c5e5c600643e823eb1dd0762)
      Change-Id: I17412f0afe525d556ab072a7b89d5839845a2ce7
    • Eric Dumazet's avatar
      BACKPORT: tcp: avoid infinite loop in tcp_splice_read() · 1616f1d5
      Eric Dumazet authored
      Splicing from TCP socket is vulnerable when a packet with URG flag is
      received and stored into receive queue.
      __tcp_splice_read() returns 0, and sk_wait_data() immediately
      returns since there is the problematic skb in queue.
      This is a nice way to burn cpu (aka infinite loop) and trigger
      soft lockups.
      Again, this gem was found by syzkaller tool.
      Fixes: 9c55e01c
       ("[TCP]: Splice receive support.")
      Signed-off-by: default avatarEric Dumazet <>
      Reported-by: default avatarDmitry Vyukov  <>
      Cc: Willy Tarreau <>
      Signed-off-by: default avatarDavid S. Miller <>
      Change-Id: Ic8000917deb6ce7ca4ce2af0c8ce951355051ec9
    • Andrey Konovalov's avatar
      dccp: fix freeing skb too early for IPV6_RECVPKTINFO · 27b5e6c3
      Andrey Konovalov authored
      In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
      is forcibly freed via __kfree_skb in dccp_rcv_state_process if
      dccp_v6_conn_request successfully returns.
      However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
      is saved to ireq->pktopts and the ref count for skb is incremented in
      dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
      in dccp_rcv_state_process.
      Fix by calling consume_skb instead of doing goto discard and therefore
      calling __kfree_skb.
      Similar fixes for TCP:
       [TCP]: skb is unexpectedly freed.
      0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
      simply consumed
      Change-Id: I8fb66546ff3870ad05030ea4e963b5cb3e015bbe
      Signed-off-by: default avatarAndrey Konovalov <>
      Acked-by: default avatarEric Dumazet <>
      Signed-off-by: default avatarDavid S. Miller <>
    • Marcelo Ricardo Leitner's avatar
      sctp: avoid BUG_ON on sctp_wait_for_sndbuf · 6a8b1c31
      Marcelo Ricardo Leitner authored
      Alexander Popov reported that an application may trigger a BUG_ON in
      sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
      waiting on it to queue more data and meanwhile another thread peels off
      the association being used by the first thread.
      This patch replaces the BUG_ON call with a proper error handling. It
      will return -EPIPE to the original sendmsg call, similarly to what would
      have been done if the association wasn't found in the first place.
      Change-Id: I3584164c04c97bb8795f4e327f2a31e0c2b40bf9
      Acked-by: default avatarAlexander Popov <>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <>
      Reviewed-by: default avatarXin Long <>
      Signed-off-by: default avatarDavid S. Miller <>
    • Davidlohr Bueso's avatar
      ipc/shm: Fix shmat mmap nil-page protection · 9d425269
      Davidlohr Bueso authored
      The issue is described here, with a nice testcase:

      The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and the
      address rounded down to 0.  For the regular mmap case, the protection
      mentioned above is that the kernel gets to generate the address --
      arch_get_unmapped_area() will always check for MAP_FIXED and return that
      address.  So by the time we do security_mmap_addr(0) things get funky for
      The testcase itself shows that while a regular user crashes, root will not
      have a problem attaching a nil-page.  There are two possible fixes to
      this.  The first, and which this patch does, is to simply allow root to
      crash as well -- this is also regular mmap behavior, ie when hacking up
      the testcase and adding mmap(...  |MAP_FIXED).  While this approach is the
      safer option, the second alternative is to ignore SHM_RND if the rounded
      address is 0, thus only having MAP_SHARED flags.  This makes the behavior
      of shmat() identical to the mmap() case.  The downside of this is
      obviously user visible, but does make sense in that it maintains semantics
      after the round-down wrt 0 address and mmap.
      Passes shm related ltp tests.
      Change-Id: I840c924440a34cd049c50639eb5bd1e69f6ac9cc
      Signed-off-by: default avatarDavidlohr Bueso <>
      Reported-by: default avatarGareth Evans <>
      Cc: Manfred Spraul <>
      Cc: Michael Kerrisk <>
      Signed-off-by: default avatarAndrew Morton <>
    • Min Chong's avatar
      usb: gadget: f_mbim: Change %p to %pK in debug messages · c352a6f6
      Min Chong authored
      The format specifier %p can leak kernel addresses
      while not valuing the kptr_restrict system settings.
      Use %pK instead of %p, which also evaluates whether
      kptr_restrict is set.
      Bug: 31802656
      Change-Id: I74e83192e0379586469edba3c7579a1cd75cf3c0
      Signed-off-by: default avatarMin Chong <>
    • Steve Pfetsch's avatar
      drivers: video: Add bounds checking in fb_cmap_to_user · 934c8514
      Steve Pfetsch authored
      Verify that unsigned int value will not become negative before cast to
      signed int.
      Bug: 31651010
      Change-Id: I548a200f678762042617f11100b6966a405a3920
    • Kees Cook's avatar
      net: ping: check minimum size on ICMP header length · 81829477
      Kees Cook authored
      [ Upstream commit 0eab121ef8750a5c8637d51534d5e9143fb0633f ]
      Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there
      was no check that the iovec contained enough bytes for an ICMP header,
      and the read loop would walk across neighboring stack contents. Since the
      iov_iter conversion, bad arguments are noticed, but the returned error is
      EFAULT. Returning EINVAL is a clearer error and also solves the problem
      prior to v3.19.
      This was found using trinity with KASAN on v3.18:
      BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
      Read of size 8 by task trinity-c2/9623
      page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x0()
      page dumped because: kasan: bad access detected
      CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
      Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
      Call trace:
      [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
      [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
      [<     inline     >] __dump_stack lib/dump_stack.c:15
      [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
      [<     inline     >] print_address_description mm/kasan/report.c:147
      [<     inline     >] kasan_report_error mm/kasan/report.c:236
      [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
      [<     inline     >] check_memory_region mm/kasan/kasan.c:264
      [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
      [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
      [<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
      [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
      [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
      [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
      [<     inline     >] __sock_sendmsg_nosec net/socket.c:624
      [<     inline     >] __sock_sendmsg net/socket.c:632
      [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
      [<     inline     >] SYSC_sendto net/socket.c:1797
      [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761
      Change-Id: I795b2ad57e1d2f73af0ade550756424be51859c3
      Reported-by: default avatarQidan He <>
      Fixes: c319b4d7
       ("net: ipv4: add IPPROTO_ICMP socket kind")
      Signed-off-by: default avatarKees Cook <>
      Signed-off-by: default avatarDavid S. Miller <>
      Signed-off-by: default avatarJiri Slaby <>
    • Takashi Iwai's avatar
      ALSA: hrtimer: Fix stall by hrtimer_cancel() · ea34c1f0
      Takashi Iwai authored
      hrtimer_cancel() waits for the completion from the callback, thus it
      must not be called inside the callback itself.  This was already a
      problem in the past with ALSA hrtimer driver, and the early commit
      : ALSA: hrtimer - Fix lock-up] tried to address it.
      However, the previous fix is still insufficient: it may still cause a
      lockup when the ALSA timer instance reprograms itself in its callback.
      Then it invokes the start function even in snd_timer_interrupt() that
      is called in hrtimer callback itself, results in a CPU stall.  This is
      no hypothetical problem but actually triggered by syzkaller fuzzer.
      This patch tries to fix the issue again.  Now we call
      hrtimer_try_to_cancel() at both start and stop functions so that it
      won't fall into a deadlock, yet giving some chance to cancel the queue
      if the functions have been called outside the callback.  The proper
      hrtimer_cancel() is called in anyway at closing, so this should be
      Change-Id: I9b0de90c925ec2dbe0e2394658b9dd3254ac346f
      Reported-and-tested-by: default avatarDmitry Vyukov <>
      Cc: <>
      Signed-off-by: default avatarTakashi Iwai <>
    • Andrey Konovalov's avatar
      ALSA: usb-audio: avoid freeing umidi object twice · bf865465
      Andrey Konovalov authored
      commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream.
      The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
      when tearing down the rawmidi interface. So we shouldn't try to free it
      in snd_usbmidi_create() after having registered the rawmidi interface.
      Found by KASAN.
      Change-Id: I109ad90b5836a5422380816671f9eb1a37e0557e
      Signed-off-by: default avatarAndrey Konovalov <>
      Acked-by: default avatarClemens Ladisch <>
      Cc: <>
      Signed-off-by: default avatarTakashi Iwai <>
    • Jann Horn's avatar
      ecryptfs: forbid opening files without mmap handler · d82a96b1
      Jann Horn authored
      This prevents users from triggering a stack overflow through a recursive
      invocation of pagefault handling that involves mapping procfs files into
      virtual memory.
      Change-Id: I91f0a2b4fecaa7deaef9d5b062dca1b88a083703
      Signed-off-by: default avatarJann Horn <>
      Acked-by: default avatarTyler Hicks <>
      Signed-off-by: default avatarLinus Torvalds <>
      Git-commit: 2f36db71009304b3f0b95afacd8eba1f9f046b87
      Signed-off-by: default avatarRavi Kumar Siddojigari <>
    • Eryu Guan's avatar
      ext4: validate s_first_meta_bg at mount time · fe44cd6f
      Eryu Guan authored
      Ralf Spenneberg reported that he hit a kernel crash when mounting a
      modified ext4 image. And it turns out that kernel crashed when
      calculating fs overhead (ext4_calculate_overhead()), this is because
      the image has very large s_first_meta_bg (debug code shows it's
      842150400), and ext4 overruns the memory in count_overhead() when
      setting bitmap buffer, which is PAGE_SIZE.
        buf = get_zeroed_page(GFP_NOFS);  <=== PAGE_SIZE buffer
        blks = count_overhead(sb, i, buf);
        for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) { <=== j = 842150400
                ext4_set_bit(EXT4_B2C(sbi, s++), buf);   <=== buffer overrun
      This can be reproduced easily for me by this script:
        rm -f fs.img
        mkdir -p /mnt/ext4
        fallocate -l 16M fs.img
        mke2fs -t ext4 -O bigalloc,meta_bg,^resize_inode -F fs.img
        debugfs -w -R "ssv first_meta_bg 842150400" fs.img
        mount -o loop fs.img /mnt/ext4
      Fix it by validating s_first_meta_bg first at mount time, and
      refusing to mount if its value exceeds the largest possible meta_bg
      Change-Id: Ie11267915312ed0638d968982c460f2123fd4485
      Reported-by: default avatarRalf Spenneberg <>
      Signed-off-by: default avatarEryu Guan <>
      Signed-off-by: default avatarTheodore Ts'o <>
      Reviewed-by: default avatarAndreas Dilger <>
    • Ilya Dryomov's avatar
      libceph: introduce ceph_crypt() for in-place en/decryption · 0521b209
      Ilya Dryomov authored
      Starting with 4.9, kernel stacks may be vmalloced and therefore not
      guaranteed to be physically contiguous; the new CONFIG_VMAP_STACK
      option is enabled by default on x86.  This makes it invalid to use
      on-stack buffers with the crypto scatterlist API, as sg_set_buf()
      expects a logical address and won't work with vmalloced addresses.
      There isn't a different (e.g. kvec-based) crypto API we could switch
      net/ceph/crypto.c to and the current scatterlist.h API isn't getting
      updated to accommodate this use case.  Allocating a new header and
      padding for each operation is a non-starter, so do the en/decryption
      in-place on a single pre-assembled (header + data + padding) heap
      buffer.  This is explicitly supported by the crypto API:
          "... the caller may provide the same scatter/gather list for the
           plaintext and cipher text. After the completion of the cipher
           operation, the plaintext data is replaced with the ciphertext data
           in case of an encryption and vice versa for a decryption."
      Change-Id: I554cae76340899bb6f00e2e06230f3a27da186a1
      Signed-off-by: default avatarIlya Dryomov <>
      Reviewed-by: default avatarSage Weil <>
    • Roman Gushchin's avatar
      fuse: break infinite loop in fuse_fill_write_pages() · eec5400f
      Roman Gushchin authored
      commit 3ca8138f014a913f98e6ef40e939868e1e9ea876 upstream.
      I got a report about unkillable task eating CPU. Further
      investigation shows, that the problem is in the fuse_fill_write_pages()
      function. If iov's first segment has zero length, we get an infinite
      loop, because we never reach iov_iter_advance() call.
      Fix this by calling iov_iter_advance() before repeating an attempt to
      copy data from userspace.
      A similar problem is described in 124d3b70
       ("fix writev regression:
      pan hanging unkillable and un-straceable"). If zero-length segmend
      is followed by segment with invalid address,
      iov_iter_fault_in_readable() checks only first segment (zero-length),
      iov_iter_copy_from_user_atomic() skips it, fails at second and
      returns zero -> goto again without skipping zero-length segment.
      Patch calls iov_iter_advance() before goto again: we'll skip zero-length
      segment at second iteraction and iov_iter_fault_in_readable() will detect
      invalid address.
      Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
      Change-Id: If1112e238627fec6fc94d09d339ea0a6140e5a1a
      Cc: Andrew Morton <>
      Cc: Maxim Patlasov <>
      Cc: Konstantin Khlebnikov <>
      Signed-off-by: default avatarRoman Gushchin <>
      Signed-off-by: default avatarMiklos Szeredi <>
      Fixes: ea9b9907 ("fuse: implement perform_write")
      Cc: <>
    • David Howells's avatar
      KEYS: Fix race between read and revoke · 22c99c69
      David Howells authored
      commit b4a1b4f5047e4f54e194681125c74c0aa64d637d upstream.
      This fixes CVE-2015-7550.
      There's a race between keyctl_read() and keyctl_revoke().  If the revoke
      happens between keyctl_read() checking the validity of a key and the key's
      semaphore being taken, then the key type read method will see a revoked key.
      This causes a problem for the user-defined key type because it assumes in
      its read method that there will always be a payload in a non-revoked key
      and doesn't check for a NULL pointer.
      Fix this by making keyctl_read() check the validity of a key after taking
      semaphore instead of before.
      I think the bug was introduced with the original keyrings code.
      This was discovered by a multithreaded test program generated by syzkaller
      ).  Here's a cleaned up version:
      	#include <sys/types.h>
      	#include <keyutils.h>
      	#include <pthread.h>
      	void *thr0(void *arg)
      		key_serial_t key = (unsigned long)arg;
      		return 0;
      	void *thr1(void *arg)
      		key_serial_t key = (unsigned long)arg;
      		char buffer[16];
      		keyctl_read(key, buffer, 16);
      		return 0;
      	int main()
      		key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
      		pthread_t th[5];
      		pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
      		pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
      		pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
      		pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
      		pthread_join(th[0], 0);
      		pthread_join(th[1], 0);
      		pthread_join(th[2], 0);
      		pthread_join(th[3], 0);
      		return 0;
      Build as:
      	cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread
      Run as:
      	while keyctl-race; do :; done
      as it may need several iterations to crash the kernel.  The crash can be
      summarised as:
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      	IP: [<ffffffff81279b08>] user_read+0x56/0xa3
      	Call Trace:
      	 [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7
      	 [<ffffffff81277815>] SyS_keyctl+0x83/0xe0
      	 [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f
      Change-Id: I46457ff377879a7422a5503356a657ac9a562841
      Reported-by: default avatarDmitry Vyukov <>
      Signed-off-by: default avatarDavid Howells <>
      Tested-by: default avatarDmitry Vyukov <>
      Signed-off-by: default avatarJames Morris <>
    • Vladis Dronov's avatar
      Input: aiptek - fix crash on detecting device without endpoints · 9eeca040
      Vladis Dronov authored
      The aiptek driver crashes in aiptek_probe() when a specially crafted USB
      device without endpoints is detected. This fix adds a check that the device
      has proper configuration expected by the driver. Also an error return value
      is changed to more matching one in one of the error paths.
      Change-Id: I02fa4ffcbe9a71948947ef5baeb72632688d9d07
      Reported-by: default avatarRalf Spenneberg <>
      Signed-off-by: default avatarVladis Dronov <>
      Signed-off-by: default avatarDmitry Torokhov <>
    • Benjamin Randazzo's avatar
      md: use kzalloc() when bitmap is disabled · 79da0adf
      Benjamin Randazzo authored
      commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
      In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
      mdu_bitmap_file_t called "file".
      5769         file = kmalloc(sizeof(*file), GFP_NOIO);
      5770         if (!file)
      5771                 return -ENOMEM;
      This structure is copied to user space at the end of the function.
      5786         if (err == 0 &&
      5787             copy_to_user(arg, file, sizeof(*file)))
      5788                 err = -EFAULT
      But if bitmap is disabled only the first byte of "file" is initialized
      with zero, so it's possible to read some bytes (up to 4095) of kernel
      space memory from user space. This is an information leak.
      5775         /* bitmap disabled, zero the first byte and copy out */
      5776         if (!mddev->bitmap_info.file)
      5777                 file->pathname[0] = '\0';
      Change-Id: Iafdff2e8356401cb63c2bb701ca0f559ad0f505f
      Signed-off-by: default avatarBenjamin Randazzo <>
      Signed-off-by: default avatarNeilBrown <>
    • Eric Dumazet's avatar
      udp: fix behavior of wrong checksums · 78902dc8
      Eric Dumazet authored
      We have two problems in UDP stack related to bogus checksums :
      1) We return -EAGAIN to application even if receive queue is not empty.
         This breaks applications using edge trigger epoll()
      2) Under UDP flood, we can loop forever without yielding to other
         processes, potentially hanging the host, especially on non SMP.
      This patch is an attempt to make things better.
      We might in the future add extra support for rt applications
      wanting to better control time spent doing a recv() in a hostile
      environment. For example we could validate checksums before queuing
      packets in socket receive queue.
      Change-Id: Id97a6bf78f775b876a86afbd3a2442a39d63ca52
      Signed-off-by: default avatarEric Dumazet <>
      Cc: Willem de Bruijn <>
      Signed-off-by: default avatarDavid S. Miller <>
    • Eric W. Biederman's avatar
      mnt: Fail collect_mounts when applied to unmounted mounts · b1f18682
      Eric W. Biederman authored
      The only users of collect_mounts are in audit_tree.c
      In audit_trim_trees and audit_add_tree_rule the path passed into
      collect_mounts is generated from kern_path passed an audit_tree
      pathname which is guaranteed to be an absolute path.   In those cases
      collect_mounts is obviously intended to work on mounted paths and
      if a race results in paths that are unmounted when collect_mounts
      it is reasonable to fail early.
      The paths passed into audit_tag_tree don't have the absolute path
      check.  But are used to play with fsnotify and otherwise interact with
      the audit_trees, so again operating only on mounted paths appears
      Avoid having to worry about what happens when we try and audit
      unmounted filesystems by restricting collect_mounts to mounts
      that appear in the mount tree.
      Change-Id: I4a41beaaf80165b9bffb12983cb16799247c4d92
      Signed-off-by: default avatar"Eric W. Biederman" <>
    • D.S. Ljungmark's avatar
      ipv6: Don't reduce hop limit for an interface · ba1b2edb
      D.S. Ljungmark authored
      commit 6fd99094de2b83d1d4c8457f2c83483b2828e75a upstream.
      A local route may have a lower hop_limit set than global routes do.
      RFC 3756, Section 4.2.7, "Parameter Spoofing"
      >   1.  The attacker includes a Current Hop Limit of one or another small
      >       number which the attacker knows will cause legitimate packets to
      >       be dropped before they reach their destination.
      >   As an example, one possible approach to mitigate this threat is to
      >   ignore very small hop limits.  The nodes could implement a
      >   configurable minimum hop limit, and ignore attempts to set it below
      >   said limit.
      Change-Id: I4b4313578ecd323f644bca9d78bf9dde39f24351
      Signed-off-by: default avatarD.S. Ljungmark <>
      Acked-by: default avatarHannes Frederic Sowa <>
      Signed-off-by: default avatarDavid S. Miller <>
    • Sasha Levin's avatar
      net: llc: use correct size for sysctl timeout entries · 4ce1701d
      Sasha Levin authored
      The timeout entries are sizeof(int) rather than sizeof(long), which
      means that when they were getting read we'd also leak kernel memory
      to userspace along with the timeout values.
      Change-Id: I328d1186720a6f70f555eeeb62c83ee69814868d
      Signed-off-by: default avatarSasha Levin <>
      Signed-off-by: default avatarDavid S. Miller <>
    • minz1's avatar
      arm: configs: enable BFQ I/O sched · 51e6f45c
      minz1 authored
      Change-Id: Ia7f43f1c4a362f11d7f696e7dde1d939b1b6782d
    • Zvikomborero Vincent Zvikaramba's avatar
      block: bfq: Set BFQ slice idle to 0 · ac7e868e
      Zvikomborero Vincent Zvikaramba authored
      * BFQ slice idle should be 0 since we do not have a SATA or other spinning disk type storage.
        From the documentation "Setting slice_idle to 0 will remove all the idling on queues/service
        tree level and one should see an overall improved throughput on faster storage devices"
      Change-Id: I0fa5e4abb9e42f65cf821cb6575bc77868a95960
    • Diogo Ferreira's avatar
      bfq-sched: Forcefully lookup entities when the cache is inconsistent · 24a0002e
      Diogo Ferreira authored
      bfq maintains a 'next-in-service' cache to prevent expensive lookups in
      the hot path. However, the cache sometimes becomes inconsistent and
      triggers a BUG:
      [44042.622839] -(3)[154:mmcqd/0]BUG: failure at ../../../../../../kernel/cyanogen/mt6735/block/bfq-sched.c:72/bfq_check_next_in_service()!
      [44042.622858] -(3)[154:mmcqd/0]Unable to handle kernel paging request at virtual address 0000dead
      [44042.622866] -(3)[154:mmcqd/0]pgd = ffffffc001361000
      [44042.622872] [0000dead] *pgd=000000007d816003, *pud=000000007d816003, *pmd=000000007d817003, *pte=0000000000000000
      [44042.622890] -(3)[154:mmcqd/0]Internal error: Oops: 96000045 [#1] PREEMPT SMP
      [44042.622907] -(3)[154:mmcqd/0]CPU: 3 PID: 154 Comm: mmcqd/0 Tainted:
      [44042.622915] -(3)[154:mmcqd/0]Hardware name: MT6735 (DT)
      [44042.622922] -(3)[154:mmcqd/0]task: ffffffc0378a6000 ti: ffffffc0378c4000
      [44042.622936] -(3)[154:mmcqd/0]PC is at bfq_dispatch_requests+0x6c4/0x9bc
      [44042.622944] -(3)[154:mmcqd/0]LR is at bfq_dispatch_requests+0x6bc/0x9bc
      [44042.622952] -(3)[154:mmcqd/0]pc : [<ffffffc000306a68>] lr : [<ffffffc000306a60>] pstate: 800001c5
      [44042.622958] -(3)[154:mmcqd/0]sp : ffffffc0378c7d30
      [44042.622962] x29: ffffffc0378c7d30 x28: 0000000000000000
      [44042.622972] x27: 0000000000000000 x26: ffffffc006c58810
      [44042.622981] x25: ffffffc037f89820 x24: ffffffc000f14000
      [44042.622990] x23: ffffffc036adb088 x22: ffffffc0369b2800
      [44042.623000] x21: ffffffc036adb098 x20: ffffffc01d6a3b60
      [44042.623009] x19: ffffffc036adb0c8 x18: 0000007f8cfa1500
      [44042.623018] x17: 0000007f8db44f40 x16: ffffffc00012d0c0
      [44042.623027] x15: 0000007f8dde04d8 x14: 676f6e6179632f6c
      [44042.623037] x13: 656e72656b2f2e2e x12: 2f2e2e2f2e2e2f2e
      [44042.623046] x11: 2e2f2e2e2f2e2e20 x10: 7461206572756c69
      [44042.623055] x9 : 6166203a4755425d x8 : 00000000001f0cc5
      [44042.623064] x7 : ffffffc000f3d5a0 x6 : 000000000000008b
      [44042.623073] x5 : 0000000000000000 x4 : 0000000000000004
      [44042.623082] x3 : 0000000000000002 x2 : 0000000000000001
      [44042.623091] x1 : 0000000000000aee x0 : 000000000000dead
      This patch makes the lookup resilient to cache inconsistencies by doing
      the expensive recomputation in cases where the bug would otherwise be
      Ticket: PORRDIGE-527
      Change-Id: I5dd701960057983a42d3d3bd57521e8d17c03d7f
    • Mauro Andreolini's avatar
      block, bfq: add Early Queue Merge (EQM) to BFQ-v7r8 for 3.10.8+ · 3e263dad
      Mauro Andreolini authored
      A set of processes may happen  to  perform interleaved reads, i.e.,requests
      whose union would give rise to a  sequential read  pattern.  There are two
      typical  cases: in the first  case,   processes  read  fixed-size chunks of
      data at a fixed distance from each other, while in the second case processes
      may read variable-size chunks at  variable distances. The latter case occurs
      for  example with  QEMU, which  splits the  I/O generated  by the  guest into
      multiple chunks,  and lets these chunks  be served by a  pool of cooperating
      processes,  iteratively  assigning  the  next  chunk of  I/O  to  the first
      available  process. CFQ  uses actual  queue merging  for the  first type of
      rocesses, whereas it  uses preemption to get a sequential  read pattern out
      of the read requests  performed by the second type of  processes. In the end
      it uses  two different  mechanisms to  achieve the  same goal: boosting the
      throughput with interleaved I/O.
      This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
      sequential  read pattern  with both  types of  processes. The  main idea is
      checking newly arrived requests against the next request of the active queue
      both in case of actual request insert and in case of request merge. By doing
      so, both the types of processes can be handled by just merging their queues.
      EQM is  then simpler and  more compact than the  pair of mechanisms used in
      Finally, EQM  also preserves the  typical low-latency properties of BFQ, by
      properly restoring the weight-raising state of  a queue when it gets back to
      a non-merged state.
      Change-Id: Ia4568c55a7c22420fcedd463e350b59832900994
      Signed-off-by: default avatarMauro Andreolini <>
      Signed-off-by: default avatarArianna Avanzini <>
      Signed-off-by: default avatarPaolo Valente <>
    • Arianna Avanzini's avatar
      block: cgroups, kconfig, build bits for BFQ-v7r8-3.10.8+ · 465c21e6
      Arianna Avanzini authored
      Update Kconfig.iosched and do the related Makefile changes to include
      kernel configuration options for BFQ. Also add the bfqio controller
      to the cgroups subsystem.
      Change-Id: Ia0b842c3663165cba46a9ffdebfcd35dad8feac7
      Signed-off-by: default avatarPaolo Valente <>
      Signed-off-by: default avatarArianna Avanzini <>
    • Paolo Valente's avatar
      block: introduce the BFQ-v7r8 I/O sched for 3.10.8+ · a43c3af2
      Paolo Valente authored
      Add the BFQ-v7r8 I/O scheduler to 3.10.8+.
      The general structure is borrowed from CFQ, as much of the code for
      handling I/O contexts Over time, several useful features have been
      ported from CFQ as well (details in the changelog in README.BFQ). A
      (bfq_)queue is associated to each task doing I/O on a device, and each
      time a scheduling decision has to be made a queue is selected and served
      until it expires.
          - Slices are given in the service domain: tasks are assigned
            budgets, measured in number of sectors. Once got the disk, a task
            must however consume its assigned budget within a configurable
            maximum time (by default, the maximum possible value of the
            budgets is automatically computed to comply with this timeout).
            This allows the desired latency vs "throughput boosting" tradeoff
            to be set.
          - Budgets are scheduled according to a variant of WF2Q+, implemented
            using an augmented rb-tree to take eligibility into account while
            preserving an O(log N) overall complexity.
          - A low-latency tunable is provided; if enabled, both interactive
            and soft real-time applications are guaranteed a very low latency.
          - Latency guarantees are preserved also in the presence of NCQ.
          - Also with flash-based devices, a high throughput is achieved
            while still preserving latency guarantees.
          - BFQ features Early Queue Merge (EQM), a sort of fusion of the
            cooperating-queue-merging and the preemption mechanisms present
            in CFQ. EQM is in fact a unified mechanism that tries to get a
            sequential read pattern, and hence a high throughput, with any
            set of processes performing interleaved I/O over a contiguous
            sequence of sectors.
          - BFQ supports full hierarchical scheduling, exporting a cgroups
            interface.  Since each node has a full scheduler, each group can
            be assigned its own weight.
          - If the cgroups interface is not used, only I/O priorities can be
            assigned to processes, with ioprio values mapped to weights
            with the relation weight = IOPRIO_BE_NR - ioprio.
          - ioprio classes are served in strict priority order, i.e., lower
            priority queues are not served as long as there are higher
            priority queues.  Among queues in the same class the bandwidth is
            distributed in proportion to the weight of each queue. A very
            thin extra bandwidth is however guaranteed to the Idle class, to
            prevent it from starving.
      Change-Id: I1c457f04e32b7adc96379071fb17ac62ef014c79
      Signed-off-by: default avatarPaolo Valente <>
      Signed-off-by: default avatarArianna Avanzini <>
    • Eric Dumazet's avatar
      UPSTREAM: packet: fix races in fanout_add() · 110f0080
      Eric Dumazet authored
      commit d199fab63c11998a602205f7ee7ff7c05c97164b upstream.
      Multiple threads can call fanout_add() at the same time.
      We need to grab fanout_mutex earlier to avoid races that could
      lead to one thread freeing po->rollover that was set by another thread.
      Do the same in fanout_release(), for peace of mind, and to help us
      finding lockdep issues earlier.
      [js] no rollover in 3.12
      Fixes: dc99f600
       ("packet: Add fanout support.")
      Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state")
      Signed-off-by: default avatarEric Dumazet <>
      Cc: Willem de Bruijn <>
      Signed-off-by: default avatarDavid S. Miller <>
      Signed-off-by: default avatarJiri Slaby <>
      Signed-off-by: default avatarWilly Tarreau <>
      (cherry picked from commit 2a272abc4e543f488b3a73292ee75a06f20d077a)
      Bug: 37897645
      Change-Id: I3b021869ee26b88d10f4d6408ce34d351543ce74
    • Takashi Iwai's avatar
      UPSTREAM: ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT · b6e6f7cd
      Takashi Iwai authored
      snd_timer_user_tselect() reallocates the queue buffer dynamically, but
      it forgot to reset its indices.  Since the read may happen
      concurrently with ioctl and snd_timer_user_tselect() allocates the
      buffer via kmalloc(), this may lead to the leak of uninitialized
      kernel-space data, as spotted via KMSAN:
        BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
        CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Call Trace:
         __dump_stack lib/dump_stack.c:16
         dump_stack+0x143/0x1b0 lib/dump_stack.c:52
         kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
         kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
         copy_to_user ./arch/x86/include/asm/uaccess.h:725
         snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
         do_loop_readv_writev fs/read_write.c:716
         __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
         do_readv_writev fs/read_write.c:894
         vfs_readv fs/read_write.c:908
         do_readv+0x52a/0x5d0 fs/read_write.c:934
         SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
         SyS_readv+0x87/0xb0 fs/read_write.c:1018
      This patch adds the missing reset of queue indices.  Together with the
      previous fix for the ioctl/read race, we cover the whole problem.
      Reported-by: default avatarAlexander Potapenko <>
      Tested-by: default avatarAlexander Potapenko <>
      Cc: <>
      Signed-off-by: default avatarTakashi Iwai <>
      (cherry picked from commit ba3021b2c79b2fa9114f92790a99deb27a65b728)
      Signed-off-by: default avatarConnor O'Brien <>
      Bug: 62201221
      Change-Id: I8d3d97bb0e6c2eefd050bf46b860dd603fe3f4c6