1. 30 1月, 2017 1 次提交
    • E
      can: Fix kernel panic at security_sock_rcv_skb · f1712c73
      Eric Dumazet 提交于
      Zhang Yanmin reported crashes [1] and provided a patch adding a
      synchronize_rcu() call in can_rx_unregister()
      
      The main problem seems that the sockets themselves are not RCU
      protected.
      
      If CAN uses RCU for delivery, then sockets should be freed only after
      one RCU grace period.
      
      Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
      ease stable backports with the following fix instead.
      
      [1]
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0
      
      Call Trace:
       <IRQ>
       [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60
       [<ffffffff81d55771>] sk_filter+0x41/0x210
       [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0
       [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0
       [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370
       [<ffffffff81f07af9>] can_receive+0xd9/0x120
       [<ffffffff81f07beb>] can_rcv+0xab/0x100
       [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0
       [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0
       [<ffffffff81d37f67>] process_backlog+0x127/0x280
       [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0
       [<ffffffff810c88d4>] __do_softirq+0x184/0x440
       [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30
       <EOI>
       [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40
       [<ffffffff810c8bed>] do_softirq+0x1d/0x20
       [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110
       [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520
       [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230
       [<ffffffff810e3baf>] process_one_work+0x24f/0x670
       [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0
       [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480
       [<ffffffff810ebafc>] kthread+0x12c/0x150
       [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70
      Reported-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1712c73
  2. 26 12月, 2016 2 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
    • T
      ktime: Get rid of the union · 2456e855
      Thomas Gleixner 提交于
      ktime is a union because the initial implementation stored the time in
      scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
      variant for 32bit machines. The Y2038 cleanup removed the timespec variant
      and switched everything to scalar nanoseconds. The union remained, but
      become completely pointless.
      
      Get rid of the union and just keep ktime_t as simple typedef of type s64.
      
      The conversion was done with coccinelle and some manual mopping up.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      2456e855
  3. 23 11月, 2016 1 次提交
  4. 01 11月, 2016 1 次提交
  5. 17 6月, 2016 4 次提交
  6. 13 10月, 2015 1 次提交
    • A
      can: avoid using timeval for uapi · ba61a8d9
      Arnd Bergmann 提交于
      The can subsystem communicates with user space using a bcm_msg_head
      header, which contains two timestamps. This is problematic for
      multiple reasons:
      
      a) The structure layout is currently incompatible between 64-bit
         user space and 32-bit user space, and cannot work in compat
         mode (other than x32).
      
      b) The timeval structure layout will change in 32-bit user
         space when we fix the y2038 overflow problem by redefining
         time_t to 64-bit, making new 32-bit user space incompatible
         with the current kernel interface.
         Cars last a long time and often use old kernels, so the actual
         users of this code are the most likely ones to migrate to y2038
         safe user space.
      
      This tries to work around part of the problem by changing the
      publicly visible user interface in the header, but not the binary
      interface. Fortunately, the values passed around in the structure
      are relative times and do not actually suffer from the y2038
      overflow, so 32-bit is enough here.
      
      We replace the use of 'struct timeval' with a newly defined
      'struct bcm_timeval' that uses the exact same binary layout
      as before and that still suffers from problem a) but not problem
      b).
      
      The downside of this approach is that any user space program
      that currently assigns a timeval structure to these members
      rather than writing the tv_sec/tv_usec portions individually
      will suffer a compile-time error when built with an updated
      kernel header. Fixing this error makes it work fine with old
      and new headers though.
      
      We could address problem a) by using '__u32' or 'int' members
      rather than 'long', but that would have a more significant
      downside in also breaking support for all existing 64-bit user
      binaries that might be using this interface, which is likely
      not acceptable.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Cc: linux-can@vger.kernel.org
      Cc: linux-api@vger.kernel.org
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      ba61a8d9
  7. 13 7月, 2015 1 次提交
    • O
      can: replace timestamp as unique skb attribute · d3b58c47
      Oliver Hartkopp 提交于
      Commit 514ac99c "can: fix multiple delivery of a single CAN frame for
      overlapping CAN filters" requires the skb->tstamp to be set to check for
      identical CAN skbs.
      
      Without timestamping to be required by user space applications this timestamp
      was not generated which lead to commit 36c01245 "can: fix loss of CAN frames
      in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs
      by introducing several __net_timestamp() calls.
      
      This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb()
      to add __net_timestamp() after skbuff creation to prevent the frame loss fixed
      in mainline Linux.
      
      This patch removes the timestamp dependency and uses an atomic counter to
      create an unique identifier together with the skbuff pointer.
      
      Btw: the new skbcnt element introduced in struct can_skb_priv has to be
      initialized with zero in out-of-tree drivers which are not using
      alloc_can{,fd}_skb() too.
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      d3b58c47
  8. 03 3月, 2015 1 次提交
  9. 02 3月, 2015 1 次提交
  10. 08 12月, 2014 2 次提交
  11. 24 11月, 2014 2 次提交
  12. 31 1月, 2014 1 次提交
  13. 19 1月, 2014 1 次提交
  14. 29 5月, 2013 1 次提交
  15. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  16. 19 2月, 2013 1 次提交
  17. 29 1月, 2013 1 次提交
  18. 26 1月, 2013 1 次提交
    • O
      can: add private data space for CAN sk_buffs · 156c2bb9
      Oliver Hartkopp 提交于
      The struct can_skb_priv is used to transport additional information along
      with the stored struct can(fd)_frame that can not be contained in existing
      struct sk_buff elements.
      
      can_skb_priv is located in the skb headroom, which does not touch the existing
      CAN sk_buff usage with skb->data and skb->len, so that even out-of-tree
      CAN drivers can be used without changes.
      
      Btw. out-of-tree CAN drivers without can_skb_priv in the sk_buff headroom
      would not support features based on can_skb_priv.
      
      The can_skb_priv->ifindex contains the first interface where the CAN frame
      appeared on the local host. Unfortunately skb->skb_iif can not be used as this
      value is overwritten in every netif_receive_skb() call.
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      156c2bb9
  19. 27 11月, 2012 1 次提交
  20. 06 10月, 2012 1 次提交
  21. 18 10月, 2011 1 次提交
  22. 30 9月, 2011 1 次提交
  23. 29 9月, 2011 1 次提交
  24. 07 6月, 2011 1 次提交
  25. 24 5月, 2011 1 次提交
    • D
      net: convert %p usage to %pK · 71338aa7
      Dan Rosenberg 提交于
      The %pK format specifier is designed to hide exposed kernel pointers,
      specifically via /proc interfaces.  Exposing these pointers provides an
      easy target for kernel write vulnerabilities, since they reveal the
      locations of writable structures containing easily triggerable function
      pointers.  The behavior of %pK depends on the kptr_restrict sysctl.
      
      If kptr_restrict is set to 0, no deviation from the standard %p behavior
      occurs.  If kptr_restrict is set to 1, the default, if the current user
      (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG
      (currently in the LSM tree), kernel pointers using %pK are printed as 0's.
       If kptr_restrict is set to 2, kernel pointers using %pK are printed as
      0's regardless of privileges.  Replacing with 0's was chosen over the
      default "(null)", which cannot be parsed by userland %p, which expects
      "(nil)".
      
      The supporting code for kptr_restrict and %pK are currently in the -mm
      tree.  This patch converts users of %p in net/ to %pK.  Cases of printing
      pointers to the syslog are not covered, since this would eliminate useful
      information for postmortem debugging and the reading of the syslog is
      already optionally protected by the dmesg_restrict sysctl.
      Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Thomas Graf <tgraf@infradead.org>
      Cc: Eugene Teo <eugeneteo@kernel.org>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Eric Paris <eparis@parisplace.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71338aa7
  26. 05 5月, 2011 1 次提交
  27. 20 4月, 2011 1 次提交
  28. 31 3月, 2011 1 次提交
  29. 28 3月, 2011 1 次提交
  30. 16 1月, 2011 1 次提交
  31. 01 1月, 2011 1 次提交
  32. 13 11月, 2010 1 次提交
  33. 12 8月, 2010 1 次提交
  34. 18 5月, 2010 1 次提交