1. 10 Aug, 2022 8 commits
    • Matthias May's avatar
      ipv6: do not use RT_TOS for IPv6 flowlabel · ab7e2e0d
      Matthias May authored
      According to Guillaume Nault RT_TOS should never be used for IPv6.
      
      Quote:
      RT_TOS() is an old macro used to interprete IPv4 TOS as described in
      the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
      code, although, given the current state of the code, most of the
      existing calls have no consequence.
      
      But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
      field to be interpreted the RFC 1349 way. There's no historical
      compatibility to worry about.
      
      Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarMatthias May <matthias.may@westermo.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ab7e2e0d
    • Matthias May's avatar
      mlx5: do not use RT_TOS for IPv6 flowlabel · bcb0da7f
      Matthias May authored
      According to Guillaume Nault RT_TOS should never be used for IPv6.
      
      Quote:
      RT_TOS() is an old macro used to interprete IPv4 TOS as described in
      the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
      code, although, given the current state of the code, most of the
      existing calls have no consequence.
      
      But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
      field to be interpreted the RFC 1349 way. There's no historical
      compatibility to worry about.
      
      Fixes: ce99f6b9 ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels")
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarMatthias May <matthias.may@westermo.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bcb0da7f
    • Matthias May's avatar
      vxlan: do not use RT_TOS for IPv6 flowlabel · e488d4f5
      Matthias May authored
      According to Guillaume Nault RT_TOS should never be used for IPv6.
      
      Quote:
      RT_TOS() is an old macro used to interprete IPv4 TOS as described in
      the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
      code, although, given the current state of the code, most of the
      existing calls have no consequence.
      
      But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
      field to be interpreted the RFC 1349 way. There's no historical
      compatibility to worry about.
      
      Fixes: 1400615d ("vxlan: allow setting ipv6 traffic class")
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarMatthias May <matthias.may@westermo.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e488d4f5
    • Matthias May's avatar
      geneve: do not use RT_TOS for IPv6 flowlabel · ca2bb695
      Matthias May authored
      According to Guillaume Nault RT_TOS should never be used for IPv6.
      
      Quote:
      RT_TOS() is an old macro used to interprete IPv4 TOS as described in
      the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
      code, although, given the current state of the code, most of the
      existing calls have no consequence.
      
      But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
      field to be interpreted the RFC 1349 way. There's no historical
      compatibility to worry about.
      
      Fixes: 3a56f86f ("geneve: handle ipv6 priority like ipv4 tos")
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarMatthias May <matthias.may@westermo.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ca2bb695
    • Matthias May's avatar
      geneve: fix TOS inheriting for ipv4 · b4ab94d6
      Matthias May authored
      The current code retrieves the TOS field after the lookup
      on the ipv4 routing table. The routing process currently
      only allows routing based on the original 3 TOS bits, and
      not on the full 6 DSCP bits.
      As a result the retrieved TOS is cut to the 3 bits.
      However for inheriting purposes the full 6 bits should be used.
      
      Extract the full 6 bits before the route lookup and use
      that instead of the cut off 3 TOS bits.
      
      Fixes: e305ac6c ("geneve: Add support to collect tunnel metadata.")
      Signed-off-by: default avatarMatthias May <matthias.may@westermo.com>
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Link: https://lore.kernel.org/r/20220805190006.8078-1-matthias.may@westermo.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b4ab94d6
    • Chia-Lin Kao (AceLan)'s avatar
      net: atlantic: fix aq_vec index out of range error · 2ba5e47f
      Chia-Lin Kao (AceLan) authored
      The final update statement of the for loop exceeds the array range, the
      dereference of self->aq_vec[i] is not checked and then leads to the
      index out of range error.
      Also fixed this kind of coding style in other for loop.
      
      [   97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
      [   97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
      [   97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
      [   97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
      [   97.937611] Workqueue: events_unbound async_run_entry_fn
      [   97.937616] Call Trace:
      [   97.937617]  <TASK>
      [   97.937619]  dump_stack_lvl+0x49/0x63
      [   97.937624]  dump_stack+0x10/0x16
      [   97.937626]  ubsan_epilogue+0x9/0x3f
      [   97.937627]  __ubsan_handle_out_of_bounds.cold+0x44/0x49
      [   97.937629]  ? __scm_send+0x348/0x440
      [   97.937632]  ? aq_vec_stop+0x72/0x80 [atlantic]
      [   97.937639]  aq_nic_stop+0x1b6/0x1c0 [atlantic]
      [   97.937644]  aq_suspend_common+0x88/0x90 [atlantic]
      [   97.937648]  aq_pm_suspend_poweroff+0xe/0x20 [atlantic]
      [   97.937653]  pci_pm_suspend+0x7e/0x1a0
      [   97.937655]  ? pci_pm_suspend_noirq+0x2b0/0x2b0
      [   97.937657]  dpm_run_callback+0x54/0x190
      [   97.937660]  __device_suspend+0x14c/0x4d0
      [   97.937661]  async_suspend+0x23/0x70
      [   97.937663]  async_run_entry_fn+0x33/0x120
      [   97.937664]  process_one_work+0x21f/0x3f0
      [   97.937666]  worker_thread+0x4a/0x3c0
      [   97.937668]  ? process_one_work+0x3f0/0x3f0
      [   97.937669]  kthread+0xf0/0x120
      [   97.937671]  ? kthread_complete_and_exit+0x20/0x20
      [   97.937672]  ret_from_fork+0x22/0x30
      [   97.937676]  </TASK>
      
      v2. fixed "warning: variable 'aq_vec' set but not used"
      
      v3. simplified a for loop
      
      Fixes: 97bde5c4 ("net: ethernet: aquantia: Support for NIC-specific code")
      Signed-off-by: default avatarChia-Lin Kao (AceLan) <acelan.kao@canonical.com>
      Acked-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
      Link: https://lore.kernel.org/r/20220808081845.42005-1-acelan.kao@canonical.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2ba5e47f
    • Christophe JAILLET's avatar
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · 690bf643
      Jakub Kicinski authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Harden set element field checks to avoid out-of-bound memory access,
         this patch also fixes the type of issue described in 7e6bc1f6
         ("netfilter: nf_tables: stricter validation of element data") in a
         broader way.
      
      2) Patches to restrict the chain, set, and rule id lookup in the
         transaction to the corresponding top-level table, patches from
         Thadeu Lima de Souza Cascardo.
      
      3) Fix incorrect comment in ip6t_LOG.h
      
      4) nft_data_init() performs upfront validation of the expected data.
         struct nft_data_desc is used to describe the expected data to be
         received from userspace. The .size field represents the maximum size
         that can be stored, for bound checks. Then, .len is an input/output field
         which stores the expected length as input (this is optional, to restrict
         the checks), as output it stores the real length received from userspace
         (if it was not specified as input). This patch comes in response to
         7e6bc1f6 ("netfilter: nf_tables: stricter validation of element data")
         to address this type of issue in a more generic way by avoid opencoded
         data validation. Next patch requires this as a dependency.
      
      5) Disallow jump to implicit chain from set element, this configuration
         is invalid. Only allow jump to chain via immediate expression is
         supported at this stage.
      
      6) Fix possible null-pointer derefence in the error path of table updates,
         if memory allocation of the transaction fails. From Florian Westphal.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
        netfilter: nf_tables: fix null deref due to zeroed list head
        netfilter: nf_tables: disallow jump to implicit chain from set element
        netfilter: nf_tables: upfront validation of data via nft_data_init()
        netfilter: ip6t_LOG: Fix a typo in a comment
        netfilter: nf_tables: do not allow RULE_ID to refer to another chain
        netfilter: nf_tables: do not allow CHAIN_ID to refer to another table
        netfilter: nf_tables: do not allow SET_ID to refer to another table
        netfilter: nf_tables: validate variable length element extension
      ====================
      
      Link: https://lore.kernel.org/r/20220809220532.130240-1-pablo@netfilter.org/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      690bf643
  2. 09 Aug, 2022 32 commits