1. 05 Jan, 2023 2 commits
    • Caleb Sander's avatar
      qed: allow sleep in qed_mcp_trace_dump() · 5401c3e0
      Caleb Sander authored
      By default, qed_mcp_cmd_and_union() delays 10us at a time in a loop
      that can run 500K times, so calls to qed_mcp_nvm_rd_cmd()
      may block the current thread for over 5s.
      We observed thread scheduling delays over 700ms in production,
      with stacktraces pointing to this code as the culprit.
      
      qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.
      It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().
      Add a "can sleep" parameter to qed_find_nvram_image() and
      qed_nvram_read() so they can sleep during qed_mcp_trace_dump().
      qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),
      called only by qed_mcp_trace_dump(), allow these functions to sleep.
      I can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,
      so keep b_can_sleep set to false when it calls these functions.
      
      An example stacktrace from a custom warning we added to the kernel
      showing a thread that has not scheduled despite long needing resched:
      [ 2745.362925,17] ------------[ cut here ]------------
      [ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()
      [ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99
      [ 2745.362956,17] Modules linked in: ...
      [ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P           O    4.4.182+ #202104120910+6d1da174272d.61x
      [ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020
      [ 2745.363346,17]  0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20
      [ 2745.363358,17]  ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000
      [ 2745.363369,17]  0000000000000063 0000000000000174 0000000000000074 0000000000000000
      [ 2745.363379,17] Call Trace:
      [ 2745.363382,17]  <IRQ>  [<ffffffff8131eb2f>] dump_stack+0x8e/0xcf
      [ 2745.363393,17]  [<ffffffff81072ac2>] warn_slowpath_common+0x82/0xc0
      [ 2745.363398,17]  [<ffffffff81072b4c>] warn_slowpath_fmt+0x4c/0x50
      [ 2745.363404,17]  [<ffffffff810d5a8e>] ? rcu_irq_exit+0xae/0xc0
      [ 2745.363408,17]  [<ffffffff817c99fe>] do_IRQ+0x15e/0x1a0
      [ 2745.363413,17]  [<ffffffff817c7ac9>] common_interrupt+0x89/0x89
      [ 2745.363416,17]  <EOI>  [<ffffffff8132aa74>] ? delay_tsc+0x24/0x50
      [ 2745.363425,17]  [<ffffffff8132aa04>] __udelay+0x34/0x40
      [ 2745.363457,17]  [<ffffffffa04d45ff>] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed]
      [ 2745.363473,17]  [<ffffffffa04d5ced>] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed]
      [ 2745.363490,17]  [<ffffffffa04e1dc7>] qed_mcp_trace_dump+0x4a7/0x630 [qed]
      [ 2745.363504,17]  [<ffffffffa04e2556>] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed]
      [ 2745.363520,17]  [<ffffffffa04e4ea7>] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed]
      [ 2745.363536,17]  [<ffffffffa04ea881>] qed_dbg_feature_size+0x61/0xa0 [qed]
      [ 2745.363551,17]  [<ffffffffa04eb427>] qed_dbg_all_data_size+0x247/0x260 [qed]
      [ 2745.363560,17]  [<ffffffffa0482c10>] qede_get_regs_len+0x30/0x40 [qede]
      [ 2745.363566,17]  [<ffffffff816c9783>] ethtool_get_drvinfo+0xe3/0x190
      [ 2745.363570,17]  [<ffffffff816cc152>] dev_ethtool+0x1362/0x2140
      [ 2745.363575,17]  [<ffffffff8109bcc6>] ? finish_task_switch+0x76/0x260
      [ 2745.363580,17]  [<ffffffff817c2116>] ? __schedule+0x3c6/0x9d0
      [ 2745.363585,17]  [<ffffffff810dbd50>] ? hrtimer_start_range_ns+0x1d0/0x370
      [ 2745.363589,17]  [<ffffffff816c1e5b>] ? dev_get_by_name_rcu+0x6b/0x90
      [ 2745.363594,17]  [<ffffffff816de6a8>] dev_ioctl+0xe8/0x710
      [ 2745.363599,17]  [<ffffffff816a58a8>] sock_do_ioctl+0x48/0x60
      [ 2745.363603,17]  [<ffffffff816a5d87>] sock_ioctl+0x1c7/0x280
      [ 2745.363608,17]  [<ffffffff8111f393>] ? seccomp_phase1+0x83/0x220
      [ 2745.363612,17]  [<ffffffff811e3503>] do_vfs_ioctl+0x2b3/0x4e0
      [ 2745.363616,17]  [<ffffffff811e3771>] SyS_ioctl+0x41/0x70
      [ 2745.363619,17]  [<ffffffff817c6ffe>] entry_SYSCALL_64_fastpath+0x1e/0x79
      [ 2745.363622,17] ---[ end trace f6954aa440266421 ]---
      
      Fixes: c965db44 ("qed: Add support for debug data collection")
      Signed-off-by: default avatarCaleb Sander <csander@purestorage.com>
      Acked-by: default avatarAlok Prasad <palok@marvell.com>
      Link: https://lore.kernel.org/r/20230103233021.1457646-1-csander@purestorage.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5401c3e0
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 49d9601b
      Jakub Kicinski authored
      Alexei Starovoitov says:
      
      ====================
      bpf 2023-01-04
      
      We've added 5 non-merge commits during the last 8 day(s) which contain
      a total of 5 files changed, 112 insertions(+), 18 deletions(-).
      
      The main changes are:
      
      1) Always use maximal size for copy_array in the verifier to fix
         KASAN tracking, from Kees.
      
      2) Fix bpf task iterator walking through dead tasks, from Kui-Feng.
      
      3) Make sure livepatch and bpf fexit can coexist, from Chuang.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        bpf: Always use maximal size for copy_array()
        selftests/bpf: add a test for iter/task_vma for short-lived processes
        bpf: keep a reference to the mm, in case the task is dead.
        selftests/bpf: Temporarily disable part of btf_dump:var_data test.
        bpf: Fix panic due to wrong pageattr of im->image
      ====================
      
      Link: https://lore.kernel.org/r/20230104215500.79435-1-alexei.starovoitov@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      49d9601b
  2. 04 Jan, 2023 1 commit
  3. 03 Jan, 2023 5 commits
    • Szymon Heidrich's avatar
      usb: rndis_host: Secure rndis_query check against int overflow · c7dd1380
      Szymon Heidrich authored
      Variables off and len typed as uint32 in rndis_query function
      are controlled by incoming RNDIS response message thus their
      value may be manipulated. Setting off to a unexpectetly large
      value will cause the sum with len and 8 to overflow and pass
      the implemented validation step. Consequently the response
      pointer will be referring to a location past the expected
      buffer boundaries allowing information leakage e.g. via
      RNDIS_OID_802_3_PERMANENT_ADDRESS OID.
      
      Fixes: ddda0862 ("USB: rndis_host, various cleanups")
      Signed-off-by: default avatarSzymon Heidrich <szymon.heidrich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7dd1380
    • Sean Anderson's avatar
      net: dpaa: Fix dtsec check for PCS availability · 7dc61838
      Sean Anderson authored
      We want to fail if the PCS is not available, not if it is available. Fix
      this condition.
      
      Fixes: 5d93cfcf ("net: dpaa: Convert to phylink")
      Reported-by: default avatarChristian Zigotzky <info@xenosoft.de>
      Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7dc61838
    • Geetha sowjanya's avatar
      octeontx2-pf: Fix lmtst ID used in aura free · 4af1b64f
      Geetha sowjanya authored
      Current code uses per_cpu pointer to get the lmtst_id mapped to
      the core on which aura_free() is executed. Using per_cpu pointer
      without preemption disable causing mismatch between lmtst_id and
      core on which pointer gets freed. This patch fixes the issue by
      disabling preemption around aura_free.
      
      Fixes: ef6c8da7 ("octeontx2-pf: cn10K: Reserve LMTST lines per core")
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarGeetha sowjanya <gakula@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4af1b64f
    • Daniil Tatianin's avatar
      drivers/net/bonding/bond_3ad: return when there's no aggregator · 9c807965
      Daniil Tatianin authored
      Otherwise we would dereference a NULL aggregator pointer when calling
      __set_agg_ports_ready on the line below.
      
      Found by Linux Verification Center (linuxtesting.org) with the SVACE
      static analysis tool.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarDaniil Tatianin <d-tatianin@yandex-team.ru>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c807965
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · d57609fa
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Use signed integer in ipv6_skip_exthdr() called from nf_confirm().
         Reported by static analysis tooling, patch from Florian Westphal.
      
      2) Missing set type checks in nf_tables: Validate that set declaration
         matches the an existing set type, otherwise bail out with EEXIST.
         Currently, nf_tables silently accepts the re-declaration with a
         different type but it bails out later with EINVAL when the user adds
         entries to the set. This fix is relatively large because it requires
         two preparation patches that are included in this batch.
      
      3) Do not ignore updates of timeout and gc_interval parameters in
         existing sets.
      
      4) Fix a hang when 0/0 subnets is added to a hash:net,port,net type of
         ipset. Except hash:net,port,net and hash:net,iface, the set types don't
         support 0/0 and the auxiliary functions rely on this fact. So 0/0 needs
         a special handling in hash:net,port,net which was missing (hash:net,iface
         was not affected by this bug), from Jozsef Kadlecsik.
      
      5) When adding/deleting large number of elements in one step in ipset,
         it can take a reasonable amount of time and can result in soft lockup
         errors. This patch is a complete rework of the previous version in order
         to use a smaller internal batch limit and at the same time removing
         the external hard limit to add arbitrary number of elements in one step.
         Also from Jozsef Kadlecsik.
      
      Except for patch #1, which fixes a bug introduced in the previous net-next
      development cycle, anything else has been broken for several releases.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d57609fa
  4. 02 Jan, 2023 8 commits
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: Rework long task execution when adding/deleting entries · 5e29dc36
      Jozsef Kadlecsik authored
      When adding/deleting large number of elements in one step in ipset, it can
      take a reasonable amount of time and can result in soft lockup errors. The
      patch 5f7b51bf ("netfilter: ipset: Limit the maximal range of
      consecutive elements to add/delete") tried to fix it by limiting the max
      elements to process at all. However it was not enough, it is still possible
      that we get hung tasks. Lowering the limit is not reasonable, so the
      approach in this patch is as follows: rely on the method used at resizing
      sets and save the state when we reach a smaller internal batch limit,
      unlock/lock and proceed from the saved state. Thus we can avoid long
      continuous tasks and at the same time removed the limit to add/delete large
      number of elements in one step.
      
      The nfnl mutex is held during the whole operation which prevents one to
      issue other ipset commands in parallel.
      
      Fixes: 5f7b51bf ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete")
      Reported-by: syzbot+9204e7399656300bf271@syzkaller.appspotmail.com
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      5e29dc36
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: fix hash:net,port,net hang with /0 subnet · a31d47be
      Jozsef Kadlecsik authored
      The hash:net,port,net set type supports /0 subnets. However, the patch
      commit 5f7b51bf titled "netfilter: ipset: Limit the maximal range
      of consecutive elements to add/delete" did not take into account it and
      resulted in an endless loop. The bug is actually older but the patch
      5f7b51bf brings it out earlier.
      
      Handle /0 subnets properly in hash:net,port,net set types.
      
      Fixes: 5f7b51bf ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete")
      Reported-by: default avatarМарк Коренберг <socketpair@gmail.com>
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a31d47be
    • Horatiu Vultur's avatar
      net: sparx5: Fix reading of the MAC address · 588ab2dc
      Horatiu Vultur authored
      There is an issue with the checking of the return value of
      'of_get_mac_address', which returns 0 on success and negative value on
      failure. The driver interpretated the result the opposite way. Therefore
      if there was a MAC address defined in the DT, then the driver was
      generating a random MAC address otherwise it would use address 0.
      Fix this by checking correctly the return value of 'of_get_mac_address'
      
      Fixes: b74ef9f9 ("net: sparx5: Do not use mac_addr uninitialized in mchp_sparx5_probe()")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      588ab2dc
    • Ido Schimmel's avatar
      vxlan: Fix memory leaks in error path · 06bf6294
      Ido Schimmel authored
      The memory allocated by vxlan_vnigroup_init() is not freed in the error
      path, leading to memory leaks [1]. Fix by calling
      vxlan_vnigroup_uninit() in the error path.
      
      The leaks can be reproduced by annotating gro_cells_init() with
      ALLOW_ERROR_INJECTION() and then running:
      
       # echo "100" > /sys/kernel/debug/fail_function/probability
       # echo "1" > /sys/kernel/debug/fail_function/times
       # echo "gro_cells_init" > /sys/kernel/debug/fail_function/inject
       # printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval
       # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter
       RTNETLINK answers: Cannot allocate memory
      
      [1]
      unreferenced object 0xffff88810db84a00 (size 512):
        comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
        hex dump (first 32 bytes):
          f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02  ..v.............
          03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00  ....H...........
        backtrace:
          [<ffffffff81a3097a>] kmalloc_trace+0x2a/0x60
          [<ffffffff82f049fc>] vxlan_vnigroup_init+0x4c/0x160
          [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280
          [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0
          [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50
          [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130
          [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0
          [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0
          [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40
          [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440
          [<ffffffff839066af>] netlink_unicast+0x53f/0x810
          [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70
          [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90
          [<ffffffff835cd6da>] ___sys_sendmsg+0x13a/0x1e0
          [<ffffffff835cd94c>] __sys_sendmsg+0x11c/0x1f0
          [<ffffffff8424da78>] do_syscall_64+0x38/0x80
      unreferenced object 0xffff88810e76d5f8 (size 192):
        comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
        hex dump (first 32 bytes):
          04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00  ..........O.....
          08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff  ..v.......v.....
        backtrace:
          [<ffffffff81a3162e>] __kmalloc_node+0x4e/0x90
          [<ffffffff81a0e166>] kvmalloc_node+0xa6/0x1f0
          [<ffffffff8276e1a3>] bucket_table_alloc.isra.0+0x83/0x460
          [<ffffffff8276f18b>] rhashtable_init+0x43b/0x7c0
          [<ffffffff82f04a1c>] vxlan_vnigroup_init+0x6c/0x160
          [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280
          [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0
          [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50
          [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130
          [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0
          [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0
          [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40
          [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440
          [<ffffffff839066af>] netlink_unicast+0x53f/0x810
          [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70
          [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90
      
      Fixes: f9c4bb0b ("vxlan: vni filtering support on collect metadata device")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06bf6294
    • Randy Dunlap's avatar
      net: sched: htb: fix htb_classify() kernel-doc · 43d25378
      Randy Dunlap authored
      Fix W=1 kernel-doc warning:
      
      net/sched/sch_htb.c:214: warning: expecting prototype for htb_classify(). Prototype was for HTB_DIRECT() instead
      
      by moving the HTB_DIRECT() macro above the function.
      Add kernel-doc notation for function parameters as well.
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43d25378
    • David S. Miller's avatar
      Merge branch 'cls_drop-fix' · 819fcf4a
      David S. Miller authored
      Jamal Hadi Salim says:
      
      ====================
      net: dont intepret cls results when asked to drop
      
      It is possible that an error in processing may occur in tcf_classify() which
      will result in res.classid being some garbage value. Example of such a code path
      is when the classifier goes into a loop due to bad policy. See patch 1/2
      for a sample splat.
      While the core code reacts correctly and asks the caller to drop the packet
      (by returning TC_ACT_SHOT) some callers first intepret the res.class as
      a pointer to memory and end up dropping the packet only after some activity with
      the pointer. There is likelihood of this resulting in an exploit. So lets fix
      all the known qdiscs that behave this way.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      819fcf4a
    • Jamal Hadi Salim's avatar
      net: sched: cbq: dont intepret cls results when asked to drop · caa4b35b
      Jamal Hadi Salim authored
      If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume that
      res.class contains a valid pointer
      
      Sample splat reported by Kyle Zeng
      
      [    5.405624] 0: reclassify loop, rule prio 0, protocol 800
      [    5.406326] ==================================================================
      [    5.407240] BUG: KASAN: slab-out-of-bounds in cbq_enqueue+0x54b/0xea0
      [    5.407987] Read of size 1 at addr ffff88800e3122aa by task poc/299
      [    5.408731]
      [    5.408897] CPU: 0 PID: 299 Comm: poc Not tainted 5.10.155+ #15
      [    5.409516] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.15.0-1 04/01/2014
      [    5.410439] Call Trace:
      [    5.410764]  dump_stack+0x87/0xcd
      [    5.411153]  print_address_description+0x7a/0x6b0
      [    5.411687]  ? vprintk_func+0xb9/0xc0
      [    5.411905]  ? printk+0x76/0x96
      [    5.412110]  ? cbq_enqueue+0x54b/0xea0
      [    5.412323]  kasan_report+0x17d/0x220
      [    5.412591]  ? cbq_enqueue+0x54b/0xea0
      [    5.412803]  __asan_report_load1_noabort+0x10/0x20
      [    5.413119]  cbq_enqueue+0x54b/0xea0
      [    5.413400]  ? __kasan_check_write+0x10/0x20
      [    5.413679]  __dev_queue_xmit+0x9c0/0x1db0
      [    5.413922]  dev_queue_xmit+0xc/0x10
      [    5.414136]  ip_finish_output2+0x8bc/0xcd0
      [    5.414436]  __ip_finish_output+0x472/0x7a0
      [    5.414692]  ip_finish_output+0x5c/0x190
      [    5.414940]  ip_output+0x2d8/0x3c0
      [    5.415150]  ? ip_mc_finish_output+0x320/0x320
      [    5.415429]  __ip_queue_xmit+0x753/0x1760
      [    5.415664]  ip_queue_xmit+0x47/0x60
      [    5.415874]  __tcp_transmit_skb+0x1ef9/0x34c0
      [    5.416129]  tcp_connect+0x1f5e/0x4cb0
      [    5.416347]  tcp_v4_connect+0xc8d/0x18c0
      [    5.416577]  __inet_stream_connect+0x1ae/0xb40
      [    5.416836]  ? local_bh_enable+0x11/0x20
      [    5.417066]  ? lock_sock_nested+0x175/0x1d0
      [    5.417309]  inet_stream_connect+0x5d/0x90
      [    5.417548]  ? __inet_stream_connect+0xb40/0xb40
      [    5.417817]  __sys_connect+0x260/0x2b0
      [    5.418037]  __x64_sys_connect+0x76/0x80
      [    5.418267]  do_syscall_64+0x31/0x50
      [    5.418477]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
      [    5.418770] RIP: 0033:0x473bb7
      [    5.418952] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00
      00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00
      00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34
      24 89
      [    5.420046] RSP: 002b:00007fffd20eb0f8 EFLAGS: 00000246 ORIG_RAX:
      000000000000002a
      [    5.420472] RAX: ffffffffffffffda RBX: 00007fffd20eb578 RCX: 0000000000473bb7
      [    5.420872] RDX: 0000000000000010 RSI: 00007fffd20eb110 RDI: 0000000000000007
      [    5.421271] RBP: 00007fffd20eb150 R08: 0000000000000001 R09: 0000000000000004
      [    5.421671] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
      [    5.422071] R13: 00007fffd20eb568 R14: 00000000004fc740 R15: 0000000000000002
      [    5.422471]
      [    5.422562] Allocated by task 299:
      [    5.422782]  __kasan_kmalloc+0x12d/0x160
      [    5.423007]  kasan_kmalloc+0x5/0x10
      [    5.423208]  kmem_cache_alloc_trace+0x201/0x2e0
      [    5.423492]  tcf_proto_create+0x65/0x290
      [    5.423721]  tc_new_tfilter+0x137e/0x1830
      [    5.423957]  rtnetlink_rcv_msg+0x730/0x9f0
      [    5.424197]  netlink_rcv_skb+0x166/0x300
      [    5.424428]  rtnetlink_rcv+0x11/0x20
      [    5.424639]  netlink_unicast+0x673/0x860
      [    5.424870]  netlink_sendmsg+0x6af/0x9f0
      [    5.425100]  __sys_sendto+0x58d/0x5a0
      [    5.425315]  __x64_sys_sendto+0xda/0xf0
      [    5.425539]  do_syscall_64+0x31/0x50
      [    5.425764]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
      [    5.426065]
      [    5.426157] The buggy address belongs to the object at ffff88800e312200
      [    5.426157]  which belongs to the cache kmalloc-128 of size 128
      [    5.426955] The buggy address is located 42 bytes to the right of
      [    5.426955]  128-byte region [ffff88800e312200, ffff88800e312280)
      [    5.427688] The buggy address belongs to the page:
      [    5.427992] page:000000009875fabc refcount:1 mapcount:0
      mapping:0000000000000000 index:0x0 pfn:0xe312
      [    5.428562] flags: 0x100000000000200(slab)
      [    5.428812] raw: 0100000000000200 dead000000000100 dead000000000122
      ffff888007843680
      [    5.429325] raw: 0000000000000000 0000000000100010 00000001ffffffff
      ffff88800e312401
      [    5.429875] page dumped because: kasan: bad access detected
      [    5.430214] page->mem_cgroup:ffff88800e312401
      [    5.430471]
      [    5.430564] Memory state around the buggy address:
      [    5.430846]  ffff88800e312180: fc fc fc fc fc fc fc fc fc fc fc fc
      fc fc fc fc
      [    5.431267]  ffff88800e312200: 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 fc
      [    5.431705] >ffff88800e312280: fc fc fc fc fc fc fc fc fc fc fc fc
      fc fc fc fc
      [    5.432123]                                   ^
      [    5.432391]  ffff88800e312300: 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 fc
      [    5.432810]  ffff88800e312380: fc fc fc fc fc fc fc fc fc fc fc fc
      fc fc fc fc
      [    5.433229] ==================================================================
      [    5.433648] Disabling lock debugging due to kernel taint
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarKyle Zeng <zengyhkyle@gmail.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      caa4b35b
    • Jamal Hadi Salim's avatar
      net: sched: atm: dont intepret cls results when asked to drop · a2965c7b
      Jamal Hadi Salim authored
      If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume
      res.class contains a valid pointer
      Fixes: b0188d4d ("[NET_SCHED]: sch_atm: Lindent")
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2965c7b
  5. 01 Jan, 2023 13 commits
  6. 30 Dec, 2022 11 commits