1. 03 12月, 2015 12 次提交
  2. 02 12月, 2015 6 次提交
    • D
      bpf, array: fix heap out-of-bounds access when updating elements · fbca9d2d
      Daniel Borkmann 提交于
      During own review but also reported by Dmitry's syzkaller [1] it has been
      noticed that we trigger a heap out-of-bounds access on eBPF array maps
      when updating elements. This happens with each map whose map->value_size
      (specified during map creation time) is not multiple of 8 bytes.
      
      In array_map_alloc(), elem_size is round_up(attr->value_size, 8) and
      used to align array map slots for faster access. However, in function
      array_map_update_elem(), we update the element as ...
      
      memcpy(array->value + array->elem_size * index, value, array->elem_size);
      
      ... where we access 'value' out-of-bounds, since it was allocated from
      map_update_elem() from syscall side as kmalloc(map->value_size, GFP_USER)
      and later on copied through copy_from_user(value, uvalue, map->value_size).
      Thus, up to 7 bytes, we can access out-of-bounds.
      
      Same could happen from within an eBPF program, where in worst case we
      access beyond an eBPF program's designated stack.
      
      Since 1be7f75d ("bpf: enable non-root eBPF programs") didn't hit an
      official release yet, it only affects priviledged users.
      
      In case of array_map_lookup_elem(), the verifier prevents eBPF programs
      from accessing beyond map->value_size through check_map_access(). Also
      from syscall side map_lookup_elem() only copies map->value_size back to
      user, so nothing could leak.
      
        [1] http://github.com/google/syzkaller
      
      Fixes: 28fbcfa0 ("bpf: add array type of eBPF maps")
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbca9d2d
    • E
      net: fix sock_wake_async() rcu protection · ceb5d58b
      Eric Dumazet 提交于
      Dmitry provided a syzkaller (http://github.com/google/syzkaller)
      triggering a fault in sock_wake_async() when async IO is requested.
      
      Said program stressed af_unix sockets, but the issue is generic
      and should be addressed in core networking stack.
      
      The problem is that by the time sock_wake_async() is called,
      we should not access the @flags field of 'struct socket',
      as the inode containing this socket might be freed without
      further notice, and without RCU grace period.
      
      We already maintain an RCU protected structure, "struct socket_wq"
      so moving SOCKWQ_ASYNC_NOSPACE & SOCKWQ_ASYNC_WAITDATA into it
      is the safe route.
      
      It also reduces number of cache lines needing dirtying, so might
      provide a performance improvement anyway.
      
      In followup patches, we might move remaining flags (SOCK_NOSPACE,
      SOCK_PASSCRED, SOCK_PASSSEC) to save 8 bytes and let 'struct socket'
      being mostly read and let it being shared between cpus.
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ceb5d58b
    • E
      net: rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA · 9cd3e072
      Eric Dumazet 提交于
      This patch is a cleanup to make following patch easier to
      review.
      
      Goal is to move SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA
      from (struct socket)->flags to a (struct socket_wq)->flags
      to benefit from RCU protection in sock_wake_async()
      
      To ease backports, we rename both constants.
      
      Two new helpers, sk_set_bit(int nr, struct sock *sk)
      and sk_clear_bit(int net, struct sock *sk) are added so that
      following patch can change their implementation.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cd3e072
    • A
      vmxnet3: fix checks for dma mapping errors · 5738a09d
      Alexey Khoroshilov 提交于
      vmxnet3_drv does not check dma_addr with dma_mapping_error()
      after mapping dma memory. The patch adds the checks and
      tries to handle failures.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: NShrikrishna Khare <skhare@vmware.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5738a09d
    • P
      wan/x25: Fix use-after-free in x25_asy_open_tty() · ee9159dd
      Peter Hurley 提交于
      The N_X25 line discipline may access the previous line discipline's closed
      and already-freed private data on open [1].
      
      The tty->disc_data field _never_ refers to valid data on entry to the
      line discipline's open() method. Rather, the ldisc is expected to
      initialize that field for its own use for the lifetime of the instance
      (ie. from open() to close() only).
      
      [1]
          [  634.336761] ==================================================================
          [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
          [  634.339558] Read of size 4 by task syzkaller_execu/8981
          [  634.340359] =============================================================================
          [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
          ...
          [  634.405018] Call Trace:
          [  634.405277] dump_stack (lib/dump_stack.c:52)
          [  634.405775] print_trailer (mm/slub.c:655)
          [  634.406361] object_err (mm/slub.c:662)
          [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
          [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
          [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
          [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
          [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
          [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
          [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
          [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
          [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
      Reported-and-tested-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee9159dd
    • N
      Revert "ipv6: ndisc: inherit metadata dst when creating ndisc requests" · 304d888b
      Nicolas Dichtel 提交于
      This reverts commit ab450605.
      
      In IPv6, we cannot inherit the dst of the original dst. ndisc packets
      are IPv6 packets and may take another route than the original packet.
      
      This patch breaks the following scenario: a packet comes from eth0 and
      is forwarded through vxlan1. The encapsulated packet triggers an NS
      which cannot be sent because of the wrong route.
      
      CC: Jiri Benc <jbenc@redhat.com>
      CC: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      304d888b
  3. 01 12月, 2015 10 次提交
  4. 30 11月, 2015 2 次提交
  5. 26 11月, 2015 2 次提交
    • D
      bpf: fix clearing on persistent program array maps · c9da161c
      Daniel Borkmann 提交于
      Currently, when having map file descriptors pointing to program arrays,
      there's still the issue that we unconditionally flush program array
      contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
      when such a file descriptor is released and is independent of the map's
      refcount.
      
      Having this flush independent of the refcount is for a reason: there
      can be arbitrary complex dependency chains among tail calls, also circular
      ones (direct or indirect, nesting limit determined during runtime), and
      we need to make sure that the map drops all references to eBPF programs
      it holds, so that the map's refcount can eventually drop to zero and
      initiate its freeing. Btw, a walk of the whole dependency graph would
      not be possible for various reasons, one being complexity and another
      one inconsistency, i.e. new programs can be added to parts of the graph
      at any time, so there's no guaranteed consistent state for the time of
      such a walk.
      
      Now, the program array pinning itself works, but the issue is that each
      derived file descriptor on close would nevertheless call unconditionally
      into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
      this flush until the last reference to a user is dropped. As this only
      concerns a subset of references (f.e. a prog array could hold a program
      that itself has reference on the prog array holding it, etc), we need to
      track them separately.
      
      Short analysis on the refcounting: on map creation time usercnt will be
      one, so there's no change in behaviour for bpf_map_release(), if unpinned.
      If we already fail in map_create(), we are immediately freed, and no
      file descriptor has been made public yet. In bpf_obj_pin_user(), we need
      to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
      reference, so before we drop the reference on the fd with fdput().
      Therefore, if actual pinning fails, we need to drop that reference again
      in bpf_any_put(), otherwise we keep holding it. When last reference
      drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
      care of dropping the usercnt again. In the bpf_obj_get_user() case, the
      bpf_any_get() will grab a reference on the usercnt, still at a time when
      we have the reference on the path. Should we later on fail to grab a new
      file descriptor, bpf_any_put() will drop it, otherwise we hold it until
      bpf_map_release() time.
      
      Joint work with Alexei.
      
      Fixes: b2197755 ("bpf: add support for persistent maps/progs")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9da161c
    • C
      isdn: Partially revert debug format string usage clean up · 19cebbcb
      Christoph Biedl 提交于
      Commit 35a4a573 ("isdn: clean up debug format string usage") introduced
      a safeguard to avoid accidential format string interpolation of data
      when calling debugl1 or HiSax_putstatus. This did however not take into
      account VHiSax_putstatus (called by HiSax_putstatus) does *not* call
      vsprintf if the head parameter is NULL - the format string is treated
      as plain text then instead. As a result, the string "%s" is processed
      literally, and the actual information is lost. This affects the isdnlog
      userspace program which stopped logging information since that commit.
      
      So revert the HiSax_putstatus invocations to the previous state.
      
      Fixes: 35a4a573 ("isdn: clean up debug format string usage")
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Signed-off-by: NChristoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19cebbcb
  6. 25 11月, 2015 8 次提交
    • Q
      RDS: fix race condition when sending a message on unbound socket · 8c7188b2
      Quentin Casasnovas 提交于
      Sasha's found a NULL pointer dereference in the RDS connection code when
      sending a message to an apparently unbound socket.  The problem is caused
      by the code checking if the socket is bound in rds_sendmsg(), which checks
      the rs_bound_addr field without taking a lock on the socket.  This opens a
      race where rs_bound_addr is temporarily set but where the transport is not
      in rds_bind(), leading to a NULL pointer dereference when trying to
      dereference 'trans' in __rds_conn_create().
      
      Vegard wrote a reproducer for this issue, so kindly ask him to share if
      you're interested.
      
      I cannot reproduce the NULL pointer dereference using Vegard's reproducer
      with this patch, whereas I could without.
      
      Complete earlier incomplete fix to CVE-2015-6937:
      
        74e98eb0 ("RDS: verify the underlying transport exists before creating a connection")
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: stable@vger.kernel.org
      Reviewed-by: NVegard Nossum <vegard.nossum@oracle.com>
      Reviewed-by: NSasha Levin <sasha.levin@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NQuentin Casasnovas <quentin.casasnovas@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c7188b2
    • A
      net: openvswitch: Remove invalid comment · 20f79566
      Aaron Conole 提交于
      During pre-upstream development, the openvswitch datapath used a custom
      hashtable to store vports that could fail on delete due to lack of
      memory. However, prior to upstream submission, this code was reworked to
      use an hlist based hastable with flexible-array based buckets. As such
      the failure condition was eliminated from the vport_del path, rendering
      this comment invalid.
      Signed-off-by: NAaron Conole <aconole@bytheb.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20f79566
    • N
      net: ipmr, ip6mr: fix vif/tunnel failure race condition · fbdd29bf
      Nikolay Aleksandrov 提交于
      Since (at least) commit b17a7c17 ("[NET]: Do sysfs registration as
      part of register_netdevice."), netdev_run_todo() deals only with
      unregistration, so we don't need to do the rtnl_unlock/lock cycle to
      finish registration when failing pimreg or dvmrp device creation. In
      fact that opens a race condition where someone can delete the device
      while rtnl is unlocked because it's fully registered. The problem gets
      worse when netlink support is introduced as there are more points of entry
      that can cause it and it also makes reusing that code correctly impossible.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbdd29bf
    • D
      rxrpc: Correctly handle ack at end of client call transmit phase · 33c40e24
      David Howells 提交于
      Normally, the transmit phase of a client call is implicitly ack'd by the
      reception of the first data packet of the response being received.
      However, if a security negotiation happens, the transmit phase, if it is
      entirely contained in a single packet, may get an ack packet in response
      and then may get aborted due to security negotiation failure.
      
      Because the client has shifted state to RXRPC_CALL_CLIENT_AWAIT_REPLY due
      to having transmitted all the data, the code that handles processing of the
      received ack packet doesn't note the hard ack the data packet.
      
      The following abort packet in the case of security negotiation failure then
      incurs an assertion failure when it tries to drain the Tx queue because the
      hard ack state is out of sync (hard ack means the packets have been
      processed and can be discarded by the sender; a soft ack means that the
      packets are received but could still be discarded and rerequested by the
      receiver).
      
      To fix this, we should record the hard ack we received for the ack packet.
      
      The assertion failure looks like:
      
      	RxRPC: Assertion failed
      	1 <= 0 is false
      	0x1 <= 0x0 is false
      	------------[ cut here ]------------
      	kernel BUG at ../net/rxrpc/ar-ack.c:431!
      	...
      	RIP: 0010:[<ffffffffa006857b>]  [<ffffffffa006857b>] rxrpc_rotate_tx_window+0xbc/0x131 [af_rxrpc]
      	...
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33c40e24
    • M
      ipv6: distinguish frag queues by device for multicast and link-local packets · 264640fc
      Michal Kubeček 提交于
      If a fragmented multicast packet is received on an ethernet device which
      has an active macvlan on top of it, each fragment is duplicated and
      received both on the underlying device and the macvlan. If some
      fragments for macvlan are processed before the whole packet for the
      underlying device is reassembled, the "overlapping fragments" test in
      ip6_frag_queue() discards the whole fragment queue.
      
      To resolve this, add device ifindex to the search key and require it to
      match reassembling multicast packets and packets to link-local
      addresses.
      
      Note: similar patch has been already submitted by Yoshifuji Hideaki in
      
        http://patchwork.ozlabs.org/patch/220979/
      
      but got lost and forgotten for some reason.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      264640fc
    • I
      drivers: net: xgene: fix: ifconfig up/down crash · aeb20b6b
      Iyappan Subramanian 提交于
      Fixing kernel crash when doing ifconfig down and up in a loop,
      
      [ 124.028237] Call trace:
      [ 124.030670] [<ffffffc000367ce0>] memcpy+0x20/0x180
      [ 124.035436] [<ffffffc00053c250>] skb_clone+0x3c/0xa8
      [ 124.040374] [<ffffffc00053ffa4>] __skb_tstamp_tx+0xc0/0x118
      [ 124.045918] [<ffffffc00054000c>] skb_tstamp_tx+0x10/0x1c
      [ 124.051203] [<ffffffc00049bc84>] xgene_enet_start_xmit+0x2e4/0x33c
      [ 124.057352] [<ffffffc00054fc20>] dev_hard_start_xmit+0x2e8/0x400
      [ 124.063327] [<ffffffc00056cb14>] sch_direct_xmit+0x90/0x1d4
      [ 124.068870] [<ffffffc000550100>] __dev_queue_xmit+0x28c/0x498
      [ 124.074585] [<ffffffc00055031c>] dev_queue_xmit_sk+0x10/0x1c
      [ 124.080216] [<ffffffc0005c3f14>] ip_finish_output2+0x3d0/0x438
      [ 124.086017] [<ffffffc0005c5794>] ip_finish_output+0x198/0x1ac
      [ 124.091732] [<ffffffc0005c61d4>] ip_output+0xec/0x164
      [ 124.096755] [<ffffffc0005c5910>] ip_local_out_sk+0x38/0x48
      [ 124.102211] [<ffffffc0005c5d84>] ip_queue_xmit+0x288/0x330
      [ 124.107668] [<ffffffc0005da8bc>] tcp_transmit_skb+0x908/0x964
      [ 124.113383] [<ffffffc0005dc0d4>] tcp_send_ack+0x128/0x138
      [ 124.118753] [<ffffffc0005d1580>] __tcp_ack_snd_check+0x5c/0x94
      [ 124.124555] [<ffffffc0005d7a0c>] tcp_rcv_established+0x554/0x68c
      [ 124.130530] [<ffffffc0005df0d4>] tcp_v4_do_rcv+0xa4/0x37c
      [ 124.135900] [<ffffffc000539430>] release_sock+0xb4/0x150
      [ 124.141184] [<ffffffc0005cdf88>] tcp_recvmsg+0x448/0x9e0
      [ 124.146468] [<ffffffc0005f2f3c>] inet_recvmsg+0xa0/0xc0
      [ 124.151666] [<ffffffc000533660>] sock_recvmsg+0x10/0x1c
      [ 124.156863] [<ffffffc0005370d4>] SyS_recvfrom+0xa4/0xf8
      [ 124.162061] Code: f2400c84 540001c0 cb040042 36000064 (38401423)
      [ 124.168133] ---[ end trace 7ab2550372e8a65b ]---
      
      The fix was to reorder napi_enable, napi_disable, request_irq and
      free_irq calls, move register_netdev after dma_coerce_mask_and_coherent.
      Signed-off-by: NIyappan Subramanian <isubramanian@apm.com>
      Tested-by: NKhuong Dinh <kdinh@apm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aeb20b6b
    • B
      net: cdc_ncm: fix NULL pointer deref in cdc_ncm_bind_common · 6527f833
      Bjørn Mork 提交于
      Commit 77b0a099 ("cdc-ncm: use common parser") added a dangerous
      new trust in the CDC functional descriptors presented by the device,
      unconditionally assuming that any device handled by the driver has
      a CDC Union descriptor.
      
      This descriptor is required by the NCM and MBIM specs, but crashing
      on non-compliant devices is still unacceptable. Not only will that
      allow malicious devices to crash the kernel, but in this case it is
      also well known that there are non-compliant real devices on the
      market - as shown by the comment accompanying the IAD workaround
      in the same function.
      
      The Sierra Wireless EM7305 is an example of such device, having
      a CDC header and a CDC MBIM descriptor but no CDC Union:
      
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber       12
            bAlternateSetting       0
            bNumEndpoints           1
            bInterfaceClass         2 Communications
            bInterfaceSubClass     14
            bInterfaceProtocol      0
            iInterface              0
            CDC Header:
              bcdCDC               1.10
            CDC MBIM:
              bcdMBIMVersion       1.00
              wMaxControlMessage   4096
              bNumberFilters       16
              bMaxFilterSize       128
              wMaxSegmentSize      4064
              bmNetworkCapabilities 0x20
                8-byte ntb input size
            Endpoint Descriptor:
      	..
      
      The conversion to a common parser also left the local cdc_union
      variable untouched.  This caused the IAD workaround code to be applied
      to all devices with an IAD descriptor, which was never intended.  Finish
      the conversion by testing for hdr.usb_cdc_union_desc instead.
      
      Cc: Oliver Neukum <oneukum@suse.com>
      Fixes: 77b0a099 ("cdc-ncm: use common parser")
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6527f833
    • D
      Merge tag 'linux-can-fixes-for-4.4-20151123' of... · 90bb81f3
      David S. Miller 提交于
      Merge tag 'linux-can-fixes-for-4.4-20151123' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2015-11-23
      
      this is a pull request of three patches for the upcoming v4.4 release.
      
      The first patch is by Mirza Krak, it fixes a problem with the sja1000 driver
      after resuming from suspend to disk, by clearing all outstanding interrupts.
      Oliver Hartkopp contributes two patches targeting almost all driver, they fix
      the assignment of the error location in CAN error messages.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90bb81f3