1. 23 6月, 2018 2 次提交
  2. 23 3月, 2018 1 次提交
    • S
      xfrm: Fix transport mode skb control buffer usage. · 9a3fb9fb
      Steffen Klassert 提交于
      A recent commit introduced a new struct xfrm_trans_cb
      that is used with the sk_buff control buffer. Unfortunately
      it placed the structure in front of the control buffer and
      overlooked that the IPv4/IPv6 control buffer is still needed
      for some layer 4 protocols. As a result the IPv4/IPv6 control
      buffer is overwritten with this structure. Fix this by setting
      a apropriate header in front of the structure.
      
      Fixes acf568ee ("xfrm: Reinject transport-mode packets ...")
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      9a3fb9fb
  3. 27 2月, 2018 1 次提交
  4. 05 1月, 2018 1 次提交
  5. 19 12月, 2017 1 次提交
  6. 01 12月, 2017 2 次提交
  7. 02 11月, 2017 2 次提交
    • F
      xfrm: defer daddr pointer assignment after spi parsing · cb79a180
      Florian Westphal 提交于
      syzbot reports:
      BUG: KASAN: use-after-free in __xfrm_state_lookup+0x695/0x6b0
      Read of size 4 at addr ffff8801d434e538 by task syzkaller647520/2991
      [..]
      __xfrm_state_lookup+0x695/0x6b0 net/xfrm/xfrm_state.c:833
      xfrm_state_lookup+0x8a/0x160 net/xfrm/xfrm_state.c:1592
      xfrm_input+0x8e5/0x22f0 net/xfrm/xfrm_input.c:302
      
      The use-after-free is the ipv4 destination address, which points
      to an skb head area that has been reallocated:
        pskb_expand_head+0x36b/0x1210 net/core/skbuff.c:1494
        __pskb_pull_tail+0x14a/0x17c0 net/core/skbuff.c:1877
        pskb_may_pull include/linux/skbuff.h:2102 [inline]
        xfrm_parse_spi+0x3d3/0x4d0 net/xfrm/xfrm_input.c:170
        xfrm_input+0xce2/0x22f0 net/xfrm/xfrm_input.c:291
      
      so the real bug is that xfrm_parse_spi() uses pskb_may_pull, but
      for now do smaller workaround that makes xfrm_input fetch daddr
      after spi parsing.
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      cb79a180
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  8. 13 9月, 2017 1 次提交
    • A
      vti: fix NULL dereference in xfrm_input() · 23e9fcfe
      Alexey Kodanev 提交于
      Can be reproduced with LTP tests:
        # icmp-uni-vti.sh -p ah -a sha256 -m tunnel -S fffffffe -k 1 -s 10
      
      IPv4:
        RIP: 0010:xfrm_input+0x7f9/0x870
        ...
        Call Trace:
        <IRQ>
        vti_input+0xaa/0x110 [ip_vti]
        ? skb_free_head+0x21/0x40
        vti_rcv+0x33/0x40 [ip_vti]
        xfrm4_ah_rcv+0x33/0x60
        ip_local_deliver_finish+0x94/0x1e0
        ip_local_deliver+0x6f/0xe0
        ? ip_route_input_noref+0x28/0x50
        ...
      
        # icmp-uni-vti.sh -6 -p ah -a sha256 -m tunnel -S fffffffe -k 1 -s 10
      IPv6:
        RIP: 0010:xfrm_input+0x7f9/0x870
        ...
        Call Trace:
        <IRQ>
        xfrm6_rcv_tnl+0x3c/0x40
        vti6_rcv+0xd5/0xe0 [ip6_vti]
        xfrm6_ah_rcv+0x33/0x60
        ip6_input_finish+0xee/0x460
        ip6_input+0x3f/0xb0
        ip6_rcv_finish+0x45/0xa0
        ipv6_rcv+0x34b/0x540
      
      xfrm_input() invokes xfrm_rcv_cb() -> vti_rcv_cb(), the last callback
      might call skb_scrub_packet(), which in turn can reset secpath.
      
      Fix it by adding a check that skb->sp is not NULL.
      
      Fixes: 7e9e9202 ("xfrm: Clear RX SKB secpath xfrm_offload")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      23e9fcfe
  9. 31 8月, 2017 1 次提交
  10. 02 8月, 2017 1 次提交
    • I
      xfrm: Clear RX SKB secpath xfrm_offload · 7e9e9202
      Ilan Tayari 提交于
      If an incoming packet undergoes XFRM crypto-offload, its secpath is
      filled with xfrm_offload struct denoting offload information.
      
      If the SKB is then forwarded to a device which supports crypto-
      offload, the stack wrongfully attempts to offload it (even though
      the output SA may not exist on the device) due to the leftover
      secpath xo.
      
      Clear the ingress xo by zeroizing secpath->olen just before
      delivering the decapsulated packet to the network stack.
      
      Fixes: d77e38e6 ("xfrm: Add an IPsec hardware offloading API")
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      7e9e9202
  11. 05 7月, 2017 1 次提交
  12. 27 4月, 2017 1 次提交
  13. 14 4月, 2017 2 次提交
  14. 15 2月, 2017 4 次提交
  15. 09 2月, 2017 1 次提交
  16. 30 1月, 2017 1 次提交
  17. 11 8月, 2016 1 次提交
    • A
      net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key · 1625f452
      Alexey Kodanev 提交于
      Running LTP 'icmp-uni-basic.sh -6 -p ipcomp -m tunnel' test over
      openvswitch + veth can trigger kernel panic:
      
        BUG: unable to handle kernel NULL pointer dereference
        at 00000000000000e0 IP: [<ffffffff8169d1d2>] xfrm_input+0x82/0x750
        ...
        [<ffffffff816d472e>] xfrm6_rcv_spi+0x1e/0x20
        [<ffffffffa082c3c2>] xfrm6_tunnel_rcv+0x42/0x50 [xfrm6_tunnel]
        [<ffffffffa082727e>] tunnel6_rcv+0x3e/0x8c [tunnel6]
        [<ffffffff8169f365>] ip6_input_finish+0xd5/0x430
        [<ffffffff8169fc53>] ip6_input+0x33/0x90
        [<ffffffff8169f1d5>] ip6_rcv_finish+0xa5/0xb0
        ...
      
      It seems that tunnel.ip6 can have garbage values and also dereferenced
      without a proper check, only tunnel.ip4 is being verified. Fix it by
      adding one more if block for AF_INET6 and initialize tunnel.ip6 with NULL
      inside xfrm6_rcv_spi() (which is similar to xfrm4_rcv_spi()).
      
      Fixes: 049f8e2e ("xfrm: Override skb->mark with tunnel->parm.i_key in xfrm_input")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      1625f452
  18. 25 3月, 2016 1 次提交
    • S
      xfrm: Fix crash observed during device unregistration and decryption · 071d36bf
      subashab@codeaurora.org 提交于
      A crash is observed when a decrypted packet is processed in receive
      path. get_rps_cpus() tries to dereference the skb->dev fields but it
      appears that the device is freed from the poison pattern.
      
      [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
      [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
      [<ffffffc000af6094>] netif_rx+0x74/0x94
      [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
      [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
      [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
      [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
      [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
      [<ffffffc0000bb40c>] kthread+0xe0/0xec
      
      -013|get_rps_cpu(
           |    dev = 0xFFFFFFC08B688000,
           |    skb = 0xFFFFFFC0C76AAC00 -> (
           |      dev = 0xFFFFFFC08B688000 -> (
           |        name =
      "......................................................
           |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
      0xAAAAAAAAAAA
      
      Following are the sequence of events observed -
      
      - Encrypted packet in receive path from netdevice is queued
      - Encrypted packet queued for decryption (asynchronous)
      - Netdevice brought down and freed
      - Packet is decrypted and returned through callback in esp_input_done
      - Packet is queued again for process in network stack using netif_rx
      
      Since the device appears to have been freed, the dereference of
      skb->dev in get_rps_cpus() leads to an unhandled page fault
      exception.
      
      Fix this by holding on to device reference when queueing packets
      asynchronously and releasing the reference on call back return.
      
      v2: Make the change generic to xfrm as mentioned by Steffen and
      update the title to xfrm
      Suggested-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NJerome Stanislaus <jeromes@codeaurora.org>
      Signed-off-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      071d36bf
  19. 23 10月, 2015 1 次提交
  20. 28 5月, 2015 1 次提交
  21. 24 4月, 2015 1 次提交
  22. 23 4月, 2015 1 次提交
  23. 07 4月, 2015 1 次提交
    • A
      xfrm: fix xfrm_input/xfrm_tunnel_check oops · 68c11e98
      Alexey Dobriyan 提交于
      https://bugzilla.kernel.org/show_bug.cgi?id=95211
      
      Commit 70be6c91
      ("xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer") added check
      which dereferences ->outer_mode too early but larval SAs don't have
      this pointer set (yet). So check for tunnel stuff later.
      
      Mike Noordermeer reported this bug and patiently applied all the debugging.
      
      Technically this is remote-oops-in-interrupt-context type of thing.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
      IP: [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      	...
      [<ffffffff81500fc6>] ? xfrm4_esp_rcv+0x36/0x70
      [<ffffffff814acc9a>] ? ip_local_deliver_finish+0x9a/0x200
      [<ffffffff81471b83>] ? __netif_receive_skb_core+0x6f3/0x8f0
      	...
      
      RIP  [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      68c11e98
  24. 14 3月, 2014 1 次提交
  25. 25 2月, 2014 2 次提交
  26. 02 1月, 2014 1 次提交
  27. 06 6月, 2013 1 次提交
    • F
      xfrm: add LINUX_MIB_XFRMACQUIREERROR statistic counter · 4c4d41f2
      Fan Du 提交于
      When host ping its peer, ICMP echo request packet triggers IPsec
      policy, then host negotiates SA secret with its peer. After IKE
      installed SA for OUT direction, but before SA for IN direction
      installed, host get ICMP echo reply from its peer. At the time
      being, the SA state for IN direction could be XFRM_STATE_ACQ,
      then the received packet will be dropped after adding
      LINUX_MIB_XFRMINSTATEINVALID statistic.
      
      Adding a LINUX_MIB_XFRMACQUIREERROR statistic counter for such
      scenario when SA in larval state is much clearer for user than
      LINUX_MIB_XFRMINSTATEINVALID which indicates the SA is totally
      bad.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4c4d41f2
  28. 05 9月, 2012 1 次提交
  29. 22 9月, 2011 1 次提交
  30. 29 3月, 2011 1 次提交
  31. 28 3月, 2011 1 次提交
  32. 14 3月, 2011 1 次提交