1. 06 Mar, 2023 4 commits
    • Selvin Xavier's avatar
      bnxt_en: Fix the double free during device removal · 89b59a84
      Selvin Xavier authored
      Following warning reported by KASAN during driver unload
      
      ==================================================================
      BUG: KASAN: double-free in bnxt_remove_one+0x103/0x200 [bnxt_en]
      Free of addr ffff88814e8dd4c0 by task rmmod/17469
      CPU: 47 PID: 17469 Comm: rmmod Kdump: loaded Tainted: G S                 6.2.0-rc7+ #2
      Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.3.10 08/15/2019
      Call Trace:
       <TASK>
       dump_stack_lvl+0x33/0x46
       print_report+0x17b/0x4b3
       ? __call_rcu_common.constprop.79+0x27e/0x8c0
       ? __pfx_free_object_rcu+0x10/0x10
       ? __virt_addr_valid+0xe3/0x160
       ? bnxt_remove_one+0x103/0x200 [bnxt_en]
       kasan_report_invalid_free+0x64/0xd0
       ? bnxt_remove_one+0x103/0x200 [bnxt_en]
       ? bnxt_remove_one+0x103/0x200 [bnxt_en]
       __kasan_slab_free+0x179/0x1c0
       ? bnxt_remove_one+0x103/0x200 [bnxt_en]
       __kmem_cache_free+0x194/0x350
       bnxt_remove_one+0x103/0x200 [bnxt_en]
       pci_device_remove+0x62/0x110
       device_release_driver_internal+0xf6/0x1c0
       driver_detach+0x76/0xe0
       bus_remove_driver+0x89/0x160
       pci_unregister_driver+0x26/0x110
       ? strncpy_from_user+0x188/0x1c0
       bnxt_exit+0xc/0x24 [bnxt_en]
       __x64_sys_delete_module+0x21f/0x390
       ? __pfx___x64_sys_delete_module+0x10/0x10
       ? __pfx_mem_cgroup_handle_over_high+0x10/0x10
       ? _raw_spin_lock+0x87/0xe0
       ? __pfx__raw_spin_lock+0x10/0x10
       ? __audit_syscall_entry+0x185/0x210
       ? ktime_get_coarse_real_ts64+0x51/0x80
       ? syscall_trace_enter.isra.18+0x126/0x1a0
       do_syscall_64+0x37/0x90
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      RIP: 0033:0x7effcb6fd71b
      Code: 73 01 c3 48 8b 0d 6d 17 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 17 2c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffeada270b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 00005623660e0750 RCX: 00007effcb6fd71b
      RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005623660e07b8
      RBP: 0000000000000000 R08: 00007ffeada26031 R09: 0000000000000000
      R10: 00007effcb771280 R11: 0000000000000206 R12: 00007ffeada272e0
      R13: 00007ffeada28bc4 R14: 00005623660e02a0 R15: 00005623660e0750
       </TASK>
      
      Auxiliary device structures are freed in bnxt_aux_dev_release. So avoid
      calling kfree from bnxt_remove_one.
      
      Also, set bp->edev to NULL before freeing the auxilary private structure.
      
      Fixes: d80d88b0 ("bnxt_en: Add auxiliary driver support")
      Reviewed-by: default avatarAjit Khaparde <ajit.khaparde@broadcom.com>
      Reviewed-by: default avatarAndy Gospodarek <andrew.gospodarek@broadcom.com>
      Signed-off-by: default avatarSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89b59a84
    • Michael Chan's avatar
      bnxt_en: Avoid order-5 memory allocation for TPA data · accd7e23
      Michael Chan authored
      The driver needs to keep track of all the possible concurrent TPA (GRO/LRO)
      completions on the aggregation ring.  On P5 chips, the maximum number
      of concurrent TPA is 256 and the amount of memory we allocate is order-5
      on systems using 4K pages.  Memory allocation failure has been reported:
      
      NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1
      CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1
      Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022
      Call Trace:
       dump_stack+0x57/0x6e
       warn_alloc.cold.120+0x7b/0xdd
       ? _cond_resched+0x15/0x30
       ? __alloc_pages_direct_compact+0x15f/0x170
       __alloc_pages_slowpath.constprop.108+0xc58/0xc70
       __alloc_pages_nodemask+0x2d0/0x300
       kmalloc_order+0x24/0xe0
       kmalloc_order_trace+0x19/0x80
       bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en]
       ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en]
       __bnxt_open_nic+0x12e/0x780 [bnxt_en]
       bnxt_open+0x10b/0x240 [bnxt_en]
       __dev_open+0xe9/0x180
       __dev_change_flags+0x1af/0x220
       dev_change_flags+0x21/0x60
       do_setlink+0x35c/0x1100
      
      Instead of allocating this big chunk of memory and dividing it up for the
      concurrent TPA instances, allocate each small chunk separately for each
      TPA instance.  This will reduce it to order-0 allocations.
      
      Fixes: 79632e9b ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.")
      Reviewed-by: default avatarSomnath Kotur <somnath.kotur@broadcom.com>
      Reviewed-by: default avatarDamodharam Ammepalli <damodharam.ammepalli@broadcom.com>
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      accd7e23
    • Russell King (Oracle)'s avatar
      net: phylib: get rid of unnecessary locking · f4b47a2e
      Russell King (Oracle) authored
      The locking in phy_probe() and phy_remove() does very little to prevent
      any races with e.g. phy_attach_direct(), but instead causes lockdep ABBA
      warnings. Remove it.
      
      ======================================================
      WARNING: possible circular locking dependency detected
      6.2.0-dirty #1108 Tainted: G        W   E
      ------------------------------------------------------
      ip/415 is trying to acquire lock:
      ffff5c268f81ef50 (&dev->lock){+.+.}-{3:3}, at: phy_attach_direct+0x17c/0x3a0 [libphy]
      
      but task is already holding lock:
      ffffaef6496cb518 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x154/0x560
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (rtnl_mutex){+.+.}-{3:3}:
             __lock_acquire+0x35c/0x6c0
             lock_acquire.part.0+0xcc/0x220
             lock_acquire+0x68/0x84
             __mutex_lock+0x8c/0x414
             mutex_lock_nested+0x34/0x40
             rtnl_lock+0x24/0x30
             sfp_bus_add_upstream+0x34/0x150
             phy_sfp_probe+0x4c/0x94 [libphy]
             mv3310_probe+0x148/0x184 [marvell10g]
             phy_probe+0x8c/0x200 [libphy]
             call_driver_probe+0xbc/0x15c
             really_probe+0xc0/0x320
             __driver_probe_device+0x84/0x120
             driver_probe_device+0x44/0x120
             __device_attach_driver+0xc4/0x160
             bus_for_each_drv+0x80/0xe0
             __device_attach+0xb0/0x1f0
             device_initial_probe+0x1c/0x2c
             bus_probe_device+0xa4/0xb0
             device_add+0x360/0x53c
             phy_device_register+0x60/0xa4 [libphy]
             fwnode_mdiobus_phy_device_register+0xc0/0x190 [fwnode_mdio]
             fwnode_mdiobus_register_phy+0x160/0xd80 [fwnode_mdio]
             of_mdiobus_register+0x140/0x340 [of_mdio]
             orion_mdio_probe+0x298/0x3c0 [mvmdio]
             platform_probe+0x70/0xe0
             call_driver_probe+0x34/0x15c
             really_probe+0xc0/0x320
             __driver_probe_device+0x84/0x120
             driver_probe_device+0x44/0x120
             __driver_attach+0x104/0x210
             bus_for_each_dev+0x78/0xdc
             driver_attach+0x2c/0x3c
             bus_add_driver+0x184/0x240
             driver_register+0x80/0x13c
             __platform_driver_register+0x30/0x3c
             xt_compat_calc_jump+0x28/0xa4 [x_tables]
             do_one_initcall+0x50/0x1b0
             do_init_module+0x50/0x1fc
             load_module+0x684/0x744
             __do_sys_finit_module+0xc4/0x140
             __arm64_sys_finit_module+0x28/0x34
             invoke_syscall+0x50/0x120
             el0_svc_common.constprop.0+0x6c/0x1b0
             do_el0_svc+0x34/0x44
             el0_svc+0x48/0xf0
             el0t_64_sync_handler+0xb8/0xc0
             el0t_64_sync+0x1a0/0x1a4
      
      -> #0 (&dev->lock){+.+.}-{3:3}:
             check_prev_add+0xb4/0xc80
             validate_chain+0x414/0x47c
             __lock_acquire+0x35c/0x6c0
             lock_acquire.part.0+0xcc/0x220
             lock_acquire+0x68/0x84
             __mutex_lock+0x8c/0x414
             mutex_lock_nested+0x34/0x40
             phy_attach_direct+0x17c/0x3a0 [libphy]
             phylink_fwnode_phy_connect.part.0+0x70/0xe4 [phylink]
             phylink_fwnode_phy_connect+0x48/0x60 [phylink]
             mvpp2_open+0xec/0x2e0 [mvpp2]
             __dev_open+0x104/0x214
             __dev_change_flags+0x1d4/0x254
             dev_change_flags+0x2c/0x7c
             do_setlink+0x254/0xa50
             __rtnl_newlink+0x430/0x514
             rtnl_newlink+0x58/0x8c
             rtnetlink_rcv_msg+0x17c/0x560
             netlink_rcv_skb+0x64/0x150
             rtnetlink_rcv+0x20/0x30
             netlink_unicast+0x1d4/0x2b4
             netlink_sendmsg+0x1a4/0x400
             ____sys_sendmsg+0x228/0x290
             ___sys_sendmsg+0x88/0xec
             __sys_sendmsg+0x70/0xd0
             __arm64_sys_sendmsg+0x2c/0x40
             invoke_syscall+0x50/0x120
             el0_svc_common.constprop.0+0x6c/0x1b0
             do_el0_svc+0x34/0x44
             el0_svc+0x48/0xf0
             el0t_64_sync_handler+0xb8/0xc0
             el0t_64_sync+0x1a0/0x1a4
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(rtnl_mutex);
                                     lock(&dev->lock);
                                     lock(rtnl_mutex);
        lock(&dev->lock);
      
       *** DEADLOCK ***
      
      Fixes: 298e54fa ("net: phy: add core phylib sfp support")
      Reported-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4b47a2e
    • Rongguang Wei's avatar
      net: stmmac: add to set device wake up flag when stmmac init phy · a9334b70
      Rongguang Wei authored
      When MAC is not support PMT, driver will check PHY's WoL capability
      and set device wakeup capability in stmmac_init_phy(). We can enable
      the WoL through ethtool, the driver would enable the device wake up
      flag. Now the device_may_wakeup() return true.
      
      But if there is a way which enable the PHY's WoL capability derectly,
      like in BIOS. The driver would not know the enable thing and would not
      set the device wake up flag. The phy_suspend may failed like this:
      
      [   32.409063] PM: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x50 returns -16
      [   32.409065] PM: Device stmmac-1:00 failed to suspend: error -16
      [   32.409067] PM: Some devices failed to suspend, or early wake event detected
      
      Add to set the device wakeup enable flag according to the get_wol
      function result in PHY can fix the error in this scene.
      
      v2: add a Fixes tag.
      
      Fixes: 1d8e5b0f ("net: stmmac: Support WOL with phy")
      Signed-off-by: default avatarRongguang Wei <weirongguang@kylinos.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9334b70
  2. 03 Mar, 2023 12 commits
    • David S. Miller's avatar
      Merge branch 'nfp-ipsec-csum' · 52812526
      David S. Miller authored
      Simon Horman says:
      
      ====================
      nfp: fix incorrect IPsec checksum handling
      
      this short series resolves two problems with IPsec checksum handling
      in the nfp driver.
      
      * PATCH 1/3, 2/3: Correct setting of checksum flags.
        One patch for each of the nfd3 and nfdk datapaths.
      
      * Patch 3/3: Correct configuration of NETIF_F_CSUM_MASK
        so that the stack does not unecessarily calculate csums for
        IPsec offload packets.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52812526
    • Huanhuan Wang's avatar
      nfp: fix esp-tx-csum-offload doesn't take effect · 1cf78d4c
      Huanhuan Wang authored
      When esp-tx-csum-offload is set to on, the protocol stack shouldn't
      calculate the IPsec offload packet's csum, but it does. Because the
      callback `.ndo_features_check` incorrectly masked NETIF_F_CSUM_MASK bit.
      
      Fixes: 57f273ad ("nfp: add framework to support ipsec offloading")
      Signed-off-by: default avatarHuanhuan Wang <huanhuan.wang@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1cf78d4c
    • Huanhuan Wang's avatar
      nfp: fix incorrectly set csum flag for nfdk path · 8b46168c
      Huanhuan Wang authored
      The csum flag of IPsec packet are set repeatedly. Therefore, the csum
      flag set of IPsec and non-IPsec packet need to be distinguished.
      
      As the ipv6 header does not have a csum field, so l3-csum flag is not
      required to be set for ipv6 case.
      
      Fixes: 436396f2 ("nfp: support IPsec offloading for NFP3800")
      Signed-off-by: default avatarHuanhuan Wang <huanhuan.wang@corigine.com>
      Reviewed-by: default avatarLouis Peens <louis.peens@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b46168c
    • Huanhuan Wang's avatar
      nfp: fix incorrectly set csum flag for nfd3 path · 3e04419c
      Huanhuan Wang authored
      The csum flag of IPsec packet are set repeatedly. Therefore, the csum
      flag set of IPsec and non-IPsec packet need to be distinguished.
      
      As the ipv6 header does not have a csum field, so l3-csum flag is not
      required to be set for ipv6 case.
      
      L4-csum flag include the tcp csum flag and udp csum flag, we shouldn't
      set the udp and tcp csum flag at the same time for one packet, should
      set l4-csum flag according to the transport layer is tcp or udp.
      
      Fixes: 57f273ad ("nfp: add framework to support ipsec offloading")
      Signed-off-by: default avatarHuanhuan Wang <huanhuan.wang@corigine.com>
      Reviewed-by: default avatarLouis Peens <louis.peens@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3e04419c
    • Petr Oros's avatar
      ice: copy last block omitted in ice_get_module_eeprom() · 84cba184
      Petr Oros authored
      ice_get_module_eeprom() is broken since commit e9c9692c ("ice:
      Reimplement module reads used by ethtool") In this refactor,
      ice_get_module_eeprom() reads the eeprom in blocks of size 8.
      But the condition that should protect the buffer overflow
      ignores the last block. The last block always contains zeros.
      
      Bug uncovered by ethtool upstream commit 9538f384b535
      ("netlink: eeprom: Defer page requests to individual parsers")
      After this commit, ethtool reads a block with length = 1;
      to read the SFF-8024 identifier value.
      
      unpatched driver:
      $ ethtool -m enp65s0f0np0 offset 0x90 length 8
      Offset          Values
      ------          ------
      0x0090:         00 00 00 00 00 00 00 00
      $ ethtool -m enp65s0f0np0 offset 0x90 length 12
      Offset          Values
      ------          ------
      0x0090:         00 00 01 a0 4d 65 6c 6c 00 00 00 00
      $
      
      $ ethtool -m enp65s0f0np0
      Offset          Values
      ------          ------
      0x0000:         11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0010:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0030:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0040:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0050:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0060:         00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00
      0x0070:         00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      patched driver:
      $ ethtool -m enp65s0f0np0 offset 0x90 length 8
      Offset          Values
      ------          ------
      0x0090:         00 00 01 a0 4d 65 6c 6c
      $ ethtool -m enp65s0f0np0 offset 0x90 length 12
      Offset          Values
      ------          ------
      0x0090:         00 00 01 a0 4d 65 6c 6c 61 6e 6f 78
      $ ethtool -m enp65s0f0np0
          Identifier                                : 0x11 (QSFP28)
          Extended identifier                       : 0x00
          Extended identifier description           : 1.5W max. Power consumption
          Extended identifier description           : No CDR in TX, No CDR in RX
          Extended identifier description           : High Power Class (> 3.5 W) not enabled
          Connector                                 : 0x23 (No separable connector)
          Transceiver codes                         : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          Transceiver type                          : 40G Ethernet: 40G Base-CR4
          Transceiver type                          : 25G Ethernet: 25G Base-CR CA-N
          Encoding                                  : 0x05 (64B/66B)
          BR, Nominal                               : 25500Mbps
          Rate identifier                           : 0x00
          Length (SMF,km)                           : 0km
          Length (OM3 50um)                         : 0m
          Length (OM2 50um)                         : 0m
          Length (OM1 62.5um)                       : 0m
          Length (Copper or Active cable)           : 1m
          Transmitter technology                    : 0xa0 (Copper cable unequalized)
          Attenuation at 2.5GHz                     : 4db
          Attenuation at 5.0GHz                     : 5db
          Attenuation at 7.0GHz                     : 7db
          Attenuation at 12.9GHz                    : 10db
          ........
          ....
      
      Fixes: e9c9692c ("ice: Reimplement module reads used by ethtool")
      Signed-off-by: default avatarPetr Oros <poros@redhat.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84cba184
    • David S. Miller's avatar
      Merge branch 'net-tools-ynl-fixes' · 8f632a0a
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      tools: ynl: fix subset use and change default value for attrs/ops
      
      Fix a problem in subsetting, which will become apparent when
      the devlink family comes after the merge window. Even tho none
      of the existing families need this, we don't want someone to
      get "inspired" by the current, incorrect code when using specs
      in other languages.
      
      Change the default value for the first attr/op. This is a slight
      behavior change so needs to go in now. The diffstat of the last
      patch should serve as the clearest justification there..
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f632a0a
    • Jakub Kicinski's avatar
      netlink: specs: update for codegen enumerating from 1 · bcec7171
      Jakub Kicinski authored
      Now that the codegen rules had been changed we can update
      the specs to reflect the new default.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcec7171
    • Jakub Kicinski's avatar
      tools: ynl: use 1 as the default for first entry in attrs/ops · ad4fafcd
      Jakub Kicinski authored
      Pretty much all families use value: 1 or reserve as unspec
      the first entry in attribute set and the first operation.
      Make this the default. Update documentation (the doc for
      values of operations just refers back to doc for attrs
      so updating only attrs).
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad4fafcd
    • Jakub Kicinski's avatar
      tools: ynl: fully inherit attrs in subsets · 7cf93538
      Jakub Kicinski authored
      To avoid having to repeat the entire definition of an attribute
      (including the value) use the Attr object from the original set.
      In fact this is already the documented expectation.
      
      Fixes: be5bea1c ("net: add basic C code generators for Netlink")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cf93538
    • Jakub Kicinski's avatar
      Merge tag 'ieee802154-for-net-2023-03-02' of... · ad93bab6
      Jakub Kicinski authored
      Merge tag 'ieee802154-for-net-2023-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan
      
      Stefan Schmidt says:
      
      ====================
      ieee802154 for net 2023-03-02
      
      Two small fixes this time.
      
      Alexander Aring fixed a potential negative array access in the ca8210
      driver.
      
      Miquel Raynal fixed a crash that could have been triggered through
      the extended netlink API for 802154. This only came in this merge window.
      Found by syzkaller.
      
      * tag 'ieee802154-for-net-2023-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan:
        ieee802154: Prevent user from crashing the host
        ca8210: fix mac_len negative array access
      ====================
      
      Link: https://lore.kernel.org/r/20230302153032.1312755-1-stefan@datenfreihafen.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ad93bab6
    • Shigeru Yoshida's avatar
      net: caif: Fix use-after-free in cfusbl_device_notify() · 9781e98a
      Shigeru Yoshida authored
      syzbot reported use-after-free in cfusbl_device_notify() [1].  This
      causes a stack trace like below:
      
      BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
      Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214
      
      CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff7 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313
       print_report mm/kasan/report.c:429 [inline]
       kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
       cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
       notifier_call_chain+0xb5/0x200 kernel/notifier.c:87
       call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945
       call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
       call_netdevice_notifiers net/core/dev.c:1997 [inline]
       netdev_wait_allrefs_any net/core/dev.c:10227 [inline]
       netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341
       default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334
       ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
       cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
       process_one_work+0x996/0x1610 kernel/workqueue.c:2289
       worker_thread+0x665/0x1080 kernel/workqueue.c:2436
       kthread+0x2e9/0x3a0 kernel/kthread.c:376
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
       </TASK>
      
      When unregistering a net device, unregister_netdevice_many_notify()
      sets the device's reg_state to NETREG_UNREGISTERING, calls notifiers
      with NETDEV_UNREGISTER, and adds the device to the todo list.
      
      Later on, devices in the todo list are processed by netdev_run_todo().
      netdev_run_todo() waits devices' reference count become 1 while
      rebdoadcasting NETDEV_UNREGISTER notification.
      
      When cfusbl_device_notify() is called with NETDEV_UNREGISTER multiple
      times, the parent device might be freed.  This could cause UAF.
      Processing NETDEV_UNREGISTER multiple times also causes inbalance of
      reference count for the module.
      
      This patch fixes the issue by accepting only first NETDEV_UNREGISTER
      notification.
      
      Fixes: 7ad65bf6 ("caif: Add support for CAIF over CDC NCM USB interface")
      CC: sjur.brandeland@stericsson.com <sjur.brandeland@stericsson.com>
      Reported-by: syzbot+b563d33852b893653a9e@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?id=c3bfd8e2450adab3bffe4d80821fbbced600407f [1]
      Signed-off-by: default avatarShigeru Yoshida <syoshida@redhat.com>
      Link: https://lore.kernel.org/r/20230301163913.391304-1-syoshida@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9781e98a
    • Yuiko Oshino's avatar
      net: lan78xx: fix accessing the LAN7800's internal phy specific registers from the MAC driver · e57cf363
      Yuiko Oshino authored
      Move the LAN7800 internal phy (phy ID  0x0007c132) specific register
      accesses to the phy driver (microchip.c).
      
      Fix the error reported by Enguerrand de Ribaucourt in December 2022,
      "Some operations during the cable switch workaround modify the register
      LAN88XX_INT_MASK of the PHY. However, this register is specific to the
      LAN8835 PHY. For instance, if a DP8322I PHY is connected to the LAN7801,
      that register (0x19), corresponds to the LED and MAC address
      configuration, resulting in unapropriate behavior."
      
      I did not test with the DP8322I PHY, but I tested with an EVB-LAN7800
      with the internal PHY.
      
      Fixes: 14437e3f ("lan78xx: workaround of forced 100 Full/Half duplex mode error")
      Signed-off-by: default avatarYuiko Oshino <yuiko.oshino@microchip.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20230301154307.30438-1-yuiko.oshino@microchip.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e57cf363
  3. 02 Mar, 2023 6 commits
  4. 01 Mar, 2023 8 commits
    • Pablo Neira Ayuso's avatar
      netfilter: nft_quota: copy content when cloning expression · aabef97a
      Pablo Neira Ayuso authored
      If the ruleset contains consumed quota, restore them accordingly.
      Otherwise, listing after restoration shows never used items.
      
      Restore the user-defined quota and flags too.
      
      Fixes: ed0a0c60 ("netfilter: nft_quota: move stateful fields out of expression data")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      aabef97a
    • Pablo Neira Ayuso's avatar
      netfilter: nft_last: copy content when cloning expression · 860e8742
      Pablo Neira Ayuso authored
      If the ruleset contains last timestamps, restore them accordingly.
      Otherwise, listing after restoration shows never used items.
      
      Fixes: 33a24de3 ("netfilter: nft_last: move stateful fields out of expression data")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      860e8742
    • Hangbin Liu's avatar
      selftests: nft_nat: ensuring the listening side is up before starting the client · 2067e7a0
      Hangbin Liu authored
      The test_local_dnat_portonly() function initiates the client-side as
      soon as it sets the listening side to the background. This could lead to
      a race condition where the server may not be ready to listen. To ensure
      that the server-side is up and running before initiating the
      client-side, a delay is introduced to the test_local_dnat_portonly()
      function.
      
      Before the fix:
        # ./nft_nat.sh
        PASS: netns routing/connectivity: ns0-rthlYrBU can reach ns1-rthlYrBU and ns2-rthlYrBU
        PASS: ping to ns1-rthlYrBU was ip NATted to ns2-rthlYrBU
        PASS: ping to ns1-rthlYrBU OK after ip nat output chain flush
        PASS: ipv6 ping to ns1-rthlYrBU was ip6 NATted to ns2-rthlYrBU
        2023/02/27 04:11:03 socat[6055] E connect(5, AF=2 10.0.1.99:2000, 16): Connection refused
        ERROR: inet port rewrite
      
      After the fix:
        # ./nft_nat.sh
        PASS: netns routing/connectivity: ns0-9sPJV6JJ can reach ns1-9sPJV6JJ and ns2-9sPJV6JJ
        PASS: ping to ns1-9sPJV6JJ was ip NATted to ns2-9sPJV6JJ
        PASS: ping to ns1-9sPJV6JJ OK after ip nat output chain flush
        PASS: ipv6 ping to ns1-9sPJV6JJ was ip6 NATted to ns2-9sPJV6JJ
        PASS: inet port rewrite without l3 address
      
      Fixes: 282e5f8f ("netfilter: nat: really support inet nat without l3 address")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      2067e7a0
    • Horatiu Vultur's avatar
      net: lan966x: Fix port police support using tc-matchall · 81563d85
      Horatiu Vultur authored
      When the police was removed from the port, then it was trying to
      remove the police from the police id and not from the actual
      police index.
      The police id represents the id of the police and police index
      represents the position in HW where the police is situated.
      The port police id can be any number while the port police index
      is a number based on the port chip port.
      Fix this by deleting the police from HW that is situated at the
      police index and not police id.
      
      Fixes: 5390334b ("net: lan966x: Add port police support using tc-matchall")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81563d85
    • Eric Dumazet's avatar
      net/sched: flower: fix fl_change() error recovery path · dfd2f0eb
      Eric Dumazet authored
      The two "goto errout;" paths in fl_change() became wrong
      after cited commit.
      
      Indeed we only must not call __fl_put() until the net pointer
      has been set in tcf_exts_init_ex()
      
      This is a minimal fix. We might in the future validate TCA_FLOWER_FLAGS
      before we allocate @fnew.
      
      BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:72 [inline]
      BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:27 [inline]
      BUG: KASAN: null-ptr-deref in refcount_read include/linux/refcount.h:147 [inline]
      BUG: KASAN: null-ptr-deref in __refcount_add_not_zero include/linux/refcount.h:152 [inline]
      BUG: KASAN: null-ptr-deref in __refcount_inc_not_zero include/linux/refcount.h:227 [inline]
      BUG: KASAN: null-ptr-deref in refcount_inc_not_zero include/linux/refcount.h:245 [inline]
      BUG: KASAN: null-ptr-deref in maybe_get_net include/net/net_namespace.h:269 [inline]
      BUG: KASAN: null-ptr-deref in tcf_exts_get_net include/net/pkt_cls.h:260 [inline]
      BUG: KASAN: null-ptr-deref in __fl_put net/sched/cls_flower.c:513 [inline]
      BUG: KASAN: null-ptr-deref in __fl_put+0x13e/0x3b0 net/sched/cls_flower.c:508
      Read of size 4 at addr 000000000000014c by task syz-executor548/5082
      
      CPU: 0 PID: 5082 Comm: syz-executor548 Not tainted 6.2.0-syzkaller-05251-g5b7c4cab #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
      print_report mm/kasan/report.c:420 [inline]
      kasan_report+0xec/0x130 mm/kasan/report.c:517
      check_region_inline mm/kasan/generic.c:183 [inline]
      kasan_check_range+0x141/0x190 mm/kasan/generic.c:189
      instrument_atomic_read include/linux/instrumented.h:72 [inline]
      atomic_read include/linux/atomic/atomic-instrumented.h:27 [inline]
      refcount_read include/linux/refcount.h:147 [inline]
      __refcount_add_not_zero include/linux/refcount.h:152 [inline]
      __refcount_inc_not_zero include/linux/refcount.h:227 [inline]
      refcount_inc_not_zero include/linux/refcount.h:245 [inline]
      maybe_get_net include/net/net_namespace.h:269 [inline]
      tcf_exts_get_net include/net/pkt_cls.h:260 [inline]
      __fl_put net/sched/cls_flower.c:513 [inline]
      __fl_put+0x13e/0x3b0 net/sched/cls_flower.c:508
      fl_change+0x101b/0x4ab0 net/sched/cls_flower.c:2341
      tc_new_tfilter+0x97c/0x2290 net/sched/cls_api.c:2310
      rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
      netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
      netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
      netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
      netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
      sock_sendmsg_nosec net/socket.c:722 [inline]
      sock_sendmsg+0xde/0x190 net/socket.c:745
      ____sys_sendmsg+0x334/0x900 net/socket.c:2504
      ___sys_sendmsg+0x110/0x1b0 net/socket.c:2558
      __sys_sendmmsg+0x18f/0x460 net/socket.c:2644
      __do_sys_sendmmsg net/socket.c:2673 [inline]
      __se_sys_sendmmsg net/socket.c:2670 [inline]
      __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2670
      
      Fixes: 08a0063d ("net/sched: flower: Move filter handle initialization earlier")
      Reported-by: syzbot+baabf3efa7c1e57d28b2@syzkaller.appspotmail.com
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Paul Blakey <paulb@nvidia.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfd2f0eb
    • Eric Dumazet's avatar
      ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping() · 693aa2c0
      Eric Dumazet authored
      ila_xlat_nl_cmd_get_mapping() generates an empty skb,
      triggerring a recent sanity check [1].
      
      Instead, return an error code, so that user space
      can get it.
      
      [1]
      skb_assert_len
      WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
      WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
      Modules linked in:
      CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
      pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
      pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
      lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
      lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
      sp : ffff80001e0d6c40
      x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
      x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
      x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
      x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
      x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
      x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
      x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
      x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
      x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
      x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
      Call trace:
      skb_assert_len include/linux/skbuff.h:2527 [inline]
      __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
      dev_queue_xmit include/linux/netdevice.h:3033 [inline]
      __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
      __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
      netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
      __netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
      netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
      netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
      nlmsg_unicast include/net/netlink.h:1099 [inline]
      genlmsg_unicast include/net/genetlink.h:433 [inline]
      genlmsg_reply include/net/genetlink.h:443 [inline]
      ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
      genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
      genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
      genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
      netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
      genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
      netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
      netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
      netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg net/socket.c:734 [inline]
      ____sys_sendmsg+0x558/0x844 net/socket.c:2479
      ___sys_sendmsg net/socket.c:2533 [inline]
      __sys_sendmsg+0x26c/0x33c net/socket.c:2562
      __do_sys_sendmsg net/socket.c:2571 [inline]
      __se_sys_sendmsg net/socket.c:2569 [inline]
      __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
      __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
      invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
      el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
      do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
      el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
      el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
      el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
      irq event stamp: 136484
      hardirqs last enabled at (136483): [<ffff800008350244>] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345
      hardirqs last disabled at (136484): [<ffff800012358d60>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405
      softirqs last enabled at (136418): [<ffff800008020ea8>] softirq_handle_end kernel/softirq.c:414 [inline]
      softirqs last enabled at (136418): [<ffff800008020ea8>] __do_softirq+0xd4c/0xfa4 kernel/softirq.c:600
      softirqs last disabled at (136371): [<ffff80000802b4a4>] ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:80
      ---[ end trace 0000000000000000 ]---
      skb len=0 headroom=0 headlen=0 tailroom=192
      mac=(0,0) net=(0,-1) trans=-1
      shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
      csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
      hash(0x0 sw=0 l4=0) proto=0x0010 pkttype=6 iif=0
      dev name=nlmon0 feat=0x0000000000005861
      
      Fixes: 7f00feaf ("ila: Add generic ILA translation facility")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      693aa2c0
    • Pedro Tammela's avatar
      net/sched: act_connmark: handle errno on tcf_idr_check_alloc · fb073904
      Pedro Tammela authored
      Smatch reports that 'ci' can be used uninitialized.
      The current code ignores errno coming from tcf_idr_check_alloc, which
      will lead to the incorrect usage of 'ci'. Handle the errno as it should.
      
      Fixes: 288864ef ("net/sched: act_connmark: transition to percpu stats and rcu")
      Reviewed-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarPedro Tammela <pctammela@mojatatu.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb073904
    • Eric Dumazet's avatar
      net: avoid skb end_offset change in __skb_unclone_keeptruesize() · 880ce5f2
      Eric Dumazet authored
      Once initial skb->head has been allocated from skb_small_head_cache,
      we need to make sure to use the same strategy whenever skb->head
      has to be re-allocated, as found by syzbot [1]
      
      This means kmalloc_reserve() can not fallback from using
      skb_small_head_cache to generic (power-of-two) kmem caches.
      
      It seems that we probably want to rework things in the future,
      to partially revert following patch, because we no longer use
      ksize() for skb allocated in TX path.
      
      2b88cba5 ("net: preserve skb_end_offset() in skb_unclone_keeptruesize()")
      
      Ideally, TCP stack should never put payload in skb->head,
      this effort has to be completed.
      
      In the mean time, add a sanity check.
      
      [1]
      BUG: KASAN: invalid-free in slab_free mm/slub.c:3787 [inline]
      BUG: KASAN: invalid-free in kmem_cache_free+0xee/0x5c0 mm/slub.c:3809
      Free of addr ffff88806cdee800 by task syz-executor239/5189
      
      CPU: 0 PID: 5189 Comm: syz-executor239 Not tainted 6.2.0-rc8-syzkaller-02400-gd1fabc68 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
      print_address_description mm/kasan/report.c:306 [inline]
      print_report+0x15e/0x45d mm/kasan/report.c:417
      kasan_report_invalid_free+0x9b/0x1b0 mm/kasan/report.c:482
      ____kasan_slab_free+0x1a5/0x1c0 mm/kasan/common.c:216
      kasan_slab_free include/linux/kasan.h:177 [inline]
      slab_free_hook mm/slub.c:1781 [inline]
      slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
      slab_free mm/slub.c:3787 [inline]
      kmem_cache_free+0xee/0x5c0 mm/slub.c:3809
      skb_kfree_head net/core/skbuff.c:857 [inline]
      skb_kfree_head net/core/skbuff.c:853 [inline]
      skb_free_head+0x16f/0x1a0 net/core/skbuff.c:872
      skb_release_data+0x57a/0x820 net/core/skbuff.c:901
      skb_release_all net/core/skbuff.c:966 [inline]
      __kfree_skb+0x4f/0x70 net/core/skbuff.c:980
      tcp_wmem_free_skb include/net/tcp.h:302 [inline]
      tcp_rtx_queue_purge net/ipv4/tcp.c:3061 [inline]
      tcp_write_queue_purge+0x617/0xcf0 net/ipv4/tcp.c:3074
      tcp_v4_destroy_sock+0x125/0x810 net/ipv4/tcp_ipv4.c:2302
      inet_csk_destroy_sock+0x19a/0x440 net/ipv4/inet_connection_sock.c:1195
      __tcp_close+0xb96/0xf50 net/ipv4/tcp.c:3021
      tcp_close+0x2d/0xc0 net/ipv4/tcp.c:3033
      inet_release+0x132/0x270 net/ipv4/af_inet.c:426
      __sock_release+0xcd/0x280 net/socket.c:651
      sock_close+0x1c/0x20 net/socket.c:1393
      __fput+0x27c/0xa90 fs/file_table.c:320
      task_work_run+0x16f/0x270 kernel/task_work.c:179
      resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
      exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
      exit_to_user_mode_prepare+0x23c/0x250 kernel/entry/common.c:203
      __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
      syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
      do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7f2511f546c3
      Code: c7 c2 c0 ff ff ff f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
      RSP: 002b:00007ffef0103d48 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f2511f546c3
      RDX: 0000000000000978 RSI: 00000000200000c0 RDI: 0000000000000003
      RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000003434
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffef0103d6c
      R13: 00007ffef0103d80 R14: 00007ffef0103dc0 R15: 0000000000000003
      </TASK>
      
      Allocated by task 5189:
      kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
      kasan_set_track+0x25/0x30 mm/kasan/common.c:52
      ____kasan_kmalloc mm/kasan/common.c:374 [inline]
      ____kasan_kmalloc mm/kasan/common.c:333 [inline]
      __kasan_kmalloc+0xa5/0xb0 mm/kasan/common.c:383
      kasan_kmalloc include/linux/kasan.h:211 [inline]
      __do_kmalloc_node mm/slab_common.c:968 [inline]
      __kmalloc_node_track_caller+0x5b/0xc0 mm/slab_common.c:988
      kmalloc_reserve+0xf1/0x230 net/core/skbuff.c:539
      pskb_expand_head+0x237/0x1160 net/core/skbuff.c:1995
      __skb_unclone_keeptruesize+0x93/0x220 net/core/skbuff.c:2094
      skb_unclone_keeptruesize include/linux/skbuff.h:1910 [inline]
      skb_prepare_for_shift net/core/skbuff.c:3804 [inline]
      skb_shift+0xef8/0x1e20 net/core/skbuff.c:3877
      tcp_skb_shift net/ipv4/tcp_input.c:1538 [inline]
      tcp_shift_skb_data net/ipv4/tcp_input.c:1646 [inline]
      tcp_sacktag_walk+0x93b/0x18a0 net/ipv4/tcp_input.c:1713
      tcp_sacktag_write_queue+0x1599/0x31d0 net/ipv4/tcp_input.c:1974
      tcp_ack+0x2e9f/0x5a10 net/ipv4/tcp_input.c:3847
      tcp_rcv_established+0x667/0x2230 net/ipv4/tcp_input.c:6006
      tcp_v4_do_rcv+0x670/0x9b0 net/ipv4/tcp_ipv4.c:1721
      sk_backlog_rcv include/net/sock.h:1113 [inline]
      __release_sock+0x133/0x3b0 net/core/sock.c:2921
      release_sock+0x58/0x1b0 net/core/sock.c:3488
      tcp_sendmsg+0x3a/0x50 net/ipv4/tcp.c:1485
      inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825
      sock_sendmsg_nosec net/socket.c:722 [inline]
      sock_sendmsg+0xde/0x190 net/socket.c:745
      sock_write_iter+0x295/0x3d0 net/socket.c:1136
      call_write_iter include/linux/fs.h:2189 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x9ed/0xdd0 fs/read_write.c:584
      ksys_write+0x1ec/0x250 fs/read_write.c:637
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      The buggy address belongs to the object at ffff88806cdee800
      which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 0 bytes inside of
      1024-byte region [ffff88806cdee800, ffff88806cdeec00)
      
      The buggy address belongs to the physical page:
      page:ffffea0001b37a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x6cde8
      head:ffffea0001b37a00 order:3 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0
      flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000010200 ffff888012441dc0 dead000000000122 0000000000000000
      raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as allocated
      page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1f2a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_MEMALLOC|__GFP_HARDWALL), pid 75, tgid 75 (kworker/u4:4), ts 96369578780, free_ts 26734162530
      prep_new_page mm/page_alloc.c:2531 [inline]
      get_page_from_freelist+0x119c/0x2ce0 mm/page_alloc.c:4283
      __alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5549
      alloc_pages+0x1aa/0x270 mm/mempolicy.c:2287
      alloc_slab_page mm/slub.c:1851 [inline]
      allocate_slab+0x25f/0x350 mm/slub.c:1998
      new_slab mm/slub.c:2051 [inline]
      ___slab_alloc+0xa91/0x1400 mm/slub.c:3193
      __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
      __slab_alloc_node mm/slub.c:3345 [inline]
      slab_alloc_node mm/slub.c:3442 [inline]
      __kmem_cache_alloc_node+0x1a4/0x430 mm/slub.c:3491
      __do_kmalloc_node mm/slab_common.c:967 [inline]
      __kmalloc_node_track_caller+0x4b/0xc0 mm/slab_common.c:988
      kmalloc_reserve+0xf1/0x230 net/core/skbuff.c:539
      __alloc_skb+0x129/0x330 net/core/skbuff.c:608
      __netdev_alloc_skb+0x74/0x410 net/core/skbuff.c:672
      __netdev_alloc_skb_ip_align include/linux/skbuff.h:3203 [inline]
      netdev_alloc_skb_ip_align include/linux/skbuff.h:3213 [inline]
      batadv_iv_ogm_aggregate_new+0x106/0x4e0 net/batman-adv/bat_iv_ogm.c:558
      batadv_iv_ogm_queue_add net/batman-adv/bat_iv_ogm.c:670 [inline]
      batadv_iv_ogm_schedule_buff+0xe6b/0x1450 net/batman-adv/bat_iv_ogm.c:849
      batadv_iv_ogm_schedule net/batman-adv/bat_iv_ogm.c:868 [inline]
      batadv_iv_ogm_schedule net/batman-adv/bat_iv_ogm.c:861 [inline]
      batadv_iv_send_outstanding_bat_ogm_packet+0x744/0x910 net/batman-adv/bat_iv_ogm.c:1712
      process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
      worker_thread+0x669/0x1090 kernel/workqueue.c:2436
      page last free stack trace:
      reset_page_owner include/linux/page_owner.h:24 [inline]
      free_pages_prepare mm/page_alloc.c:1446 [inline]
      free_pcp_prepare+0x66a/0xc20 mm/page_alloc.c:1496
      free_unref_page_prepare mm/page_alloc.c:3369 [inline]
      free_unref_page+0x1d/0x490 mm/page_alloc.c:3464
      free_contig_range+0xb5/0x180 mm/page_alloc.c:9488
      destroy_args+0xa8/0x64c mm/debug_vm_pgtable.c:998
      debug_vm_pgtable+0x28de/0x296f mm/debug_vm_pgtable.c:1318
      do_one_initcall+0x141/0x790 init/main.c:1306
      do_initcall_level init/main.c:1379 [inline]
      do_initcalls init/main.c:1395 [inline]
      do_basic_setup init/main.c:1414 [inline]
      kernel_init_freeable+0x6f9/0x782 init/main.c:1634
      kernel_init+0x1e/0x1d0 init/main.c:1522
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
      
      Memory state around the buggy address:
      ffff88806cdee700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ffff88806cdee780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88806cdee800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ^
      ffff88806cdee880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: bf9f1baa ("net: add dedicated kmem_cache for typical/small skb->head")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      880ce5f2
  5. 28 Feb, 2023 7 commits
  6. 27 Feb, 2023 3 commits