1. 25 Apr, 2022 10 commits
  2. 23 Apr, 2022 1 commit
    • Xin Long's avatar
      sctp: check asoc strreset_chunk in sctp_generate_reconf_event · 165e3e17
      Xin Long authored
      A null pointer reference issue can be triggered when the response of a
      stream reconf request arrives after the timer is triggered, such as:
      
        send Incoming SSN Reset Request --->
        CPU0:
         reconf timer is triggered,
         go to the handler code before hold sk lock
                                  <--- reply with Outgoing SSN Reset Request
        CPU1:
         process Outgoing SSN Reset Request,
         and set asoc->strreset_chunk to NULL
        CPU0:
         continue the handler code, hold sk lock,
         and try to hold asoc->strreset_chunk, crash!
      
      In Ying Xu's testing, the call trace is:
      
        [ ] BUG: kernel NULL pointer dereference, address: 0000000000000010
        [ ] RIP: 0010:sctp_chunk_hold+0xe/0x40 [sctp]
        [ ] Call Trace:
        [ ]  <IRQ>
        [ ]  sctp_sf_send_reconf+0x2c/0x100 [sctp]
        [ ]  sctp_do_sm+0xa4/0x220 [sctp]
        [ ]  sctp_generate_reconf_event+0xbd/0xe0 [sctp]
        [ ]  call_timer_fn+0x26/0x130
      
      This patch is to fix it by returning from the timer handler if asoc
      strreset_chunk is already set to NULL.
      
      Fixes: 7b9438de ("sctp: add stream reconf timer")
      Reported-by: default avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      165e3e17
  3. 22 Apr, 2022 12 commits
  4. 21 Apr, 2022 2 commits
    • Linus Torvalds's avatar
      Merge tag 'net-5.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 59f0c244
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from xfrm and can.
      
        Current release - regressions:
      
         - rxrpc: restore removed timer deletion
      
        Current release - new code bugs:
      
         - gre: fix device lookup for l3mdev use-case
      
         - xfrm: fix egress device lookup for l3mdev use-case
      
        Previous releases - regressions:
      
         - sched: cls_u32: fix netns refcount changes in u32_change()
      
         - smc: fix sock leak when release after smc_shutdown()
      
         - xfrm: limit skb_page_frag_refill use to a single page
      
         - eth: atlantic: invert deep par in pm functions, preventing null
           derefs
      
         - eth: stmmac: use readl_poll_timeout_atomic() in atomic state
      
        Previous releases - always broken:
      
         - gre: fix skb_under_panic on xmit
      
         - openvswitch: fix OOB access in reserve_sfa_size()
      
         - dsa: hellcreek: calculate checksums in tagger
      
         - eth: ice: fix crash in switchdev mode
      
         - eth: igc:
            - fix infinite loop in release_swfw_sync
            - fix scheduling while atomic"
      
      * tag 'net-5.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (37 commits)
        drivers: net: hippi: Fix deadlock in rr_close()
        selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets
        selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets
        nfc: MAINTAINERS: add Bug entry
        net: stmmac: Use readl_poll_timeout_atomic() in atomic state
        doc/ip-sysctl: add bc_forwarding
        netlink: reset network and mac headers in netlink_dump()
        net: mscc: ocelot: fix broken IP multicast flooding
        net: dsa: hellcreek: Calculate checksums in tagger
        net: atlantic: invert deep par in pm functions, preventing null derefs
        can: isotp: stop timeout monitoring when no first frame was sent
        bonding: do not discard lowest hash bit for non layer3+4 hashing
        net: lan966x: Make sure to release ptp interrupt
        ipv6: make ip6_rt_gc_expire an atomic_t
        net: Handle l3mdev in ip_tunnel_init_flow
        l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be using netdev_master_upper_dev_get_rcu
        net/sched: cls_u32: fix possible leak in u32_init_knode()
        net/sched: cls_u32: fix netns refcount changes in u32_change()
        powerpc: Update MAINTAINERS for ibmvnic and VAS
        net: restore alpha order to Ethernet devices in config
        ...
      59f0c244
    • Duoming Zhou's avatar
      drivers: net: hippi: Fix deadlock in rr_close() · bc6de287
      Duoming Zhou authored
      There is a deadlock in rr_close(), which is shown below:
      
         (Thread 1)                |      (Thread 2)
                                   | rr_open()
      rr_close()                   |  add_timer()
       spin_lock_irqsave() //(1)   |  (wait a time)
       ...                         | rr_timer()
       del_timer_sync()            |  spin_lock_irqsave() //(2)
       (wait timer to stop)        |  ...
      
      We hold rrpriv->lock in position (1) of thread 1 and
      use del_timer_sync() to wait timer to stop, but timer handler
      also need rrpriv->lock in position (2) of thread 2.
      As a result, rr_close() will block forever.
      
      This patch extracts del_timer_sync() from the protection of
      spin_lock_irqsave(), which could let timer handler to obtain
      the needed lock.
      Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
      Link: https://lore.kernel.org/r/20220417125519.82618-1-duoming@zju.edu.cnSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      bc6de287
  5. 20 Apr, 2022 9 commits
    • Linus Torvalds's avatar
      Merge tag 'xtensa-20220416' of https://github.com/jcmvbkbc/linux-xtensa · b2534357
      Linus Torvalds authored
      Pull xtensa fixes from Max Filippov:
      
       - fix patching CPU selection in patch_text
      
       - fix potential deadlock in ISS platform serial driver
      
       - fix potential register clobbering in coprocessor exception handler
      
      * tag 'xtensa-20220416' of https://github.com/jcmvbkbc/linux-xtensa:
        xtensa: fix a7 clobbering in coprocessor context load/store
        arch: xtensa: platforms: Fix deadlock in rs_close()
        xtensa: patch_text: Fixup last cpu should be master
      b2534357
    • Linus Torvalds's avatar
      Merge tag 'erofs-for-5.18-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs · 10c5f102
      Linus Torvalds authored
      Pull erofs fixes from Gao Xiang:
       "One patch to fix a use-after-free race related to the on-stack
        z_erofs_decompressqueue, which happens very rarely but needs to be
        fixed properly soon.
      
        The other patch fixes some sysfs Sphinx warnings"
      
      * tag 'erofs-for-5.18-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
        Documentation/ABI: sysfs-fs-erofs: Fix Sphinx errors
        erofs: fix use-after-free of on-stack io[]
      10c5f102
    • Linus Torvalds's avatar
      Revert "fs/pipe: use kvcalloc to allocate a pipe_buffer array" · 906f9040
      Linus Torvalds authored
      This reverts commit 5a519c8f.
      
      It turns out that making the pipe almost arbitrarily large has some
      rather unexpected downsides.  The kernel test robot reports a kernel
      warning that is due to pipe->max_usage now growing to the point where
      the iter_file_splice_write() buffer allocation can no longer be
      satisfied as a slab allocation, and the
      
              int nbufs = pipe->max_usage;
              struct bio_vec *array = kcalloc(nbufs, sizeof(struct bio_vec),
                                              GFP_KERNEL);
      
      code sequence there will now always fail as a result.
      
      That code could be modified to use kvcalloc() too, but I feel very
      uncomfortable making those kinds of changes for a very niche use case
      that really should have other options than make these kinds of
      fundamental changes to pipe behavior.
      
      Maybe the CRIU process dumping should be multi-threaded, and use
      multiple pipes and multiple cores, rather than try to use one larger
      pipe to minimize splice() calls.
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Link: https://lore.kernel.org/all/20220420073717.GD16310@xsang-OptiPlex-9020/
      Cc: Andrei Vagin <avagin@gmail.com>
      Cc: Dmitry Safonov <0x7f454c46@gmail.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      906f9040
    • Mikulas Patocka's avatar
      x86: __memcpy_flushcache: fix wrong alignment if size > 2^32 · a6823e4e
      Mikulas Patocka authored
      The first "if" condition in __memcpy_flushcache is supposed to align the
      "dest" variable to 8 bytes and copy data up to this alignment.  However,
      this condition may misbehave if "size" is greater than 4GiB.
      
      The statement min_t(unsigned, size, ALIGN(dest, 8) - dest); casts both
      arguments to unsigned int and selects the smaller one.  However, the
      cast truncates high bits in "size" and it results in misbehavior.
      
      For example:
      
      	suppose that size == 0x100000001, dest == 0x200000002
      	min_t(unsigned, size, ALIGN(dest, 8) - dest) == min_t(0x1, 0xe) == 0x1;
      	...
      	dest += 0x1;
      
      so we copy just one byte "and" dest remains unaligned.
      
      This patch fixes the bug by replacing unsigned with size_t.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a6823e4e
    • Ido Schimmel's avatar
      selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets · 5e624215
      Ido Schimmel authored
      The test verifies that packets are correctly flooded by the bridge and
      the VXLAN device by matching on the encapsulated packets at the other
      end. However, if packets other than those generated by the test also
      ingress the bridge (e.g., MLD packets), they will be flooded as well and
      interfere with the expected count.
      
      Make the test more robust by making sure that only the packets generated
      by the test can ingress the bridge. Drop all the rest using tc filters
      on the egress of 'br0' and 'h1'.
      
      In the software data path, the problem can be solved by matching on the
      inner destination MAC or dropping unwanted packets at the egress of the
      VXLAN device, but this is not currently supported by mlxsw.
      
      Fixes: d01724dd ("selftests: mlxsw: spectrum-2: Add a test for VxLAN flooding with IPv6")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e624215
    • Ido Schimmel's avatar
      selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets · 044011fd
      Ido Schimmel authored
      The test verifies that packets are correctly flooded by the bridge and
      the VXLAN device by matching on the encapsulated packets at the other
      end. However, if packets other than those generated by the test also
      ingress the bridge (e.g., MLD packets), they will be flooded as well and
      interfere with the expected count.
      
      Make the test more robust by making sure that only the packets generated
      by the test can ingress the bridge. Drop all the rest using tc filters
      on the egress of 'br0' and 'h1'.
      
      In the software data path, the problem can be solved by matching on the
      inner destination MAC or dropping unwanted packets at the egress of the
      VXLAN device, but this is not currently supported by mlxsw.
      
      Fixes: 94d302de ("selftests: mlxsw: Add a test for VxLAN flooding")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      044011fd
    • Krzysztof Kozlowski's avatar
      nfc: MAINTAINERS: add Bug entry · c5d0fc54
      Krzysztof Kozlowski authored
      Add a Bug section, indicating preferred mailing method for bug reports,
      to NFC Subsystem entry.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5d0fc54
    • Kevin Hao's avatar
      net: stmmac: Use readl_poll_timeout_atomic() in atomic state · 234901de
      Kevin Hao authored
      The init_systime() may be invoked in atomic state. We have observed the
      following call trace when running "phc_ctl /dev/ptp0 set" on a Intel
      Agilex board.
        BUG: sleeping function called from invalid context at drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:74
        in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 381, name: phc_ctl
        preempt_count: 1, expected: 0
        RCU nest depth: 0, expected: 0
        Preemption disabled at:
        [<ffff80000892ef78>] stmmac_set_time+0x34/0x8c
        CPU: 2 PID: 381 Comm: phc_ctl Not tainted 5.18.0-rc2-next-20220414-yocto-standard+ #567
        Hardware name: SoCFPGA Agilex SoCDK (DT)
        Call trace:
         dump_backtrace.part.0+0xc4/0xd0
         show_stack+0x24/0x40
         dump_stack_lvl+0x7c/0xa0
         dump_stack+0x18/0x34
         __might_resched+0x154/0x1c0
         __might_sleep+0x58/0x90
         init_systime+0x78/0x120
         stmmac_set_time+0x64/0x8c
         ptp_clock_settime+0x60/0x9c
         pc_clock_settime+0x6c/0xc0
         __arm64_sys_clock_settime+0x88/0xf0
         invoke_syscall+0x5c/0x130
         el0_svc_common.constprop.0+0x4c/0x100
         do_el0_svc+0x7c/0xa0
         el0_svc+0x58/0xcc
         el0t_64_sync_handler+0xa4/0x130
         el0t_64_sync+0x18c/0x190
      
      So we should use readl_poll_timeout_atomic() here instead of
      readl_poll_timeout().
      
      Also adjust the delay time to 10us to fix a "__bad_udelay" build error
      reported by "kernel test robot <lkp@intel.com>". I have tested this on
      Intel Agilex and NXP S32G boards, there is no delay needed at all.
      So the 10us delay should be long enough for most cases.
      
      Fixes: ff8ed737 ("net: stmmac: use readl_poll_timeout() function in init_systime()")
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      234901de
    • Nicolas Dichtel's avatar
      doc/ip-sysctl: add bc_forwarding · c6a4254c
      Nicolas Dichtel authored
      Let's describe this sysctl.
      
      Fixes: 5cbf777c ("route: add support for directed broadcast forwarding")
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6a4254c
  6. 19 Apr, 2022 6 commits
    • Song Liu's avatar
      vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP · 559089e0
      Song Liu authored
      Huge page backed vmalloc memory could benefit performance in many cases.
      However, some users of vmalloc may not be ready to handle huge pages for
      various reasons: hardware constraints, potential pages split, etc.
      VM_NO_HUGE_VMAP was introduced to allow vmalloc users to opt-out huge
      pages.  However, it is not easy to track down all the users that require
      the opt-out, as the allocation are passed different stacks and may cause
      issues in different layers.
      
      To address this issue, replace VM_NO_HUGE_VMAP with an opt-in flag,
      VM_ALLOW_HUGE_VMAP, so that users that benefit from huge pages could ask
      specificially.
      
      Also, remove vmalloc_no_huge() and add opt-in helper vmalloc_huge().
      
      Fixes: fac54e2b ("x86/Kconfig: Select HAVE_ARCH_HUGE_VMALLOC with HAVE_ARCH_HUGE_VMAP")
      Link: https://lore.kernel.org/netdev/14444103-d51b-0fb3-ee63-c3f182f0b546@molgen.mpg.de/"
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Reviewed-by: default avatarRik van Riel <riel@surriel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      559089e0
    • Linus Torvalds's avatar
      Merge tag 'spi-fix-v5.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi · b7f73403
      Linus Torvalds authored
      Pull spi fixes from Mark Brown:
       "A few more fixes for SPI, plus one new PCI ID for another Intel
        chipset.
      
        All device specific stuff"
      
      * tag 'spi-fix-v5.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
        spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controller
        spi: cadence-quadspi: fix incorrect supports_op() return value
        spi: intel: Add support for Raptor Lake-S SPI serial flash
        spi: spi-mtk-nor: initialize spi controller after resume
      b7f73403
    • Christian Brauner's avatar
      fs: fix acl translation · 705191b0
      Christian Brauner authored
      Last cycle we extended the idmapped mounts infrastructure to support
      idmapped mounts of idmapped filesystems (No such filesystem yet exist.).
      Since then, the meaning of an idmapped mount is a mount whose idmapping
      is different from the filesystems idmapping.
      
      While doing that work we missed to adapt the acl translation helpers.
      They still assume that checking for the identity mapping is enough.  But
      they need to use the no_idmapping() helper instead.
      
      Note, POSIX ACLs are always translated right at the userspace-kernel
      boundary using the caller's current idmapping and the initial idmapping.
      The order depends on whether we're coming from or going to userspace.
      The filesystem's idmapping doesn't matter at the border.
      
      Consequently, if a non-idmapped mount is passed we need to make sure to
      always pass the initial idmapping as the mount's idmapping and not the
      filesystem idmapping.  Since it's irrelevant here it would yield invalid
      ids and prevent setting acls for filesystems that are mountable in a
      userns and support posix acls (tmpfs and fuse).
      
      I verified the regression reported in [1] and verified that this patch
      fixes it.  A regression test will be added to xfstests in parallel.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=215849 [1]
      Fixes: bd303368 ("fs: support mapped mounts of mapped filesystems")
      Cc: Seth Forshee <sforshee@digitalocean.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: <stable@vger.kernel.org> # 5.17
      Cc: <regressions@lists.linux.dev>
      Signed-off-by: default avatarChristian Brauner (Microsoft) <brauner@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      705191b0
    • Eric Dumazet's avatar
      netlink: reset network and mac headers in netlink_dump() · 99c07327
      Eric Dumazet authored
      netlink_dump() is allocating an skb, reserves space in it
      but forgets to reset network header.
      
      This allows a BPF program, invoked later from sk_filter()
      to access uninitialized kernel memory from the reserved
      space.
      
      Theorically mac header reset could be omitted, because
      it is set to a special initial value.
      bpf_internal_load_pointer_neg_helper calls skb_mac_header()
      without checking skb_mac_header_was_set().
      Relying on skb->len not being too big seems fragile.
      We also could add a sanity check in bpf_internal_load_pointer_neg_helper()
      to avoid surprises in the future.
      
      syzbot report was:
      
      BUG: KMSAN: uninit-value in ___bpf_prog_run+0xa22b/0xb420 kernel/bpf/core.c:1637
       ___bpf_prog_run+0xa22b/0xb420 kernel/bpf/core.c:1637
       __bpf_prog_run32+0x121/0x180 kernel/bpf/core.c:1796
       bpf_dispatcher_nop_func include/linux/bpf.h:784 [inline]
       __bpf_prog_run include/linux/filter.h:626 [inline]
       bpf_prog_run include/linux/filter.h:633 [inline]
       __bpf_prog_run_save_cb+0x168/0x580 include/linux/filter.h:756
       bpf_prog_run_save_cb include/linux/filter.h:770 [inline]
       sk_filter_trim_cap+0x3bc/0x8c0 net/core/filter.c:150
       sk_filter include/linux/filter.h:905 [inline]
       netlink_dump+0xe0c/0x16c0 net/netlink/af_netlink.c:2276
       netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
       sock_recvmsg_nosec net/socket.c:948 [inline]
       sock_recvmsg net/socket.c:966 [inline]
       sock_read_iter+0x5a9/0x630 net/socket.c:1039
       do_iter_readv_writev+0xa7f/0xc70
       do_iter_read+0x52c/0x14c0 fs/read_write.c:786
       vfs_readv fs/read_write.c:906 [inline]
       do_readv+0x432/0x800 fs/read_write.c:943
       __do_sys_readv fs/read_write.c:1034 [inline]
       __se_sys_readv fs/read_write.c:1031 [inline]
       __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Uninit was stored to memory at:
       ___bpf_prog_run+0x96c/0xb420 kernel/bpf/core.c:1558
       __bpf_prog_run32+0x121/0x180 kernel/bpf/core.c:1796
       bpf_dispatcher_nop_func include/linux/bpf.h:784 [inline]
       __bpf_prog_run include/linux/filter.h:626 [inline]
       bpf_prog_run include/linux/filter.h:633 [inline]
       __bpf_prog_run_save_cb+0x168/0x580 include/linux/filter.h:756
       bpf_prog_run_save_cb include/linux/filter.h:770 [inline]
       sk_filter_trim_cap+0x3bc/0x8c0 net/core/filter.c:150
       sk_filter include/linux/filter.h:905 [inline]
       netlink_dump+0xe0c/0x16c0 net/netlink/af_netlink.c:2276
       netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
       sock_recvmsg_nosec net/socket.c:948 [inline]
       sock_recvmsg net/socket.c:966 [inline]
       sock_read_iter+0x5a9/0x630 net/socket.c:1039
       do_iter_readv_writev+0xa7f/0xc70
       do_iter_read+0x52c/0x14c0 fs/read_write.c:786
       vfs_readv fs/read_write.c:906 [inline]
       do_readv+0x432/0x800 fs/read_write.c:943
       __do_sys_readv fs/read_write.c:1034 [inline]
       __se_sys_readv fs/read_write.c:1031 [inline]
       __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Uninit was created at:
       slab_post_alloc_hook mm/slab.h:737 [inline]
       slab_alloc_node mm/slub.c:3244 [inline]
       __kmalloc_node_track_caller+0xde3/0x14f0 mm/slub.c:4972
       kmalloc_reserve net/core/skbuff.c:354 [inline]
       __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
       alloc_skb include/linux/skbuff.h:1158 [inline]
       netlink_dump+0x30f/0x16c0 net/netlink/af_netlink.c:2242
       netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
       sock_recvmsg_nosec net/socket.c:948 [inline]
       sock_recvmsg net/socket.c:966 [inline]
       sock_read_iter+0x5a9/0x630 net/socket.c:1039
       do_iter_readv_writev+0xa7f/0xc70
       do_iter_read+0x52c/0x14c0 fs/read_write.c:786
       vfs_readv fs/read_write.c:906 [inline]
       do_readv+0x432/0x800 fs/read_write.c:943
       __do_sys_readv fs/read_write.c:1034 [inline]
       __se_sys_readv fs/read_write.c:1031 [inline]
       __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      CPU: 0 PID: 3470 Comm: syz-executor751 Not tainted 5.17.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: db65a3aa ("netlink: Trim skb to alloc size to avoid MSG_TRUNC")
      Fixes: 9063e21f ("netlink: autosize skb lengthes")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Link: https://lore.kernel.org/r/20220415181442.551228-1-eric.dumazet@gmail.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      99c07327
    • Pengcheng Yang's avatar
      ipvs: correctly print the memory size of ip_vs_conn_tab · eba1a872
      Pengcheng Yang authored
      The memory size of ip_vs_conn_tab changed after we use hlist
      instead of list.
      
      Fixes: 731109e7 ("ipvs: use hlist instead of list")
      Signed-off-by: default avatarPengcheng Yang <yangpc@wangsu.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      eba1a872
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix broken IP multicast flooding · 4cf35a2b
      Vladimir Oltean authored
      When the user runs:
      bridge link set dev $br_port mcast_flood on
      
      this command should affect not only L2 multicast, but also IPv4 and IPv6
      multicast.
      
      In the Ocelot switch, unknown multicast gets flooded according to
      different PGIDs according to its type, and PGID_MC only handles L2
      multicast. Therefore, by leaving PGID_MCIPV4 and PGID_MCIPV6 at their
      default value of 0, unknown IP multicast traffic is never flooded.
      
      Fixes: 421741ea ("net: mscc: ocelot: offload bridge port flags to device")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/20220415151950.219660-1-vladimir.oltean@nxp.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4cf35a2b