1. 10 Dec, 2022 7 commits
    • Kees Cook's avatar
      skbuff: Introduce slab_build_skb() · ce098da1
      Kees Cook authored
      syzkaller reported:
      
        BUG: KASAN: slab-out-of-bounds in __build_skb_around+0x235/0x340 net/core/skbuff.c:294
        Write of size 32 at addr ffff88802aa172c0 by task syz-executor413/5295
      
      For bpf_prog_test_run_skb(), which uses a kmalloc()ed buffer passed to
      build_skb().
      
      When build_skb() is passed a frag_size of 0, it means the buffer came
      from kmalloc. In these cases, ksize() is used to find its actual size,
      but since the allocation may not have been made to that size, actually
      perform the krealloc() call so that all the associated buffer size
      checking will be correctly notified (and use the "new" pointer so that
      compiler hinting works correctly). Split this logic out into a new
      interface, slab_build_skb(), but leave the original 0 checking for now
      to catch any stragglers.
      
      Reported-by: syzbot+fda18eaa8c12534ccb3b@syzkaller.appspotmail.com
      Link: https://groups.google.com/g/syzkaller-bugs/c/UnIKxTtU5-0/m/-wbXinkgAQAJ
      Fixes: 38931d89 ("mm: Make ksize() a reporting-only function")
      Cc: Pavel Begunkov <asml.silence@gmail.com>
      Cc: pepsipu <soopthegoop@gmail.com>
      Cc: syzbot+fda18eaa8c12534ccb3b@syzkaller.appspotmail.com
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: kasan-dev <kasan-dev@googlegroups.com>
      Cc: Andrii Nakryiko <andrii@kernel.org>
      Cc: ast@kernel.org
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Hao Luo <haoluo@google.com>
      Cc: Jesper Dangaard Brouer <hawk@kernel.org>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: jolsa@kernel.org
      Cc: KP Singh <kpsingh@kernel.org>
      Cc: martin.lau@linux.dev
      Cc: Stanislav Fomichev <sdf@google.com>
      Cc: song@kernel.org
      Cc: Yonghong Song <yhs@fb.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20221208060256.give.994-kees@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ce098da1
    • Jiapeng Chong's avatar
      net: bcmgenet: Remove the unused function · 28d39503
      Jiapeng Chong authored
      The function dmadesc_get_addr() is defined in the bcmgenet.c file, but
      not called elsewhere, so remove this unused function.
      
      drivers/net/ethernet/broadcom/genet/bcmgenet.c:120:26: warning: unused function 'dmadesc_get_addr'.
      
      Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3401Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarJiapeng Chong <jiapeng.chong@linux.alibaba.com>
      Link: https://lore.kernel.org/r/20221209033723.32452-1-jiapeng.chong@linux.alibaba.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      28d39503
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-miscellaneous-cleanup' · 2b53d869
      Jakub Kicinski authored
      Mat Martineau says:
      
      ====================
      mptcp: Miscellaneous cleanup
      
      Two code cleanup patches for the 6.2 merge window that don't change
      behavior:
      
      Patch 1 makes proper use of nlmsg_free(), as suggested by Jakub while
      reviewing f8c9dfbd ("mptcp: add pm listener events").
      
      Patch 2 clarifies success status in a few mptcp functions, which
      prevents some smatch false positives.
      ====================
      
      Link: https://lore.kernel.org/r/20221209004431.143701-1-mathew.j.martineau@linux.intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2b53d869
    • Matthieu Baerts's avatar
      mptcp: return 0 instead of 'err' var · 03e7d28c
      Matthieu Baerts authored
      When 'err' is 0, it looks clearer to return '0' instead of the variable
      called 'err'.
      
      The behaviour is then not modified, just a clearer code.
      
      By doing this, we can also avoid false positive smatch warnings like
      this one:
      
        net/mptcp/pm_netlink.c:1169 mptcp_pm_parse_pm_addr_attr() warn: missing error code? 'err'
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <error27@gmail.com>
      Suggested-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      03e7d28c
    • Geliang Tang's avatar
      mptcp: use nlmsg_free instead of kfree_skb · 8b34b52c
      Geliang Tang authored
      Use nlmsg_free() instead of kfree_skb() in pm_netlink.c.
      
      The SKB's have been created by nlmsg_new(). The proper cleaning way
      should then be done with nlmsg_free().
      
      For the moment, nlmsg_free() is simply calling kfree_skb() so we don't
      change the behaviour here.
      Suggested-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8b34b52c
    • Jakub Kicinski's avatar
      Merge tag 'mlx5-updates-2022-12-08' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · c80edd8d
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2022-12-08
      
      1) Support range match action in SW steering
      
      Yevgeny Kliteynik says:
      =======================
      
      The following patch series adds support for a range match action in
      SW Steering.
      
      SW steering is able to match only on the exact values of the packet fields,
      as requested by the user: the user provides mask for the fields that are of
      interest, and the exact values to be matched on when the traffic is handled.
      
      The following patch series add new type of action - Range Match, where the
      user provides a field to be matched on and a range of values (min to max)
      that will be considered as hit.
      
      There are several new notions that were implemented in order to support
      Range Match:
       - MATCH_RANGES Steering Table Entry (STE): the new STE type that allows
         matching the packets' fields on the range of values instead of a specific
         value.
       - Match Definer: this is a general FW object that defines which fields
         in the packet will be referenced by the mask and tag of each STE.
         Match definer ID is part of STE fields, and it defines how the HW needs
         to interpret the STE's mask/tag values.
         Till now SW steering used the definers that were managed by FW and
         implemented the STE layout as described by the HW spec.
         Now that we're adding a new type of STE, SW steering needs to also be
         able to define this new STE's layout, and this is do
      
      =======================
      
      2) From OZ add support for meter mtu offload
         2.1: Refactor the code to allow both metering and range post actions as a
              pre-step for adding police mtu offload support.
         2.2: Instantiate mtu green/red flow tables with a single match-all rule.
              Add the green/red actions to the hit/miss table accordingly
         2.3: Initialize the meter object with the TC police mtu parameter.
              Use the hardware range match action feature.
      
      3) From MaorD, support routes with more than 2 nexthops in multipath
      
      4) Michael and Or, improve and extend vport representor counters.
      
      * tag 'mlx5-updates-2022-12-08' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
        net/mlx5: Expose steering dropped packets counter
        net/mlx5: Refactor and expand rep vport stat group
        net/mlx5e: multipath, support routes with more than 2 nexthops
        net/mlx5e: TC, add support for meter mtu offload
        net/mlx5e: meter, add mtu post meter tables
        net/mlx5e: meter, refactor to allow multiple post meter tables
        net/mlx5: DR, Add support for range match action
        net/mlx5: DR, Add function that tells if STE miss addr has been initialized
        net/mlx5: DR, Some refactoring of miss address handling
        net/mlx5: DR, Manage definers with refcounts
        net/mlx5: DR, Handle FT action in a separate function
        net/mlx5: DR, Rework is_fw_table function
        net/mlx5: DR, Add functions to create/destroy MATCH_DEFINER general object
        net/mlx5: fs, add match on ranges API
        net/mlx5: mlx5_ifc updates for MATCH_DEFINER general object
      ====================
      
      Link: https://lore.kernel.org/r/20221209001420.142794-1-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c80edd8d
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · 043cd1e2
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2022-12-08 (ice)
      
      Jacob Keller says:
      
      This series of patches primarily consists of changes to fix some corner
      cases that can cause Tx timestamp failures. The issues were discovered and
      reported by Siddaraju DH and primarily affect E822 hardware, though this
      series also includes some improvements that affect E810 hardware as well.
      
      The primary issue is regarding the way that E822 determines when to generate
      timestamp interrupts. If the driver reads timestamp indexes which do not
      have a valid timestamp, the E822 interrupt tracking logic can get stuck.
      This is due to the way that E822 hardware tracks timestamp index reads
      internally. I was previously unaware of this behavior as it is significantly
      different in E810 hardware.
      
      Most of the fixes target refactors to ensure that the ice driver does not
      read timestamp indexes which are not valid on E822 hardware. This is done by
      using the Tx timestamp ready bitmap register from the PHY. This register
      indicates what timestamp indexes have outstanding timestamps waiting to be
      captured.
      
      Care must be taken in all cases where we read the timestamp registers, and
      thus all flows which might have read these registers are refactored. The
      ice_ptp_tx_tstamp function is modified to consolidate as much of the logic
      relating to these registers as possible. It now handles discarding stale
      timestamps which are old or which occurred after a PHC time update. This
      replaces previously standalone thread functions like the periodic work
      function and the ice_ptp_flush_tx_tracker function.
      
      In addition, some minor cleanups noticed while writing these refactors are
      included.
      
      The remaining patches refactor the E822 implementation to remove the
      "bypass" mode for timestamps. The E822 hardware has the ability to provide a
      more precise timestamp by making use of measurements of the precise way that
      packets flow through the hardware pipeline. These measurements are known as
      "Vernier" calibration. The "bypass" mode disables many of these measurements
      in favor of a faster start up time for Tx and Rx timestamping. Instead, once
      these measurements were captured, the driver tries to reconfigure the PHY to
      enable the vernier calibrations.
      
      Unfortunately this recalibration does not work. Testing indicates that the
      PHY simply remains in bypass mode without the increased timestamp precision.
      Remove the attempt at recalibration and always use vernier mode. This has
      one disadvantage that Tx and Rx timestamps cannot begin until after at least
      one packet of that type goes through the hardware pipeline. Because of this,
      further refactor the driver to separate Tx and Rx vernier calibration.
      Complete the Tx and Rx independently, enabling the appropriate type of
      timestamp as soon as the relevant packet has traversed the hardware
      pipeline. This was reported by Milena Olech.
      
      Note that although these might be considered "bug fixes", the required
      changes in order to appropriately resolve these issues is large. Thus it
      does not feel suitable to send this series to net.
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
        ice: reschedule ice_ptp_wait_for_offset_valid during reset
        ice: make Tx and Rx vernier offset calibration independent
        ice: only check set bits in ice_ptp_flush_tx_tracker
        ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
        ice: cleanup allocations in ice_ptp_alloc_tx_tracker
        ice: protect init and calibrating check in ice_ptp_request_ts
        ice: synchronize the misc IRQ when tearing down Tx tracker
        ice: check Tx timestamp memory register for ready timestamps
        ice: handle discarding old Tx requests in ice_ptp_tx_tstamp
        ice: always call ice_ptp_link_change and make it void
        ice: fix misuse of "link err" with "link status"
        ice: Reset TS memory for all quads
        ice: Remove the E822 vernier "bypass" logic
        ice: Use more generic names for ice_ptp_tx fields
      ====================
      
      Link: https://lore.kernel.org/r/20221208213932.1274143-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      043cd1e2
  2. 09 Dec, 2022 33 commits