1. 08 7月, 2014 9 次提交
  2. 12 6月, 2014 1 次提交
  3. 06 6月, 2014 3 次提交
  4. 17 5月, 2014 2 次提交
  5. 07 5月, 2014 1 次提交
  6. 29 4月, 2014 1 次提交
    • I
      libceph: fix non-default values check in apply_primary_affinity() · 92b2e751
      Ilya Dryomov 提交于
      osd_primary_affinity array is indexed into incorrectly when checking
      for non-default primary-affinity values.  This nullifies the impact of
      the rest of the apply_primary_affinity() and results in misdirected
      requests.
      
                      if (osds[i] != CRUSH_ITEM_NONE &&
                          osdmap->osd_primary_affinity[i] !=
                                                      ^^^
                                              CEPH_OSD_DEFAULT_PRIMARY_AFFINITY) {
      
      For a pool with size 2, this always ends up checking osd0 and osd1
      primary_affinity values, instead of the values that correspond to the
      osds in question.  E.g., given a [2,3] up set and a [max,max,0,max]
      primary affinity vector, requests are still sent to osd2, because both
      osd0 and osd1 happen to have max primary_affinity values and therefore
      we return from apply_primary_affinity() early on the premise that all
      osds in the given set have max (default) values.  Fix it.
      
      Fixes: http://tracker.ceph.com/issues/7954Signed-off-by: NIlya Dryomov <ilya.dryomov@inktank.com>
      Reviewed-by: NSage Weil <sage@inktank.com>
      92b2e751
  7. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  8. 05 4月, 2014 22 次提交