Skip to content
Snippets Groups Projects
  1. May 07, 2022
    • Zhang Qiao's avatar
      cpuset: Fix unsafe lock order between cpuset lock and cpuslock · 9fcc65d0
      Zhang Qiao authored
      stable inclusion
      from linux-4.19.236
      commit aa44002e7db25f333ddf412fb81e8db6c100841a
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      The backport commit 4eec5fe1c680a ("cgroup/cpuset: Fix a race
      between cpuset_attach() and cpu hotplug") looks suspicious since
      it comes before commit d74b27d6 ("cgroup/cpuset: Change
      cpuset_rwsem and hotplug lock order") v5.4-rc1~176^2~30 when
      the locking order was: cpuset lock, cpus lock.
      
      Fix it with the correct locking order and reduce the cpus locking
      range because only set_cpus_allowed_ptr() needs the protection of
      cpus lock.
      
      Fixes: 4eec5fe1c680a ("cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug")
      Reported-by: default avatarMichal Koutný <mkoutny@suse.com>
      Signed-off-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      9fcc65d0
    • Eric Dumazet's avatar
      tcp: make tcp_read_sock() more robust · 5d2ba004
      Eric Dumazet authored
      stable inclusion
      from linux-4.19.236
      commit 9c90c0c62b5b5878f32400338983878a5345b050
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit e3d5ea2c011ecb16fb94c56a659364e6b30fac94 ]
      
      If recv_actor() returns an incorrect value, tcp_read_sock()
      might loop forever.
      
      Instead, issue a one time warning and make sure to make progress.
      
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/r/20220302161723.3910001-2-eric.dumazet@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      5d2ba004
    • Yan Yan's avatar
      xfrm: Fix xfrm migrate issues when address family changes · 504cf1ff
      Yan Yan authored
      stable inclusion
      from linux-4.19.236
      commit f82fdf0230c3ea639306f35daaac7fca11a48a7a
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit e03c3bba351f99ad932e8f06baa9da1afc418e02 ]
      
      xfrm_migrate cannot handle address family change of an xfrm_state.
      The symptons are the xfrm_state will be migrated to a wrong address,
      and sending as well as receiving packets wil be broken.
      
      This commit fixes it by breaking the original xfrm_state_clone
      method into two steps so as to update the props.family before
      running xfrm_init_state. As the result, xfrm_state's inner mode,
      outer mode, type and IP header length in xfrm_state_migrate can
      be updated with the new address family.
      
      Tested with additions to Android's kernel unit test suite:
      https://android-review.googlesource.com/c/kernel/tests/+/1885354
      
      
      
      Signed-off-by: default avatarYan Yan <evitayan@google.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      504cf1ff
    • Kai Lueke's avatar
      Revert "xfrm: state and policy should fail if XFRMA_IF_ID 0" · 8fca9e9d
      Kai Lueke authored
      stable inclusion
      from linux-4.19.236
      commit c8c9220cc0fb0dcdcce140533cc46128bd836347
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      CVE: NA
      
      --------------------------------
      
      commit a3d9001b4e287fc043e5539d03d71a32ab114bcb upstream.
      
      This reverts commit 68ac0f3810e76a853b5f7b90601a05c3048b8b54 because ID
      0 was meant to be used for configuring the policy/state without
      matching for a specific interface (e.g., Cilium is affected, see
      https://github.com/cilium/cilium/pull/18789 and
      https://github.com/cilium/cilium/pull/19019
      
      ).
      
      Signed-off-by: default avatarKai Lueke <kailueke@linux.microsoft.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      8fca9e9d
    • Josh Triplett's avatar
      ext4: add check to prevent attempting to resize an fs with sparse_super2 · fb435f3b
      Josh Triplett authored
      stable inclusion
      from linux-4.19.235
      commit 056d829499d3e9b5bb2c4e9a1d96d4e4f77b5ae2
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit b1489186cc8391e0c1e342f9fbc3eedf6b944c61 upstream.
      
      The in-kernel ext4 resize code doesn't support filesystem with the
      sparse_super2 feature. It fails with errors like this and doesn't finish
      the resize:
      EXT4-fs (loop0): resizing filesystem from 16640 to 7864320 blocks
      EXT4-fs warning (device loop0): verify_reserved_gdb:760: reserved GDT 2 missing grp 1 (32770)
      EXT4-fs warning (device loop0): ext4_resize_fs:2111: error (-22) occurred during file system resize
      EXT4-fs (loop0): resized filesystem to 2097152
      
      To reproduce:
      mkfs.ext4 -b 4096 -I 256 -J size=32 -E resize=$((256*1024*1024)) -O sparse_super2 ext4.img 65M
      truncate -s 30G ext4.img
      mount ext4.img /mnt
      python3 -c 'import fcntl, os, struct ; fd = os.open("/mnt", os.O_RDONLY | os.O_DIRECTORY) ; fcntl.ioctl(fd, 0x40086610, struct.pack("Q", 30 * 1024 * 1024 * 1024 // 4096), False) ; os.close(fd)'
      dmesg | tail
      e2fsck ext4.img
      
      The userspace resize2fs tool has a check for this case: it checks if the
      filesystem has sparse_super2 set and if the kernel provides
      /sys/fs/ext4/features/sparse_super2. However, the former check requires
      manually reading and parsing the filesystem superblock.
      
      Detect this case in ext4_resize_begin and error out early with a clear
      error message.
      
      Signed-off-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Link: https://lore.kernel.org/r/74b8ae78405270211943cd7393e65586c5faeed1.1623093259.git.josh@joshtriplett.org
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      fb435f3b
    • suresh kumar's avatar
      net-sysfs: add check for netdevice being present to speed_show · 7be896bf
      suresh kumar authored
      stable inclusion
      from linux-4.19.235
      commit 75fc8363227a999e8f3d17e2eb28dce5600dcd3f
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
      
      When bringing down the netdevice or system shutdown, a panic can be
      triggered while accessing the sysfs path because the device is already
      removed.
      
          [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
          [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
          ...
          [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
          [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
      
          crash> bt
          ...
          PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
          ...
           #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
              [exception RIP: dma_pool_alloc+0x1ab]
              RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
              RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
              RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
              RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
              R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
              R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
              ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
          #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
          #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
          #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
          #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
          #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
          #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
          #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
          #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
          #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
          #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
          #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
          #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
          #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
          #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
          #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
          #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
          #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
      
          crash> net_device.state ffff89443b0c0000
            state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
      
      To prevent this scenario, we also make sure that the netdevice is present.
      
      Signed-off-by: default avatarsuresh kumar <suresh2514@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      7be896bf
    • Hugh Dickins's avatar
      memfd: fix F_SEAL_WRITE after shmem huge page allocated · 3322f20f
      Hugh Dickins authored
      stable inclusion
      from linux-4.19.233
      commit 463c2accd61fe8c664dfcb9d9de50f632363ad28
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      CVE: NA
      
      --------------------------------
      
      commit f2b277c4d1c63a85127e8aa2588e9cc3bd21cb99 upstream.
      
      Wangyong reports: after enabling tmpfs filesystem to support transparent
      hugepage with the following command:
      
        echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled
      
      the docker program tries to add F_SEAL_WRITE through the following
      command, but it fails unexpectedly with errno EBUSY:
      
        fcntl(5, F_ADD_SEALS, F_SEAL_WRITE) = -1.
      
      That is because memfd_tag_pins() and memfd_wait_for_pins() were never
      updated for shmem huge pages: checking page_mapcount() against
      page_count() is hopeless on THP subpages - they need to check
      total_mapcount() against page_count() on THP heads only.
      
      Make memfd_tag_pins() (compared > 1) as strict as memfd_wait_for_pins()
      (compared != 1): either can be justified, but given the non-atomic
      total_mapcount() calculation, it is better now to be strict.  Bear in
      mind that total_mapcount() itself scans all of the THP subpages, when
      choosing to take an XA_CHECK_SCHED latency break.
      
      Also fix the unlikely xa_is_value() case in memfd_wait_for_pins(): if a
      page has been swapped out since memfd_tag_pins(), then its refcount must
      have fallen, and so it can safely be untagged.
      
      Link: https://lkml.kernel.org/r/a4f79248-df75-2c8c-3df-ba3317ccb5da@google.com
      
      
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Reported-by: default avatarwangyong <wang.yong12@zte.com.cn>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
      Cc: CGEL ZTE <cgel.zte@gmail.com>
      Cc: Kirill A. Shutemov <kirill@shutemov.name>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Yang Yang <yang.yang29@zte.com.cn>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      3322f20f
    • Lukas Wunner's avatar
      PCI: pciehp: Fix infinite loop in IRQ handler upon power fault · e0440916
      Lukas Wunner authored
      stable inclusion
      from linux-4.19.233
      commit ff27f7d0333cff89ec85c419f431aca1b38fb16a
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      CVE: NA
      
      --------------------------------
      
      commit 23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12 upstream.
      
      The Power Fault Detected bit in the Slot Status register differs from
      all other hotplug events in that it is sticky:  It can only be cleared
      after turning off slot power.  Per PCIe r5.0, sec. 6.7.1.8:
      
        If a power controller detects a main power fault on the hot-plug slot,
        it must automatically set its internal main power fault latch [...].
        The main power fault latch is cleared when software turns off power to
        the hot-plug slot.
      
      The stickiness used to cause interrupt storms and infinite loops which
      were fixed in 2009 by commits 5651c48c ("PCI pciehp: fix power fault
      interrupt storm problem") and 99f0169c ("PCI: pciehp: enable
      software notification on empty slots").
      
      Unfortunately in 2020 the infinite loop issue was inadvertently
      reintroduced by commit 8edf5332 ("PCI: pciehp: Fix MSI interrupt
      race"):  The hardirq handler pciehp_isr() clears the PFD bit until
      pciehp's power_fault_detected flag is set.  That happens in the IRQ
      thread pciehp_ist(), which never learns of the event because the hardirq
      handler is stuck in an infinite loop.  Fix by setting the
      power_fault_detected flag already in the hardirq handler.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=214989
      Link: https://lore.kernel.org/linux-pci/DM8PR11MB5702255A6A92F735D90A4446868B9@DM8PR11MB5702.namprd11.prod.outlook.com
      Fixes: 8edf5332 ("PCI: pciehp: Fix MSI interrupt race")
      Link: https://lore.kernel.org/r/66eaeef31d4997ceea357ad93259f290ededecfd.1637187226.git.lukas@wunner.de
      
      
      Reported-by: default avatarJoseph Bao <joseph.bao@intel.com>
      Tested-by: default avatarJoseph Bao <joseph.bao@intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v4.19+
      Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
      [sudip: adjust context]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      e0440916
    • Florian Westphal's avatar
      netfilter: nf_queue: fix possible use-after-free · 856bec9c
      Florian Westphal authored
      stable inclusion
      from linux-4.19.233
      commit 34dc4a6a7f261736ef7183868a5bddad31c7f9e3
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit c3873070247d9e3c7a6b0cf9bf9b45e8018427b1 upstream.
      
      Eric Dumazet says:
        The sock_hold() side seems suspect, because there is no guarantee
        that sk_refcnt is not already 0.
      
      On failure, we cannot queue the packet and need to indicate an
      error.  The packet will be dropped by the caller.
      
      v2: split skb prefetch hunk into separate change
      
      Fixes: 271b72c7 ("udp: RCU handling for Unicast packets.")
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      856bec9c
    • Florian Westphal's avatar
      netfilter: nf_queue: don't assume sk is full socket · 7078f0dd
      Florian Westphal authored
      stable inclusion
      from linux-4.19.233
      commit 6d9719ef61a99d1ed750b510d32620a6c4bb7397
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit 747670fd9a2d1b7774030dba65ca022ba442ce71 upstream.
      
      There is no guarantee that state->sk refers to a full socket.
      
      If refcount transitions to 0, sock_put calls sk_free which then ends up
      with garbage fields.
      
      I'd like to thank Oleksandr Natalenko and Jiri Benc for considerable
      debug work and pointing out state->sk oddities.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Tested-by: default avatarOleksandr Natalenko <oleksandr@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      7078f0dd
    • Leon Romanovsky's avatar
      xfrm: enforce validity of offload input flags · 48c4b4b5
      Leon Romanovsky authored
      stable inclusion
      from linux-4.19.233
      commit 94c115d1380400f0001640619244dfe7a3a04772
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit 7c76ecd9c99b6e9a771d813ab1aa7fa428b3ade1 upstream.
      
      struct xfrm_user_offload has flags variable that received user input,
      but kernel didn't check if valid bits were provided. It caused a situation
      where not sanitized input was forwarded directly to the drivers.
      
      For example, XFRM_OFFLOAD_IPV6 define that was exposed, was used by
      strongswan, but not implemented in the kernel at all.
      
      As a solution, check and sanitize input flags to forward
      XFRM_OFFLOAD_INBOUND to the drivers.
      
      Fixes: d77e38e6 ("xfrm: Add an IPsec hardware offloading API")
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      48c4b4b5
    • Antony Antony's avatar
      xfrm: fix the if_id check in changelink · 8db3cf08
      Antony Antony authored
      stable inclusion
      from linux-4.19.233
      commit 33c4a43021acfb91e289b2d92e2db0f4a8fcf41e
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit 6d0d95a1c2b07270870e7be16575c513c29af3f1 upstream.
      
      if_id will be always 0, because it was not yet initialized.
      
      Fixes: 8dce43919566 ("xfrm: interface with if_id 0 should return error")
      Reported-by: default avatarPavel Machek <pavel@denx.de>
      Signed-off-by: default avatarAntony Antony <antony.antony@secunet.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      8db3cf08
    • Eric Dumazet's avatar
      netfilter: fix use-after-free in __nf_register_net_hook() · 2d3caf24
      Eric Dumazet authored
      stable inclusion
      from linux-4.19.233
      commit bdd8fc1b826e6f23963f5bef3f7431c6188ec954
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit 56763f12b0f02706576a088e85ef856deacc98a0 upstream.
      
      We must not dereference @new_hooks after nf_hook_mutex has been released,
      because other threads might have freed our allocated hooks already.
      
      BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
      BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
      BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
      Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430
      
      CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      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+0x8d/0x336 mm/kasan/report.c:255
       __kasan_report mm/kasan/report.c:442 [inline]
       kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
       nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
       hooks_validate net/netfilter/core.c:171 [inline]
       __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
       nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
       nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
       nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
       synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
       xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
       check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
       find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
       translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
       do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
       do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
       nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
       ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024
       rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084
       __sys_setsockopt+0x2db/0x610 net/socket.c:2180
       __do_sys_setsockopt net/socket.c:2191 [inline]
       __se_sys_setsockopt net/socket.c:2188 [inline]
       __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f65a1ace7d9
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9
      RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
      RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130
      R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000
       </TASK>
      
      The buggy address belongs to the page:
      page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8
      flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as freed
      page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993
       prep_new_page mm/page_alloc.c:2434 [inline]
       get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
       __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
       __alloc_pages_node include/linux/gfp.h:572 [inline]
       alloc_pages_node include/linux/gfp.h:595 [inline]
       kmalloc_large_node+0x62/0x130 mm/slub.c:4438
       __kmalloc_node+0x35a/0x4a0 mm/slub.c:4454
       kmalloc_node include/linux/slab.h:604 [inline]
       kvmalloc_node+0x97/0x100 mm/util.c:580
       kvmalloc include/linux/slab.h:731 [inline]
       kvzalloc include/linux/slab.h:739 [inline]
       allocate_hook_entries_size net/netfilter/core.c:61 [inline]
       nf_hook_entries_grow+0x140/0x780 net/netfilter/core.c:128
       __nf_register_net_hook+0x144/0x820 net/netfilter/core.c:429
       nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
       nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
       nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
       synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
       xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
       check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
       find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
       translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
       do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
       do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
       nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
      page last free stack trace:
       reset_page_owner include/linux/page_owner.h:24 [inline]
       free_pages_prepare mm/page_alloc.c:1352 [inline]
       free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1404
       free_unref_page_prepare mm/page_alloc.c:3325 [inline]
       free_unref_page+0x19/0x690 mm/page_alloc.c:3404
       kvfree+0x42/0x50 mm/util.c:613
       rcu_do_batch kernel/rcu/tree.c:2527 [inline]
       rcu_core+0x7b1/0x1820 kernel/rcu/tree.c:2778
       __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
      
      Memory state around the buggy address:
       ffff88801c1a7f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff88801c1a7f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      >ffff88801c1a8000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                         ^
       ffff88801c1a8080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff88801c1a8100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      
      Fixes: 2420b79f ("netfilter: debug: check for sorted array")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      2d3caf24
    • Jiri Bohac's avatar
      xfrm: fix MTU regression · 52dfb991
      Jiri Bohac authored
      stable inclusion
      from linux-4.19.233
      commit 20fe64c54412ca42efb9ba07f856ed8cac6e007e
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      commit 6596a0229541270fb8d38d989f91b78838e5e9da upstream.
      
      Commit 749439bf ("ipv6: fix udpv6
      sendmsg crash caused by too small MTU") breaks PMTU for xfrm.
      
      A Packet Too Big ICMPv6 message received in response to an ESP
      packet will prevent all further communication through the tunnel
      if the reported MTU minus the ESP overhead is smaller than 1280.
      
      E.g. in a case of a tunnel-mode ESP with sha256/aes the overhead
      is 92 bytes. Receiving a PTB with MTU of 1371 or less will result
      in all further packets in the tunnel dropped. A ping through the
      tunnel fails with "ping: sendmsg: Invalid argument".
      
      Apparently the MTU on the xfrm route is smaller than 1280 and
      fails the check inside ip6_setup_cork() added by 749439bf.
      
      We found this by debugging USGv6/ipv6ready failures. Failing
      tests are: "Phase-2 Interoperability Test Scenario IPsec" /
      5.3.11 and 5.4.11 (Tunnel Mode: Fragmentation).
      
      Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm:
      xfrm_state_mtu should return at least 1280 for ipv6") attempted
      to fix this but caused another regression in TCP MSS calculations
      and had to be reverted.
      
      The patch below fixes the situation by dropping the MTU
      check and instead checking for the underflows described in the
      749439bf commit message.
      
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Fixes: 749439bf ("ipv6: fix udpv6 sendmsg crash caused by too small MTU")
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      52dfb991
    • Ronnie Sahlberg's avatar
      cifs: fix double free race when mount fails in cifs_get_root() · 7959a470
      Ronnie Sahlberg authored
      stable inclusion
      from linux-4.19.233
      commit 2fe0e281f7ad0a62259649764228227dd6b2561d
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit 3d6cc9898efdfb062efb74dc18cfc700e082f5d5 ]
      
      When cifs_get_root() fails during cifs_smb3_do_mount() we call
      deactivate_locked_super() which eventually will call delayed_free() which
      will free the context.
      In this situation we should not proceed to enter the out: section in
      cifs_smb3_do_mount() and free the same resources a second time.
      
      [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
      
      [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           OE     5.17.0-rc3+ #4
      [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
      [Thu Feb 10 12:59:06 2022] Call Trace:
      [Thu Feb 10 12:59:06 2022]  <IRQ>
      [Thu Feb 10 12:59:06 2022]  dump_stack_lvl+0x5d/0x78
      [Thu Feb 10 12:59:06 2022]  print_address_description.constprop.0+0x24/0x150
      [Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  kasan_report.cold+0x7d/0x117
      [Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  __asan_load8+0x86/0xa0
      [Thu Feb 10 12:59:06 2022]  rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  rcu_core+0x547/0xca0
      [Thu Feb 10 12:59:06 2022]  ? call_rcu+0x3c0/0x3c0
      [Thu Feb 10 12:59:06 2022]  ? __this_cpu_preempt_check+0x13/0x20
      [Thu Feb 10 12:59:06 2022]  ? lock_is_held_type+0xea/0x140
      [Thu Feb 10 12:59:06 2022]  rcu_core_si+0xe/0x10
      [Thu Feb 10 12:59:06 2022]  __do_softirq+0x1d4/0x67b
      [Thu Feb 10 12:59:06 2022]  __irq_exit_rcu+0x100/0x150
      [Thu Feb 10 12:59:06 2022]  irq_exit_rcu+0xe/0x30
      [Thu Feb 10 12:59:06 2022]  sysvec_hyperv_stimer0+0x9d/0xc0
      ...
      [Thu Feb 10 12:59:07 2022] Freed by task 58179:
      [Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
      [Thu Feb 10 12:59:07 2022]  kasan_set_track+0x25/0x30
      [Thu Feb 10 12:59:07 2022]  kasan_set_free_info+0x24/0x40
      [Thu Feb 10 12:59:07 2022]  ____kasan_slab_free+0x137/0x170
      [Thu Feb 10 12:59:07 2022]  __kasan_slab_free+0x12/0x20
      [Thu Feb 10 12:59:07 2022]  slab_free_freelist_hook+0xb3/0x1d0
      [Thu Feb 10 12:59:07 2022]  kfree+0xcd/0x520
      [Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0x149/0xbe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
      [Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
      [Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
      [Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
      [Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
      [Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [Thu Feb 10 12:59:07 2022] Last potentially related work creation:
      [Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
      [Thu Feb 10 12:59:07 2022]  __kasan_record_aux_stack+0xb6/0xc0
      [Thu Feb 10 12:59:07 2022]  kasan_record_aux_stack_noalloc+0xb/0x10
      [Thu Feb 10 12:59:07 2022]  call_rcu+0x76/0x3c0
      [Thu Feb 10 12:59:07 2022]  cifs_umount+0xce/0xe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  cifs_kill_sb+0xc8/0xe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  deactivate_locked_super+0x5d/0xd0
      [Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
      [Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
      [Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
      [Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
      [Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
      [Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Reported-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Reviewed-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      7959a470
  2. May 06, 2022
  3. Apr 29, 2022
  4. Apr 28, 2022
  5. Apr 26, 2022