1. 10 10月, 2012 1 次提交
    • A
      rbd: reset BACKOFF if unable to re-queue · 588377d6
      Alex Elder 提交于
      If ceph_fault() is unable to queue work after a delay, it sets the
      BACKOFF connection flag so con_work() will attempt to do so.
      
      In con_work(), when BACKOFF is set, if queue_delayed_work() doesn't
      result in newly-queued work, it simply ignores this condition and
      proceeds as if no backoff delay were desired.  There are two
      problems with this--one of which is a bug.
      
      The first problem is simply that the intended behavior is to back
      off, and if we aren't able queue the work item to run after a delay
      we're not doing that.
      
      The only reason queue_delayed_work() won't queue work is if the
      provided work item is already queued.  In the messenger, this
      means that con_work() is already scheduled to be run again.  So
      if we simply set the BACKOFF flag again when this occurs, we know
      the next con_work() call will again attempt to hold off activity
      on the connection until after the delay.
      
      The second problem--the bug--is a leak of a reference count.  If
      queue_delayed_work() returns 0 in con_work(), con->ops->put() drops
      the connection reference held on entry to con_work().  However,
      processing is (was) allowed to continue, and at the end of the
      function a second con->ops->put() is called.
      
      This patch fixes both problems.
      Signed-off-by: NAlex Elder <elder@inktank.com>
      Reviewed-by: NSage Weil <sage@inktank.com>
      588377d6
  2. 02 10月, 2012 5 次提交
  3. 28 9月, 2012 2 次提交
  4. 26 9月, 2012 3 次提交
  5. 25 9月, 2012 1 次提交
  6. 24 9月, 2012 2 次提交
    • L
      batman-adv: Fix symmetry check / route flapping in multi interface setups · 7caf69fb
      Linus Lüssing 提交于
      If receiving an OGM from a neighbor other than the currently selected
      and if it has the same TQ then we are supposed to switch if this
      neighbor provides a more symmetric link than the currently selected one.
      
      However this symmetry check currently is broken if the interface of the
      neighbor we received the OGM from and the one of the currently selected
      neighbor differ: We are currently trying to determine the symmetry of the
      link towards the selected router via the link we received the OGM from
      instead of just checking via the link towards the currently selected
      router.
      
      This leads to way more route switches than necessary and can lead to
      permanent route flapping in many common multi interface setups.
      
      This patch fixes this issue by using the right interface for this
      symmetry check.
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      7caf69fb
    • D
      batman-adv: Fix change mac address of soft iface. · 40a3eb33
      Def 提交于
      Into function interface_set_mac_addr, the function tt_local_add was
      invoked before updating dev->dev_addr. The new MAC address was not
      tagged as NoPurge.
      Signed-off-by: NDef <def@laposte.net>
      40a3eb33
  7. 23 9月, 2012 1 次提交
  8. 22 9月, 2012 3 次提交
  9. 21 9月, 2012 8 次提交
    • E
      net: do not disable sg for packets requiring no checksum · c0d680e5
      Ed Cashin 提交于
      A change in a series of VLAN-related changes appears to have
      inadvertently disabled the use of the scatter gather feature of
      network cards for transmission of non-IP ethernet protocols like ATA
      over Ethernet (AoE).  Below is a reference to the commit that
      introduces a "harmonize_features" function that turns off scatter
      gather when the NIC does not support hardware checksumming for the
      ethernet protocol of an sk buff.
      
        commit f01a5236
        Author: Jesse Gross <jesse@nicira.com>
        Date:   Sun Jan 9 06:23:31 2011 +0000
      
            net offloading: Generalize netif_get_vlan_features().
      
      The can_checksum_protocol function is not equipped to consider a
      protocol that does not require checksumming.  Calling it for a
      protocol that requires no checksum is inappropriate.
      
      The patch below has harmonize_features call can_checksum_protocol when
      the protocol needs a checksum, so that the network layer is not forced
      to perform unnecessary skb linearization on the transmission of AoE
      packets.  Unnecessary linearization results in decreased performance
      and increased memory pressure, as reported here:
      
        http://www.spinics.net/lists/linux-mm/msg15184.html
      
      The problem has probably not been widely experienced yet, because
      only recently has the kernel.org-distributed aoe driver acquired the
      ability to use payloads of over a page in size, with the patchset
      recently included in the mm tree:
      
        https://lkml.org/lkml/2012/8/28/140
      
      The coraid.com-distributed aoe driver already could use payloads of
      greater than a page in size, but its users generally do not use the
      newest kernels.
      Signed-off-by: NEd Cashin <ecashin@coraid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0d680e5
    • M
      xfrm_user: don't copy esn replay window twice for new states · e3ac104d
      Mathias Krause 提交于
      The ESN replay window was already fully initialized in
      xfrm_alloc_replay_state_esn(). No need to copy it again.
      
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3ac104d
    • M
      xfrm_user: ensure user supplied esn replay window is valid · ecd79187
      Mathias Krause 提交于
      The current code fails to ensure that the netlink message actually
      contains as many bytes as the header indicates. If a user creates a new
      state or updates an existing one but does not supply the bytes for the
      whole ESN replay window, the kernel copies random heap bytes into the
      replay bitmap, the ones happen to follow the XFRMA_REPLAY_ESN_VAL
      netlink attribute. This leads to following issues:
      
      1. The replay window has random bits set confusing the replay handling
         code later on.
      
      2. A malicious user could use this flaw to leak up to ~3.5kB of heap
         memory when she has access to the XFRM netlink interface (requires
         CAP_NET_ADMIN).
      
      Known users of the ESN replay window are strongSwan and Steffen's
      iproute2 patch (<http://patchwork.ozlabs.org/patch/85962/>). The latter
      uses the interface with a bitmap supplied while the former does not.
      strongSwan is therefore prone to run into issue 1.
      
      To fix both issues without breaking existing userland allow using the
      XFRMA_REPLAY_ESN_VAL netlink attribute with either an empty bitmap or a
      fully specified one. For the former case we initialize the in-kernel
      bitmap with zero, for the latter we copy the user supplied bitmap. For
      state updates the full bitmap must be supplied.
      
      To prevent overflows in the bitmap length calculation the maximum size
      of bmp_len is limited to 128 by this patch -- resulting in a maximum
      replay window of 4096 packets. This should be sufficient for all real
      life scenarios (RFC 4303 recommends a default replay window size of 64).
      
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Martin Willi <martin@revosec.ch>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecd79187
    • M
      xfrm_user: fix info leak in copy_to_user_tmpl() · 1f86840f
      Mathias Krause 提交于
      The memory used for the template copy is a local stack variable. As
      struct xfrm_user_tmpl contains multiple holes added by the compiler for
      alignment, not initializing the memory will lead to leaking stack bytes
      to userland. Add an explicit memset(0) to avoid the info leak.
      
      Initial version of the patch by Brad Spengler.
      
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f86840f
    • M
      xfrm_user: fix info leak in copy_to_user_policy() · 7b789836
      Mathias Krause 提交于
      The memory reserved to dump the xfrm policy includes multiple padding
      bytes added by the compiler for alignment (padding bytes in struct
      xfrm_selector and struct xfrm_userpolicy_info). Add an explicit
      memset(0) before filling the buffer to avoid the heap info leak.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b789836
    • M
      xfrm_user: fix info leak in copy_to_user_state() · f778a636
      Mathias Krause 提交于
      The memory reserved to dump the xfrm state includes the padding bytes of
      struct xfrm_usersa_info added by the compiler for alignment (7 for
      amd64, 3 for i386). Add an explicit memset(0) before filling the buffer
      to avoid the info leak.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f778a636
    • M
      xfrm_user: fix info leak in copy_to_user_auth() · 4c87308b
      Mathias Krause 提交于
      copy_to_user_auth() fails to initialize the remainder of alg_name and
      therefore discloses up to 54 bytes of heap memory via netlink to
      userland.
      
      Use strncpy() instead of strcpy() to fill the trailing bytes of alg_name
      with null bytes.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c87308b
    • A
      tcp: restore rcv_wscale in a repair mode (v2) · bc26ccd8
      Andrey Vagin 提交于
      rcv_wscale is a symetric parameter with snd_wscale.
      
      Both this parameters are set on a connection handshake.
      
      Without this value a remote window size can not be interpreted correctly,
      because a value from a packet should be shifted on rcv_wscale.
      
      And one more thing is that wscale_ok should be set too.
      
      This patch doesn't break a backward compatibility.
      If someone uses it in a old scheme, a rcv window
      will be restored with the same bug (rcv_wscale = 0).
      
      v2: Save backward compatibility on big-endian system. Before
          the first two bytes were snd_wscale and the second two bytes were
          rcv_wscale. Now snd_wscale is opt_val & 0xFFFF and rcv_wscale >> 16.
          This approach is independent on byte ordering.
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      CC: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NAndrew Vagin <avagin@openvz.org>
      Acked-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc26ccd8
  10. 20 9月, 2012 4 次提交
  11. 19 9月, 2012 10 次提交
    • L
      cfg80211: fix possible circular lock on reg_regdb_search() · a85d0d7f
      Luis R. Rodriguez 提交于
      When call_crda() is called we kick off a witch hunt search
      for the same regulatory domain on our internal regulatory
      database and that work gets kicked off on a workqueue, this
      is done while the cfg80211_mutex is held. If that workqueue
      kicks off it will first lock reg_regdb_search_mutex and
      later cfg80211_mutex but to ensure two CPUs will not contend
      against cfg80211_mutex the right thing to do is to have the
      reg_regdb_search() wait until the cfg80211_mutex is let go.
      
      The lockdep report is pasted below.
      
      cfg80211: Calling CRDA to update world regulatory domain
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.3.8 #3 Tainted: G           O
      -------------------------------------------------------
      kworker/0:1/235 is trying to acquire lock:
       (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
      
      but task is already holding lock:
       (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (reg_regdb_search_mutex){+.+...}:
             [<800a8384>] lock_acquire+0x60/0x88
             [<802950a8>] mutex_lock_nested+0x54/0x31c
             [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211]
      
      -> #1 (reg_mutex#2){+.+...}:
             [<800a8384>] lock_acquire+0x60/0x88
             [<802950a8>] mutex_lock_nested+0x54/0x31c
             [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211]
      
      -> #0 (cfg80211_mutex){+.+...}:
             [<800a77b8>] __lock_acquire+0x10d4/0x17bc
             [<800a8384>] lock_acquire+0x60/0x88
             [<802950a8>] mutex_lock_nested+0x54/0x31c
             [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
      
      other info that might help us debug this:
      
      Chain exists of:
        cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(reg_regdb_search_mutex);
                                     lock(reg_mutex#2);
                                     lock(reg_regdb_search_mutex);
        lock(cfg80211_mutex);
      
       *** DEADLOCK ***
      
      3 locks held by kworker/0:1/235:
       #0:  (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460
       #1:  (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460
       #2:  (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]
      
      stack backtrace:
      Call Trace:
      [<80290fd4>] dump_stack+0x8/0x34
      [<80291bc4>] print_circular_bug+0x2ac/0x2d8
      [<800a77b8>] __lock_acquire+0x10d4/0x17bc
      [<800a8384>] lock_acquire+0x60/0x88
      [<802950a8>] mutex_lock_nested+0x54/0x31c
      [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
      Reported-by: NFelix Fietkau <nbd@openwrt.org>
      Tested-by: NFelix Fietkau <nbd@openwrt.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a85d0d7f
    • V
      Bluetooth: Fix not removing power_off delayed work · 78c04c0b
      Vinicius Costa Gomes 提交于
      For example, when a usb reset is received (I could reproduce it
      running something very similar to this[1] in a loop) it could be
      that the device is unregistered while the power_off delayed work
      is still scheduled to run.
      
      Backtrace:
      
      WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
      Hardware name: To Be Filled By O.E.M.
      ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x26
      Modules linked in: nouveau mxm_wmi btusb wmi bluetooth ttm coretemp drm_kms_helper
      Pid: 2114, comm: usb-reset Not tainted 3.5.0bt-next #2
      Call Trace:
       [<ffffffff8124cc00>] ? free_obj_work+0x57/0x91
       [<ffffffff81058f88>] warn_slowpath_common+0x7e/0x97
       [<ffffffff81059035>] warn_slowpath_fmt+0x41/0x43
       [<ffffffff8124ccb6>] debug_print_object+0x7c/0x8d
       [<ffffffff8106e3ec>] ? __queue_work+0x259/0x259
       [<ffffffff8124d63e>] ? debug_check_no_obj_freed+0x6f/0x1b5
       [<ffffffff8124d667>] debug_check_no_obj_freed+0x98/0x1b5
       [<ffffffffa00aa031>] ? bt_host_release+0x10/0x1e [bluetooth]
       [<ffffffff810fc035>] kfree+0x90/0xe6
       [<ffffffffa00aa031>] bt_host_release+0x10/0x1e [bluetooth]
       [<ffffffff812ec2f9>] device_release+0x4a/0x7e
       [<ffffffff8123ef57>] kobject_release+0x11d/0x154
       [<ffffffff8123ed98>] kobject_put+0x4a/0x4f
       [<ffffffff812ec0d9>] put_device+0x12/0x14
       [<ffffffffa009472b>] hci_free_dev+0x22/0x26 [bluetooth]
       [<ffffffffa0280dd0>] btusb_disconnect+0x96/0x9f [btusb]
       [<ffffffff813581b4>] usb_unbind_interface+0x57/0x106
       [<ffffffff812ef988>] __device_release_driver+0x83/0xd6
       [<ffffffff812ef9fb>] device_release_driver+0x20/0x2d
       [<ffffffff813582a7>] usb_driver_release_interface+0x44/0x7b
       [<ffffffff81358795>] usb_forced_unbind_intf+0x45/0x4e
       [<ffffffff8134f959>] usb_reset_device+0xa6/0x12e
       [<ffffffff8135df86>] usbdev_do_ioctl+0x319/0xe20
       [<ffffffff81203244>] ? avc_has_perm_flags+0xc9/0x12e
       [<ffffffff812031a0>] ? avc_has_perm_flags+0x25/0x12e
       [<ffffffff81050101>] ? do_page_fault+0x31e/0x3a1
       [<ffffffff8135eaa6>] usbdev_ioctl+0x9/0xd
       [<ffffffff811126b1>] vfs_ioctl+0x21/0x34
       [<ffffffff81112f7b>] do_vfs_ioctl+0x408/0x44b
       [<ffffffff81208d45>] ? file_has_perm+0x76/0x81
       [<ffffffff8111300f>] sys_ioctl+0x51/0x76
       [<ffffffff8158db22>] system_call_fastpath+0x16/0x1b
      
      [1] http://cpansearch.perl.org/src/DPAVLIN/Biblio-RFID-0.03/examples/usbreset.cSigned-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      78c04c0b
    • A
      Bluetooth: Fix freeing uninitialized delayed works · aad3d0e3
      Andrei Emeltchenko 提交于
      When releasing L2CAP socket which is in BT_CONFIG state l2cap_chan_close
      invokes l2cap_send_disconn_req which cancel delayed works which are only
      set in BT_CONNECTED state with l2cap_ertm_init. Add state check before
      cancelling those works.
      
      ...
      [ 9668.574372] [21085] l2cap_sock_release: sock cd065200, sk f073e800
      [ 9668.574399] [21085] l2cap_sock_shutdown: sock cd065200, sk f073e800
      [ 9668.574411] [21085] l2cap_chan_close: chan f073ec00 state BT_CONFIG sk f073e800
      [ 9668.574421] [21085] l2cap_send_disconn_req: chan f073ec00 conn ecc16600
      [ 9668.574441] INFO: trying to register non-static key.
      [ 9668.574443] the code is fine but needs lockdep annotation.
      [ 9668.574446] turning off the locking correctness validator.
      [ 9668.574450] Pid: 21085, comm: obex-client Tainted: G           O 3.5.0+ #57
      [ 9668.574452] Call Trace:
      [ 9668.574463]  [<c10a64b3>] __lock_acquire+0x12e3/0x1700
      [ 9668.574468]  [<c10a44fb>] ? trace_hardirqs_on+0xb/0x10
      [ 9668.574476]  [<c15e4f60>] ? printk+0x4d/0x4f
      [ 9668.574479]  [<c10a6e38>] lock_acquire+0x88/0x130
      [ 9668.574487]  [<c1059740>] ? try_to_del_timer_sync+0x60/0x60
      [ 9668.574491]  [<c1059790>] del_timer_sync+0x50/0xc0
      [ 9668.574495]  [<c1059740>] ? try_to_del_timer_sync+0x60/0x60
      [ 9668.574515]  [<f8aa1c23>] l2cap_send_disconn_req+0xe3/0x160 [bluetooth]
      ...
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      aad3d0e3
    • A
      Bluetooth: mgmt: Fix enabling LE while powered off · 562fcc24
      Andrzej Kaczmarek 提交于
      When new BT USB adapter is plugged in it's configured while still being powered
      off (HCI_AUTO_OFF flag is set), thus Set LE will only set dev_flags but won't
      write changes to controller. As a result it's not possible to start device
      discovery session on LE controller as it uses interleaved discovery which
      requires LE Supported Host flag in extended features.
      
      This patch ensures HCI Write LE Host Supported is sent when Set Powered is
      called to power on controller and clear HCI_AUTO_OFF flag.
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      562fcc24
    • A
      Bluetooth: mgmt: Fix enabling SSP while powered off · 3d1cbdd6
      Andrzej Kaczmarek 提交于
      When new BT USB adapter is plugged in it's configured while still being powered
      off (HCI_AUTO_OFF flag is set), thus Set SSP will only set dev_flags but won't
      write changes to controller. As a result remote devices won't use Secure Simple
      Pairing with our device due to SSP Host Support flag disabled in extended
      features and may also reject SSP attempt from our side (with possible fallback
      to legacy pairing).
      
      This patch ensures HCI Write Simple Pairing Mode is sent when Set Powered is
      called to power on controller and clear HCI_AUTO_OFF flag.
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      3d1cbdd6
    • L
      xfrm: fix a read lock imbalance in make_blackhole · 433a1954
      Li RongQing 提交于
      if xfrm_policy_get_afinfo returns 0, it has already released the read
      lock, xfrm_policy_put_afinfo should not be called again.
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      433a1954
    • E
      tcp: fix regression in urgent data handling · 1d57f195
      Eric Dumazet 提交于
      Stephan Springl found that commit 1402d366 "tcp: introduce
      tcp_try_coalesce" introduced a regression for rlogin
      
      It turns out problem comes from TCP urgent data handling and
      a change in behavior in input path.
      
      rlogin sends two one-byte packets with URG ptr set, and when next data
      frame is coalesced, we lack sk_data_ready() calls to wakeup consumer.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NStephan Springl <springl-k@lar.bfw.de>
      Cc: Alexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d57f195
    • M
      net: fix memory leak on oom with zerocopy · 0e698bf6
      Michael S. Tsirkin 提交于
      If orphan flags fails, we don't free the skb
      on receive, which leaks the skb memory.
      
      Return value was also wrong: netif_receive_skb
      is supposed to return NET_RX_DROP, not ENOMEM.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e698bf6
    • M
      xfrm_user: return error pointer instead of NULL #2 · c2546372
      Mathias Krause 提交于
      When dump_one_policy() returns an error, e.g. because of a too small
      buffer to dump the whole xfrm policy, xfrm_policy_netlink() returns
      NULL instead of an error pointer. But its caller expects an error
      pointer and therefore continues to operate on a NULL skbuff.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2546372
    • M
      xfrm_user: return error pointer instead of NULL · 864745d2
      Mathias Krause 提交于
      When dump_one_state() returns an error, e.g. because of a too small
      buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
      instead of an error pointer. But its callers expect an error pointer
      and therefore continue to operate on a NULL skbuff.
      
      This could lead to a privilege escalation (execution of user code in
      kernel context) if the attacker has CAP_NET_ADMIN and is able to map
      address 0.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      864745d2