--- /dev/null
+From 4c3ccf0346288a7204250981df15b64837cbf463 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Jul 2021 14:21:18 +0100
+Subject: ARM: dts: versatile: Fix up interrupt controller node names
+
+From: Sudeep Holla <sudeep.holla@arm.com>
+
+[ Upstream commit 82a1c67554dff610d6be4e1982c425717b3c6a23 ]
+
+Once the new schema interrupt-controller/arm,vic.yaml is added, we get
+the below warnings:
+
+ arch/arm/boot/dts/versatile-ab.dt.yaml:
+ intc@10140000: $nodename:0: 'intc@10140000' does not match
+ '^interrupt-controller(@[0-9a-f,]+)*$'
+
+ arch/arm/boot/dts/versatile-ab.dt.yaml:
+ intc@10140000: 'clear-mask' does not match any of the regexes
+
+Fix the node names for the interrupt controller to conform
+to the standard node name interrupt-controller@.. Also drop invalid
+clear-mask property.
+
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Acked-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20210701132118.759454-1-sudeep.holla@arm.com'
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/versatile-ab.dts | 5 ++---
+ arch/arm/boot/dts/versatile-pb.dts | 2 +-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
+index 37bd41ff8dff..151c0220047d 100644
+--- a/arch/arm/boot/dts/versatile-ab.dts
++++ b/arch/arm/boot/dts/versatile-ab.dts
+@@ -195,16 +195,15 @@
+ #size-cells = <1>;
+ ranges;
+
+- vic: intc@10140000 {
++ vic: interrupt-controller@10140000 {
+ compatible = "arm,versatile-vic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x10140000 0x1000>;
+- clear-mask = <0xffffffff>;
+ valid-mask = <0xffffffff>;
+ };
+
+- sic: intc@10003000 {
++ sic: interrupt-controller@10003000 {
+ compatible = "arm,versatile-sic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+diff --git a/arch/arm/boot/dts/versatile-pb.dts b/arch/arm/boot/dts/versatile-pb.dts
+index 06a0fdf24026..e7e751a858d8 100644
+--- a/arch/arm/boot/dts/versatile-pb.dts
++++ b/arch/arm/boot/dts/versatile-pb.dts
+@@ -7,7 +7,7 @@
+
+ amba {
+ /* The Versatile PB is using more SIC IRQ lines than the AB */
+- sic: intc@10003000 {
++ sic: interrupt-controller@10003000 {
+ clear-mask = <0xffffffff>;
+ /*
+ * Valid interrupt lines mask according to
+--
+2.30.2
+
--- /dev/null
+From 92e101a89725baafe2fee776f20189c846b9de2c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Jul 2021 19:34:02 +0900
+Subject: cifs: fix the out of range assignment to bit fields in
+ parse_server_interfaces
+
+From: Hyunchul Lee <hyc.lee@gmail.com>
+
+[ Upstream commit c9c9c6815f9004ee1ec87401ed0796853bd70f1b ]
+
+Because the out of range assignment to bit fields
+are compiler-dependant, the fields could have wrong
+value.
+
+Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/smb2ops.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
+index b0b06eb86edf..81e087723777 100644
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -497,8 +497,8 @@ parse_server_interfaces(struct network_interface_info_ioctl_rsp *buf,
+ p = buf;
+ while (bytes_left >= sizeof(*p)) {
+ info->speed = le64_to_cpu(p->LinkSpeed);
+- info->rdma_capable = le32_to_cpu(p->Capability & RDMA_CAPABLE);
+- info->rss_capable = le32_to_cpu(p->Capability & RSS_CAPABLE);
++ info->rdma_capable = le32_to_cpu(p->Capability & RDMA_CAPABLE) ? 1 : 0;
++ info->rss_capable = le32_to_cpu(p->Capability & RSS_CAPABLE) ? 1 : 0;
+
+ cifs_dbg(FYI, "%s: adding iface %zu\n", __func__, *iface_count);
+ cifs_dbg(FYI, "%s: speed %zu bps\n", __func__, info->speed);
+--
+2.30.2
+
--- /dev/null
+From ed62c2db438b73fcfa1ca325f1cd7d69be9a6f88 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 14:54:19 +0000
+Subject: drm/ttm: add a check against null pointer dereference
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ]
+
+When calling ttm_range_man_fini(), 'man' may be uninitialized, which may
+cause a null pointer dereference bug.
+
+Fix this by checking if it is a null pointer.
+
+This log reveals it:
+
+[ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058
+[ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160
+[ 7.911826 ] Call Trace:
+[ 7.911826 ] radeon_ttm_fini+0x167/0x210
+[ 7.911826 ] radeon_bo_fini+0x15/0x40
+[ 7.913767 ] rs400_fini+0x55/0x80
+[ 7.914358 ] radeon_device_fini+0x3c/0x140
+[ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0
+[ 7.914358 ] radeon_driver_load_kms+0x13a/0x200
+[ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0
+[ 7.914358 ] drm_dev_register+0x1db/0x290
+[ 7.914358 ] radeon_pci_probe+0x16a/0x230
+[ 7.914358 ] local_pci_probe+0x4a/0xb0
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/ttm/ttm_range_manager.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c
+index 1da0e277c511..ce9d127edbb5 100644
+--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
++++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
+@@ -147,6 +147,9 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev,
+ struct drm_mm *mm = &rman->mm;
+ int ret;
+
++ if (!man)
++ return 0;
++
+ ttm_resource_manager_set_used(man, false);
+
+ ret = ttm_resource_manager_force_list_clean(bdev, man);
+--
+2.30.2
+
--- /dev/null
+From 36018a10080d8741d07b889e58c9ec71cde95e5d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Jul 2021 14:50:28 +0100
+Subject: firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow
+
+From: Sudeep Holla <sudeep.holla@arm.com>
+
+[ Upstream commit 7a691f16ccad05d770f813d9c4b4337a30c6d63f ]
+
+The scmi_linux_errmap buffer access index is supposed to depend on the
+array size to prevent element out of bounds access. It uses SCMI_ERR_MAX
+to check bounds but that can mismatch with the array size. It also
+changes the success into -EIO though scmi_linux_errmap is never used in
+case of success, it is expected to work for success case too.
+
+It is slightly confusing code as the negative of the error code
+is used as index to the buffer. Fix it by negating it at the start and
+make it more readable.
+
+Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/arm_scmi/driver.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
+index af4560dab6b4..6fa024d1dd99 100644
+--- a/drivers/firmware/arm_scmi/driver.c
++++ b/drivers/firmware/arm_scmi/driver.c
+@@ -43,7 +43,6 @@ enum scmi_error_codes {
+ SCMI_ERR_GENERIC = -8, /* Generic Error */
+ SCMI_ERR_HARDWARE = -9, /* Hardware Error */
+ SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
+- SCMI_ERR_MAX
+ };
+
+ /* List of all SCMI devices active in system */
+@@ -118,8 +117,10 @@ static const int scmi_linux_errmap[] = {
+
+ static inline int scmi_to_linux_errno(int errno)
+ {
+- if (errno < SCMI_SUCCESS && errno > SCMI_ERR_MAX)
+- return scmi_linux_errmap[-errno];
++ int err_idx = -errno;
++
++ if (err_idx >= SCMI_SUCCESS && err_idx < ARRAY_SIZE(scmi_linux_errmap))
++ return scmi_linux_errmap[err_idx];
+ return -EIO;
+ }
+
+--
+2.30.2
+
--- /dev/null
+From f62175dd44e19d316776c6525c4f5bb01aab7571 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Jul 2021 15:18:18 +0100
+Subject: firmware: arm_scmi: Fix range check for the maximum number of pending
+ messages
+
+From: Cristian Marussi <cristian.marussi@arm.com>
+
+[ Upstream commit bdb8742dc6f7c599c3d61959234fe4c23638727b ]
+
+SCMI message headers carry a sequence number and such field is sized to
+allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an
+acceptable maximum number of pending in-flight messages.
+
+Fix accordingly the checks performed on the value exported by transports
+in scmi_desc.max_msg
+
+Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com
+Reported-by: Vincent Guittot <vincent.guittot@linaro.org>
+Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
+[sudeep.holla: updated the patch title and error message]
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/arm_scmi/driver.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
+index 6fa024d1dd99..8c9663258d5d 100644
+--- a/drivers/firmware/arm_scmi/driver.c
++++ b/drivers/firmware/arm_scmi/driver.c
+@@ -615,8 +615,9 @@ static int __scmi_xfer_info_init(struct scmi_info *sinfo,
+ const struct scmi_desc *desc = sinfo->desc;
+
+ /* Pre-allocated messages, no more than what hdr.seq can support */
+- if (WARN_ON(desc->max_msg >= MSG_TOKEN_MAX)) {
+- dev_err(dev, "Maximum message of %d exceeds supported %ld\n",
++ if (WARN_ON(!desc->max_msg || desc->max_msg > MSG_TOKEN_MAX)) {
++ dev_err(dev,
++ "Invalid maximum messages %d, not in range [1 - %lu]\n",
+ desc->max_msg, MSG_TOKEN_MAX);
+ return -EINVAL;
+ }
+--
+2.30.2
+
--- /dev/null
+From c2de2725ebd6cce5a05aed3fbbc7cc351505313b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 21:27:08 -0700
+Subject: hfs: add lock nesting notation to hfs_find_init
+
+From: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+
+[ Upstream commit b3b2177a2d795e35dc11597b2609eb1e7e57e570 ]
+
+Syzbot reports a possible recursive lock in [1].
+
+This happens due to missing lock nesting information. From the logs, we
+see that a call to hfs_fill_super is made to mount the hfs filesystem.
+While searching for the root inode, the lock on the catalog btree is
+grabbed. Then, when the parent of the root isn't found, a call to
+__hfs_bnode_create is made to create the parent of the root. This
+eventually leads to a call to hfs_ext_read_extent which grabs a lock on
+the extents btree.
+
+Since the order of locking is catalog btree -> extents btree, this lock
+hierarchy does not lead to a deadlock.
+
+To tell lockdep that this locking is safe, we add nesting notation to
+distinguish between catalog btrees, extents btrees, and attributes
+btrees (for HFS+). This has already been done in hfsplus.
+
+Link: https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db [1]
+Link: https://lkml.kernel.org/r/20210701030756.58760-4-desmondcheongzx@gmail.com
+Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+Reported-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com
+Tested-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
+Cc: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/hfs/bfind.c | 14 +++++++++++++-
+ fs/hfs/btree.h | 7 +++++++
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c
+index 4af318fbda77..ef9498a6e88a 100644
+--- a/fs/hfs/bfind.c
++++ b/fs/hfs/bfind.c
+@@ -25,7 +25,19 @@ int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd)
+ fd->key = ptr + tree->max_key_len + 2;
+ hfs_dbg(BNODE_REFS, "find_init: %d (%p)\n",
+ tree->cnid, __builtin_return_address(0));
+- mutex_lock(&tree->tree_lock);
++ switch (tree->cnid) {
++ case HFS_CAT_CNID:
++ mutex_lock_nested(&tree->tree_lock, CATALOG_BTREE_MUTEX);
++ break;
++ case HFS_EXT_CNID:
++ mutex_lock_nested(&tree->tree_lock, EXTENTS_BTREE_MUTEX);
++ break;
++ case HFS_ATTR_CNID:
++ mutex_lock_nested(&tree->tree_lock, ATTR_BTREE_MUTEX);
++ break;
++ default:
++ return -EINVAL;
++ }
+ return 0;
+ }
+
+diff --git a/fs/hfs/btree.h b/fs/hfs/btree.h
+index 4ba45caf5939..0e6baee93245 100644
+--- a/fs/hfs/btree.h
++++ b/fs/hfs/btree.h
+@@ -13,6 +13,13 @@ typedef int (*btree_keycmp)(const btree_key *, const btree_key *);
+
+ #define NODE_HASH_SIZE 256
+
++/* B-tree mutex nested subclasses */
++enum hfs_btree_mutex_classes {
++ CATALOG_BTREE_MUTEX,
++ EXTENTS_BTREE_MUTEX,
++ ATTR_BTREE_MUTEX,
++};
++
+ /* A HFS BTree held in memory */
+ struct hfs_btree {
+ struct super_block *sb;
+--
+2.30.2
+
--- /dev/null
+From 4feb4af2598e0d069f2465be9bb7d9aa88696b69 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 21:27:01 -0700
+Subject: hfs: add missing clean-up in hfs_fill_super
+
+From: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+
+[ Upstream commit 16ee572eaf0d09daa4c8a755fdb71e40dbf8562d ]
+
+Patch series "hfs: fix various errors", v2.
+
+This series ultimately aims to address a lockdep warning in
+hfs_find_init reported by Syzbot [1].
+
+The work done for this led to the discovery of another bug, and the
+Syzkaller repro test also reveals an invalid memory access error after
+clearing the lockdep warning. Hence, this series is broken up into
+three patches:
+
+1. Add a missing call to hfs_find_exit for an error path in
+ hfs_fill_super
+
+2. Fix memory mapping in hfs_bnode_read by fixing calls to kmap
+
+3. Add lock nesting notation to tell lockdep that the observed locking
+ hierarchy is safe
+
+This patch (of 3):
+
+Before exiting hfs_fill_super, the struct hfs_find_data used in
+hfs_find_init should be passed to hfs_find_exit to be cleaned up, and to
+release the lock held on the btree.
+
+The call to hfs_find_exit is missing from an error path. We add it back
+in by consolidating calls to hfs_find_exit for error paths.
+
+Link: https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db [1]
+Link: https://lkml.kernel.org/r/20210701030756.58760-1-desmondcheongzx@gmail.com
+Link: https://lkml.kernel.org/r/20210701030756.58760-2-desmondcheongzx@gmail.com
+Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Shuah Khan <skhan@linuxfoundation.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/hfs/super.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/fs/hfs/super.c b/fs/hfs/super.c
+index 44d07c9e3a7f..12d9bae39363 100644
+--- a/fs/hfs/super.c
++++ b/fs/hfs/super.c
+@@ -420,14 +420,12 @@ static int hfs_fill_super(struct super_block *sb, void *data, int silent)
+ if (!res) {
+ if (fd.entrylength > sizeof(rec) || fd.entrylength < 0) {
+ res = -EIO;
+- goto bail;
++ goto bail_hfs_find;
+ }
+ hfs_bnode_read(fd.bnode, &rec, fd.entryoffset, fd.entrylength);
+ }
+- if (res) {
+- hfs_find_exit(&fd);
+- goto bail_no_root;
+- }
++ if (res)
++ goto bail_hfs_find;
+ res = -EINVAL;
+ root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
+ hfs_find_exit(&fd);
+@@ -443,6 +441,8 @@ static int hfs_fill_super(struct super_block *sb, void *data, int silent)
+ /* everything's okay */
+ return 0;
+
++bail_hfs_find:
++ hfs_find_exit(&fd);
+ bail_no_root:
+ pr_err("get root inode failed\n");
+ bail:
+--
+2.30.2
+
--- /dev/null
+From c9c62258ca762ed198fc19a79f167efba06c1b6a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 21:27:05 -0700
+Subject: hfs: fix high memory mapping in hfs_bnode_read
+
+From: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+
+[ Upstream commit 54a5ead6f5e2b47131a7385d0c0af18e7b89cb02 ]
+
+Pages that we read in hfs_bnode_read need to be kmapped into kernel
+address space. However, currently only the 0th page is kmapped. If the
+given offset + length exceeds this 0th page, then we have an invalid
+memory access.
+
+To fix this, we kmap relevant pages one by one and copy their relevant
+portions of data.
+
+An example of invalid memory access occurring without this fix can be seen
+in the following crash report:
+
+ ==================================================================
+ BUG: KASAN: use-after-free in memcpy include/linux/fortify-string.h:191 [inline]
+ BUG: KASAN: use-after-free in hfs_bnode_read+0xc4/0xe0 fs/hfs/bnode.c:26
+ Read of size 2 at addr ffff888125fdcffe by task syz-executor5/4634
+
+ CPU: 0 PID: 4634 Comm: syz-executor5 Not tainted 5.13.0-syzkaller #0
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+ Call Trace:
+ __dump_stack lib/dump_stack.c:79 [inline]
+ dump_stack+0x195/0x1f8 lib/dump_stack.c:120
+ print_address_description.constprop.0+0x1d/0x110 mm/kasan/report.c:233
+ __kasan_report mm/kasan/report.c:419 [inline]
+ kasan_report.cold+0x7b/0xd4 mm/kasan/report.c:436
+ check_region_inline mm/kasan/generic.c:180 [inline]
+ kasan_check_range+0x154/0x1b0 mm/kasan/generic.c:186
+ memcpy+0x24/0x60 mm/kasan/shadow.c:65
+ memcpy include/linux/fortify-string.h:191 [inline]
+ hfs_bnode_read+0xc4/0xe0 fs/hfs/bnode.c:26
+ hfs_bnode_read_u16 fs/hfs/bnode.c:34 [inline]
+ hfs_bnode_find+0x880/0xcc0 fs/hfs/bnode.c:365
+ hfs_brec_find+0x2d8/0x540 fs/hfs/bfind.c:126
+ hfs_brec_read+0x27/0x120 fs/hfs/bfind.c:165
+ hfs_cat_find_brec+0x19a/0x3b0 fs/hfs/catalog.c:194
+ hfs_fill_super+0xc13/0x1460 fs/hfs/super.c:419
+ mount_bdev+0x331/0x3f0 fs/super.c:1368
+ hfs_mount+0x35/0x40 fs/hfs/super.c:457
+ legacy_get_tree+0x10c/0x220 fs/fs_context.c:592
+ vfs_get_tree+0x93/0x300 fs/super.c:1498
+ do_new_mount fs/namespace.c:2905 [inline]
+ path_mount+0x13f5/0x20e0 fs/namespace.c:3235
+ do_mount fs/namespace.c:3248 [inline]
+ __do_sys_mount fs/namespace.c:3456 [inline]
+ __se_sys_mount fs/namespace.c:3433 [inline]
+ __x64_sys_mount+0x2b8/0x340 fs/namespace.c:3433
+ do_syscall_64+0x37/0xc0 arch/x86/entry/common.c:47
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x45e63a
+ Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 88 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
+ RSP: 002b:00007f9404d410d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
+ RAX: ffffffffffffffda RBX: 0000000020000248 RCX: 000000000045e63a
+ RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f9404d41120
+ RBP: 00007f9404d41120 R08: 00000000200002c0 R09: 0000000020000000
+ R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
+ R13: 0000000000000003 R14: 00000000004ad5d8 R15: 0000000000000000
+
+ The buggy address belongs to the page:
+ page:00000000dadbcf3e refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x125fdc
+ flags: 0x2fffc0000000000(node=0|zone=2|lastcpupid=0x3fff)
+ raw: 02fffc0000000000 ffffea000497f748 ffffea000497f6c8 0000000000000000
+ raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
+ page dumped because: kasan: bad access detected
+
+ Memory state around the buggy address:
+ ffff888125fdce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ffff888125fdcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ >ffff888125fdcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ^
+ ffff888125fdd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ffff888125fdd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ==================================================================
+
+Link: https://lkml.kernel.org/r/20210701030756.58760-3-desmondcheongzx@gmail.com
+Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
+Cc: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/hfs/bnode.c | 25 ++++++++++++++++++++-----
+ 1 file changed, 20 insertions(+), 5 deletions(-)
+
+diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
+index b63a4df7327b..c0a73a6ffb28 100644
+--- a/fs/hfs/bnode.c
++++ b/fs/hfs/bnode.c
+@@ -15,16 +15,31 @@
+
+ #include "btree.h"
+
+-void hfs_bnode_read(struct hfs_bnode *node, void *buf,
+- int off, int len)
++void hfs_bnode_read(struct hfs_bnode *node, void *buf, int off, int len)
+ {
+ struct page *page;
++ int pagenum;
++ int bytes_read;
++ int bytes_to_read;
++ void *vaddr;
+
+ off += node->page_offset;
+- page = node->page[0];
++ pagenum = off >> PAGE_SHIFT;
++ off &= ~PAGE_MASK; /* compute page offset for the first page */
+
+- memcpy(buf, kmap(page) + off, len);
+- kunmap(page);
++ for (bytes_read = 0; bytes_read < len; bytes_read += bytes_to_read) {
++ if (pagenum >= node->tree->pages_per_bnode)
++ break;
++ page = node->page[pagenum];
++ bytes_to_read = min_t(int, len - bytes_read, PAGE_SIZE - off);
++
++ vaddr = kmap_atomic(page);
++ memcpy(buf + bytes_read, vaddr + off, bytes_to_read);
++ kunmap_atomic(vaddr);
++
++ pagenum++;
++ off = 0; /* page offset only applies to the first page */
++ }
+ }
+
+ u16 hfs_bnode_read_u16(struct hfs_bnode *node, int off)
+--
+2.30.2
+
--- /dev/null
+From f0acdcfdd16b113de5bd9be4c6c7a1c61dd6288c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Jul 2021 09:58:04 -0700
+Subject: iomap: remove the length variable in iomap_seek_data
+
+From: Christoph Hellwig <hch@lst.de>
+
+[ Upstream commit 3ac1d426510f97ace05093ae9f2f710d9cbe6215 ]
+
+The length variable is rather pointless given that it can be trivially
+deduced from offset and size. Also the initial calculation can lead
+to KASAN warnings.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reported-by: Leizhen (ThunderTown) <thunder.leizhen@huawei.com>
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Darrick J. Wong <djwong@kernel.org>
+Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/iomap/seek.c | 16 ++++++----------
+ 1 file changed, 6 insertions(+), 10 deletions(-)
+
+diff --git a/fs/iomap/seek.c b/fs/iomap/seek.c
+index 107ee80c3568..271edcc84a28 100644
+--- a/fs/iomap/seek.c
++++ b/fs/iomap/seek.c
+@@ -186,27 +186,23 @@ loff_t
+ iomap_seek_data(struct inode *inode, loff_t offset, const struct iomap_ops *ops)
+ {
+ loff_t size = i_size_read(inode);
+- loff_t length = size - offset;
+ loff_t ret;
+
+ /* Nothing to be found before or beyond the end of the file. */
+ if (offset < 0 || offset >= size)
+ return -ENXIO;
+
+- while (length > 0) {
+- ret = iomap_apply(inode, offset, length, IOMAP_REPORT, ops,
+- &offset, iomap_seek_data_actor);
++ while (offset < size) {
++ ret = iomap_apply(inode, offset, size - offset, IOMAP_REPORT,
++ ops, &offset, iomap_seek_data_actor);
+ if (ret < 0)
+ return ret;
+ if (ret == 0)
+- break;
+-
++ return offset;
+ offset += ret;
+- length -= ret;
+ }
+
+- if (length <= 0)
+- return -ENXIO;
+- return offset;
++ /* We've reached the end of the file without finding data */
++ return -ENXIO;
+ }
+ EXPORT_SYMBOL_GPL(iomap_seek_data);
+--
+2.30.2
+
--- /dev/null
+From 4758afd0c4853bd563f1246f28869da840890843 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Jul 2021 09:58:04 -0700
+Subject: iomap: remove the length variable in iomap_seek_hole
+
+From: Christoph Hellwig <hch@lst.de>
+
+[ Upstream commit 49694d14ff68fa4b5f86019dbcfb44a8bd213e58 ]
+
+The length variable is rather pointless given that it can be trivially
+deduced from offset and size. Also the initial calculation can lead
+to KASAN warnings.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reported-by: Leizhen (ThunderTown) <thunder.leizhen@huawei.com>
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Darrick J. Wong <djwong@kernel.org>
+Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/iomap/seek.c | 9 +++------
+ 1 file changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/fs/iomap/seek.c b/fs/iomap/seek.c
+index 271edcc84a28..220c306167f7 100644
+--- a/fs/iomap/seek.c
++++ b/fs/iomap/seek.c
+@@ -140,23 +140,20 @@ loff_t
+ iomap_seek_hole(struct inode *inode, loff_t offset, const struct iomap_ops *ops)
+ {
+ loff_t size = i_size_read(inode);
+- loff_t length = size - offset;
+ loff_t ret;
+
+ /* Nothing to be found before or beyond the end of the file. */
+ if (offset < 0 || offset >= size)
+ return -ENXIO;
+
+- while (length > 0) {
+- ret = iomap_apply(inode, offset, length, IOMAP_REPORT, ops,
+- &offset, iomap_seek_hole_actor);
++ while (offset < size) {
++ ret = iomap_apply(inode, offset, size - offset, IOMAP_REPORT,
++ ops, &offset, iomap_seek_hole_actor);
+ if (ret < 0)
+ return ret;
+ if (ret == 0)
+ break;
+-
+ offset += ret;
+- length -= ret;
+ }
+
+ return offset;
+--
+2.30.2
+
--- /dev/null
+From e84c451b36446d7a4717ef6a3094c9aadd6779d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Jul 2021 09:45:06 +0300
+Subject: ipv6: allocate enough headroom in ip6_finish_output2()
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+[ Upstream commit 5796015fa968a3349027a27dcd04c71d95c53ba5 ]
+
+When TEE target mirrors traffic to another interface, sk_buff may
+not have enough headroom to be processed correctly.
+ip_finish_output2() detect this situation for ipv4 and allocates
+new skb with enogh headroom. However ipv6 lacks this logic in
+ip_finish_output2 and it leads to skb_under_panic:
+
+ skbuff: skb_under_panic: text:ffffffffc0866ad4 len:96 put:24
+ head:ffff97be85e31800 data:ffff97be85e317f8 tail:0x58 end:0xc0 dev:gre0
+ ------------[ cut here ]------------
+ kernel BUG at net/core/skbuff.c:110!
+ invalid opcode: 0000 [#1] SMP PTI
+ CPU: 2 PID: 393 Comm: kworker/2:2 Tainted: G OE 5.13.0 #13
+ Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.4 04/01/2014
+ Workqueue: ipv6_addrconf addrconf_dad_work
+ RIP: 0010:skb_panic+0x48/0x4a
+ Call Trace:
+ skb_push.cold.111+0x10/0x10
+ ipgre_header+0x24/0xf0 [ip_gre]
+ neigh_connected_output+0xae/0xf0
+ ip6_finish_output2+0x1a8/0x5a0
+ ip6_output+0x5c/0x110
+ nf_dup_ipv6+0x158/0x1000 [nf_dup_ipv6]
+ tee_tg6+0x2e/0x40 [xt_TEE]
+ ip6t_do_table+0x294/0x470 [ip6_tables]
+ nf_hook_slow+0x44/0xc0
+ nf_hook.constprop.34+0x72/0xe0
+ ndisc_send_skb+0x20d/0x2e0
+ ndisc_send_ns+0xd1/0x210
+ addrconf_dad_work+0x3c8/0x540
+ process_one_work+0x1d1/0x370
+ worker_thread+0x30/0x390
+ kthread+0x116/0x130
+ ret_from_fork+0x22/0x30
+
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/ip6_output.c | 28 ++++++++++++++++++++++++++++
+ 1 file changed, 28 insertions(+)
+
+diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
+index 341d0c7acc8b..781d3bc64b71 100644
+--- a/net/ipv6/ip6_output.c
++++ b/net/ipv6/ip6_output.c
+@@ -60,10 +60,38 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
+ {
+ struct dst_entry *dst = skb_dst(skb);
+ struct net_device *dev = dst->dev;
++ unsigned int hh_len = LL_RESERVED_SPACE(dev);
++ int delta = hh_len - skb_headroom(skb);
+ const struct in6_addr *nexthop;
+ struct neighbour *neigh;
+ int ret;
+
++ /* Be paranoid, rather than too clever. */
++ if (unlikely(delta > 0) && dev->header_ops) {
++ /* pskb_expand_head() might crash, if skb is shared */
++ if (skb_shared(skb)) {
++ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
++
++ if (likely(nskb)) {
++ if (skb->sk)
++ skb_set_owner_w(skb, skb->sk);
++ consume_skb(skb);
++ } else {
++ kfree_skb(skb);
++ }
++ skb = nskb;
++ }
++ if (skb &&
++ pskb_expand_head(skb, SKB_DATA_ALIGN(delta), 0, GFP_ATOMIC)) {
++ kfree_skb(skb);
++ skb = NULL;
++ }
++ if (!skb) {
++ IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTDISCARDS);
++ return -ENOMEM;
++ }
++ }
++
+ if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
+ struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
+
+--
+2.30.2
+
--- /dev/null
+From 41eff5208c7657a89caec5f3fe91c3ceef64a90b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Jul 2021 10:55:14 +0300
+Subject: ipv6: ip6_finish_output2: set sk into newly allocated nskb
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+[ Upstream commit 2d85a1b31dde84038ea07ad825c3d8d3e71f4344 ]
+
+skb_set_owner_w() should set sk not to old skb but to new nskb.
+
+Fixes: 5796015fa968 ("ipv6: allocate enough headroom in ip6_finish_output2()")
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Link: https://lore.kernel.org/r/70c0744f-89ae-1869-7e3e-4fa292158f4b@virtuozzo.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/ip6_output.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
+index 781d3bc64b71..72a673a43a75 100644
+--- a/net/ipv6/ip6_output.c
++++ b/net/ipv6/ip6_output.c
+@@ -74,7 +74,7 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
+
+ if (likely(nskb)) {
+ if (skb->sk)
+- skb_set_owner_w(skb, skb->sk);
++ skb_set_owner_w(nskb, skb->sk);
+ consume_skb(skb);
+ } else {
+ kfree_skb(skb);
+--
+2.30.2
+
--- /dev/null
+From f0b97fc3e6939342f48149b0fd99d591b0de36a2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 29 Jun 2021 19:53:28 +0800
+Subject: net/802/garp: fix memleak in garp_request_join()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 42ca63f980842918560b25f0244307fd83b4777c ]
+
+I got kmemleak report when doing fuzz test:
+
+BUG: memory leak
+unreferenced object 0xffff88810c909b80 (size 64):
+ comm "syz", pid 957, jiffies 4295220394 (age 399.090s)
+ hex dump (first 32 bytes):
+ 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 08 00 00 00 01 02 00 04 ................
+ backtrace:
+ [<00000000ca1f2e2e>] garp_request_join+0x285/0x3d0
+ [<00000000bf153351>] vlan_gvrp_request_join+0x15b/0x190
+ [<0000000024005e72>] vlan_dev_open+0x706/0x980
+ [<00000000dc20c4d4>] __dev_open+0x2bb/0x460
+ [<0000000066573004>] __dev_change_flags+0x501/0x650
+ [<0000000035b42f83>] rtnl_configure_link+0xee/0x280
+ [<00000000a5e69de0>] __rtnl_newlink+0xed5/0x1550
+ [<00000000a5258f4a>] rtnl_newlink+0x66/0x90
+ [<00000000506568ee>] rtnetlink_rcv_msg+0x439/0xbd0
+ [<00000000b7eaeae1>] netlink_rcv_skb+0x14d/0x420
+ [<00000000c373ce66>] netlink_unicast+0x550/0x750
+ [<00000000ec74ce74>] netlink_sendmsg+0x88b/0xda0
+ [<00000000381ff246>] sock_sendmsg+0xc9/0x120
+ [<000000008f6a2db3>] ____sys_sendmsg+0x6e8/0x820
+ [<000000008d9c1735>] ___sys_sendmsg+0x145/0x1c0
+ [<00000000aa39dd8b>] __sys_sendmsg+0xfe/0x1d0
+
+Calling garp_request_leave() after garp_request_join(), the attr->state
+is set to GARP_APPLICANT_VO, garp_attr_destroy() won't be called in last
+transmit event in garp_uninit_applicant(), the attr of applicant will be
+leaked. To fix this leak, iterate and free each attr of applicant before
+rerturning from garp_uninit_applicant().
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/802/garp.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/net/802/garp.c b/net/802/garp.c
+index 400bd857e5f5..f6012f8e59f0 100644
+--- a/net/802/garp.c
++++ b/net/802/garp.c
+@@ -203,6 +203,19 @@ static void garp_attr_destroy(struct garp_applicant *app, struct garp_attr *attr
+ kfree(attr);
+ }
+
++static void garp_attr_destroy_all(struct garp_applicant *app)
++{
++ struct rb_node *node, *next;
++ struct garp_attr *attr;
++
++ for (node = rb_first(&app->gid);
++ next = node ? rb_next(node) : NULL, node != NULL;
++ node = next) {
++ attr = rb_entry(node, struct garp_attr, node);
++ garp_attr_destroy(app, attr);
++ }
++}
++
+ static int garp_pdu_init(struct garp_applicant *app)
+ {
+ struct sk_buff *skb;
+@@ -609,6 +622,7 @@ void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl
+
+ spin_lock_bh(&app->lock);
+ garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
++ garp_attr_destroy_all(app);
+ garp_pdu_queue(app);
+ spin_unlock_bh(&app->lock);
+
+--
+2.30.2
+
--- /dev/null
+From 96ba69b1e555a2107d952993483bed1e7b142c5d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 29 Jun 2021 15:22:37 +0800
+Subject: net/802/mrp: fix memleak in mrp_request_join()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 996af62167d0e0ec69b938a3561e96f84ffff1aa ]
+
+I got kmemleak report when doing fuzz test:
+
+BUG: memory leak
+unreferenced object 0xffff88810c239500 (size 64):
+comm "syz-executor940", pid 882, jiffies 4294712870 (age 14.631s)
+hex dump (first 32 bytes):
+01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00 00 00 00 00 00 00 00 01 00 00 00 01 02 00 04 ................
+backtrace:
+[<00000000a323afa4>] slab_alloc_node mm/slub.c:2972 [inline]
+[<00000000a323afa4>] slab_alloc mm/slub.c:2980 [inline]
+[<00000000a323afa4>] __kmalloc+0x167/0x340 mm/slub.c:4130
+[<000000005034ca11>] kmalloc include/linux/slab.h:595 [inline]
+[<000000005034ca11>] mrp_attr_create net/802/mrp.c:276 [inline]
+[<000000005034ca11>] mrp_request_join+0x265/0x550 net/802/mrp.c:530
+[<00000000fcfd81f3>] vlan_mvrp_request_join+0x145/0x170 net/8021q/vlan_mvrp.c:40
+[<000000009258546e>] vlan_dev_open+0x477/0x890 net/8021q/vlan_dev.c:292
+[<0000000059acd82b>] __dev_open+0x281/0x410 net/core/dev.c:1609
+[<000000004e6dc695>] __dev_change_flags+0x424/0x560 net/core/dev.c:8767
+[<00000000471a09af>] rtnl_configure_link+0xd9/0x210 net/core/rtnetlink.c:3122
+[<0000000037a4672b>] __rtnl_newlink+0xe08/0x13e0 net/core/rtnetlink.c:3448
+[<000000008d5d0fda>] rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3488
+[<000000004882fe39>] rtnetlink_rcv_msg+0x369/0xa10 net/core/rtnetlink.c:5552
+[<00000000907e6c54>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
+[<00000000e7d7a8c4>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
+[<00000000e7d7a8c4>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
+[<00000000e0645d50>] netlink_sendmsg+0x78e/0xc90 net/netlink/af_netlink.c:1929
+[<00000000c24559b7>] sock_sendmsg_nosec net/socket.c:654 [inline]
+[<00000000c24559b7>] sock_sendmsg+0x139/0x170 net/socket.c:674
+[<00000000fc210bc2>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
+[<00000000be4577b5>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
+
+Calling mrp_request_leave() after mrp_request_join(), the attr->state
+is set to MRP_APPLICANT_VO, mrp_attr_destroy() won't be called in last
+TX event in mrp_uninit_applicant(), the attr of applicant will be leaked.
+To fix this leak, iterate and free each attr of applicant before rerturning
+from mrp_uninit_applicant().
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/802/mrp.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/net/802/mrp.c b/net/802/mrp.c
+index bea6e43d45a0..35e04cc5390c 100644
+--- a/net/802/mrp.c
++++ b/net/802/mrp.c
+@@ -292,6 +292,19 @@ static void mrp_attr_destroy(struct mrp_applicant *app, struct mrp_attr *attr)
+ kfree(attr);
+ }
+
++static void mrp_attr_destroy_all(struct mrp_applicant *app)
++{
++ struct rb_node *node, *next;
++ struct mrp_attr *attr;
++
++ for (node = rb_first(&app->mad);
++ next = node ? rb_next(node) : NULL, node != NULL;
++ node = next) {
++ attr = rb_entry(node, struct mrp_attr, node);
++ mrp_attr_destroy(app, attr);
++ }
++}
++
+ static int mrp_pdu_init(struct mrp_applicant *app)
+ {
+ struct sk_buff *skb;
+@@ -895,6 +908,7 @@ void mrp_uninit_applicant(struct net_device *dev, struct mrp_application *appl)
+
+ spin_lock_bh(&app->lock);
+ mrp_mad_event(app, MRP_EVENT_TX);
++ mrp_attr_destroy_all(app);
+ mrp_pdu_queue(app);
+ spin_unlock_bh(&app->lock);
+
+--
+2.30.2
+
--- /dev/null
+From 3a36b8de0e2ebc6e376f7cf9426d97ad17b31790 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 29 Jun 2021 07:12:45 -0700
+Subject: net: annotate data race around sk_ll_usec
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 0dbffbb5335a1e3aa6855e4ee317e25e669dd302 ]
+
+sk_ll_usec is read locklessly from sk_can_busy_loop()
+while another thread can change its value in sock_setsockopt()
+
+This is correct but needs annotations.
+
+BUG: KCSAN: data-race in __skb_try_recv_datagram / sock_setsockopt
+
+write to 0xffff88814eb5f904 of 4 bytes by task 14011 on cpu 0:
+ sock_setsockopt+0x1287/0x2090 net/core/sock.c:1175
+ __sys_setsockopt+0x14f/0x200 net/socket.c:2100
+ __do_sys_setsockopt net/socket.c:2115 [inline]
+ __se_sys_setsockopt net/socket.c:2112 [inline]
+ __x64_sys_setsockopt+0x62/0x70 net/socket.c:2112
+ do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+read to 0xffff88814eb5f904 of 4 bytes by task 14001 on cpu 1:
+ sk_can_busy_loop include/net/busy_poll.h:41 [inline]
+ __skb_try_recv_datagram+0x14f/0x320 net/core/datagram.c:273
+ unix_dgram_recvmsg+0x14c/0x870 net/unix/af_unix.c:2101
+ unix_seqpacket_recvmsg+0x5a/0x70 net/unix/af_unix.c:2067
+ ____sys_recvmsg+0x15d/0x310 include/linux/uio.h:244
+ ___sys_recvmsg net/socket.c:2598 [inline]
+ do_recvmmsg+0x35c/0x9f0 net/socket.c:2692
+ __sys_recvmmsg net/socket.c:2771 [inline]
+ __do_sys_recvmmsg net/socket.c:2794 [inline]
+ __se_sys_recvmmsg net/socket.c:2787 [inline]
+ __x64_sys_recvmmsg+0xcf/0x150 net/socket.c:2787
+ do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+value changed: 0x00000000 -> 0x00000101
+
+Reported by Kernel Concurrency Sanitizer on:
+CPU: 1 PID: 14001 Comm: syz-executor.3 Not tainted 5.13.0-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/busy_poll.h | 2 +-
+ net/core/sock.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
+index b001fa91c14e..716b7c5f6fdd 100644
+--- a/include/net/busy_poll.h
++++ b/include/net/busy_poll.h
+@@ -36,7 +36,7 @@ static inline bool net_busy_loop_on(void)
+
+ static inline bool sk_can_busy_loop(const struct sock *sk)
+ {
+- return sk->sk_ll_usec && !signal_pending(current);
++ return READ_ONCE(sk->sk_ll_usec) && !signal_pending(current);
+ }
+
+ bool sk_busy_loop_end(void *p, unsigned long start_time);
+diff --git a/net/core/sock.c b/net/core/sock.c
+index 7de51ea15cdf..d638c5361ed2 100644
+--- a/net/core/sock.c
++++ b/net/core/sock.c
+@@ -1164,7 +1164,7 @@ set_sndbuf:
+ if (val < 0)
+ ret = -EINVAL;
+ else
+- sk->sk_ll_usec = val;
++ WRITE_ONCE(sk->sk_ll_usec, val);
+ }
+ break;
+ #endif
+--
+2.30.2
+
--- /dev/null
+From d87510da0f7d9b8ad77b329a3f2f5932952fa898 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 May 2021 10:12:45 -0700
+Subject: rcu-tasks: Don't delete holdouts within trc_inspect_reader()
+
+From: Paul E. McKenney <paulmck@kernel.org>
+
+[ Upstream commit 1d10bf55d85d34eb73dd8263635f43fd72135d2d ]
+
+As Yanfei pointed out, although invoking trc_del_holdout() is safe
+from the viewpoint of the integrity of the holdout list itself,
+the put_task_struct() invoked by trc_del_holdout() can result in
+use-after-free errors due to later accesses to this task_struct structure
+by the RCU Tasks Trace grace-period kthread.
+
+This commit therefore removes this call to trc_del_holdout() from
+trc_inspect_reader() in favor of the grace-period thread's existing call
+to trc_del_holdout(), thus eliminating that particular class of
+use-after-free errors.
+
+Reported-by: "Xu, Yanfei" <yanfei.xu@windriver.com>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/rcu/tasks.h | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
+index 73bbe792fe1e..208acb286ec2 100644
+--- a/kernel/rcu/tasks.h
++++ b/kernel/rcu/tasks.h
+@@ -879,10 +879,9 @@ static bool trc_inspect_reader(struct task_struct *t, void *arg)
+ in_qs = likely(!t->trc_reader_nesting);
+ }
+
+- // Mark as checked. Because this is called from the grace-period
+- // kthread, also remove the task from the holdout list.
++ // Mark as checked so that the grace-period kthread will
++ // remove it from the holdout list.
+ t->trc_reader_checked = true;
+- trc_del_holdout(t);
+
+ if (in_qs)
+ return true; // Already in quiescent state, done!!!
+--
+2.30.2
+
--- /dev/null
+From 6bd294c18ca98ce0b2edb5218e9a3921b2e96ea2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 May 2021 11:28:40 -0700
+Subject: rcu-tasks: Don't delete holdouts within trc_wait_for_one_reader()
+
+From: Paul E. McKenney <paulmck@kernel.org>
+
+[ Upstream commit a9ab9cce9367a2cc02a3c7eb57a004dc0b8f380d ]
+
+Invoking trc_del_holdout() from within trc_wait_for_one_reader() is
+only a performance optimization because the RCU Tasks Trace grace-period
+kthread will eventually do this within check_all_holdout_tasks_trace().
+But it is not a particularly important performance optimization because
+it only applies to the grace-period kthread, of which there is but one.
+This commit therefore removes this invocation of trc_del_holdout() in
+favor of the one in check_all_holdout_tasks_trace() in the grace-period
+kthread.
+
+Reported-by: "Xu, Yanfei" <yanfei.xu@windriver.com>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/rcu/tasks.h | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
+index 208acb286ec2..b338f514ee5a 100644
+--- a/kernel/rcu/tasks.h
++++ b/kernel/rcu/tasks.h
+@@ -908,7 +908,6 @@ static void trc_wait_for_one_reader(struct task_struct *t,
+ // The current task had better be in a quiescent state.
+ if (t == current) {
+ t->trc_reader_checked = true;
+- trc_del_holdout(t);
+ WARN_ON_ONCE(t->trc_reader_nesting);
+ return;
+ }
+--
+2.30.2
+
--- /dev/null
+From ad86045738b3273584f5b94c5ca6f25b44bae726 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 29 Jun 2021 23:34:08 -0400
+Subject: sctp: move 198 addresses from unusable to private scope
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 1d11fa231cabeae09a95cb3e4cf1d9dd34e00f08 ]
+
+The doc draft-stewart-tsvwg-sctp-ipv4-00 that restricts 198 addresses
+was never published. These addresses as private addresses should be
+allowed to use in SCTP.
+
+As Michael Tuexen suggested, this patch is to move 198 addresses from
+unusable to private scope.
+
+Reported-by: Sérgio <surkamp@gmail.com>
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/sctp/constants.h | 4 +---
+ net/sctp/protocol.c | 3 ++-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
+index 122d9e2d8dfd..1ad049ac2add 100644
+--- a/include/net/sctp/constants.h
++++ b/include/net/sctp/constants.h
+@@ -340,8 +340,7 @@ enum {
+ #define SCTP_SCOPE_POLICY_MAX SCTP_SCOPE_POLICY_LINK
+
+ /* Based on IPv4 scoping <draft-stewart-tsvwg-sctp-ipv4-00.txt>,
+- * SCTP IPv4 unusable addresses: 0.0.0.0/8, 224.0.0.0/4, 198.18.0.0/24,
+- * 192.88.99.0/24.
++ * SCTP IPv4 unusable addresses: 0.0.0.0/8, 224.0.0.0/4, 192.88.99.0/24.
+ * Also, RFC 8.4, non-unicast addresses are not considered valid SCTP
+ * addresses.
+ */
+@@ -349,7 +348,6 @@ enum {
+ ((htonl(INADDR_BROADCAST) == a) || \
+ ipv4_is_multicast(a) || \
+ ipv4_is_zeronet(a) || \
+- ipv4_is_test_198(a) || \
+ ipv4_is_anycast_6to4(a))
+
+ /* Flags used for the bind address copy functions. */
+diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
+index 47fb87ce489f..940f1e257a90 100644
+--- a/net/sctp/protocol.c
++++ b/net/sctp/protocol.c
+@@ -397,7 +397,8 @@ static enum sctp_scope sctp_v4_scope(union sctp_addr *addr)
+ retval = SCTP_SCOPE_LINK;
+ } else if (ipv4_is_private_10(addr->v4.sin_addr.s_addr) ||
+ ipv4_is_private_172(addr->v4.sin_addr.s_addr) ||
+- ipv4_is_private_192(addr->v4.sin_addr.s_addr)) {
++ ipv4_is_private_192(addr->v4.sin_addr.s_addr) ||
++ ipv4_is_test_198(addr->v4.sin_addr.s_addr)) {
+ retval = SCTP_SCOPE_PRIVATE;
+ } else {
+ retval = SCTP_SCOPE_GLOBAL;
+--
+2.30.2
+
af_unix-fix-garbage-collect-vs-msg_peek.patch
workqueue-fix-uaf-in-pwq_unbound_release_workfn.patch
cgroup1-fix-leaked-context-root-causing-sporadic-null-deref-in-ltp.patch
+net-802-mrp-fix-memleak-in-mrp_request_join.patch
+net-802-garp-fix-memleak-in-garp_request_join.patch
+net-annotate-data-race-around-sk_ll_usec.patch
+sctp-move-198-addresses-from-unusable-to-private-sco.patch
+rcu-tasks-don-t-delete-holdouts-within-trc_inspect_r.patch
+rcu-tasks-don-t-delete-holdouts-within-trc_wait_for_.patch
+ipv6-allocate-enough-headroom-in-ip6_finish_output2.patch
+drm-ttm-add-a-check-against-null-pointer-dereference.patch
+hfs-add-missing-clean-up-in-hfs_fill_super.patch
+hfs-fix-high-memory-mapping-in-hfs_bnode_read.patch
+hfs-add-lock-nesting-notation-to-hfs_find_init.patch
+firmware-arm_scmi-fix-possible-scmi_linux_errmap-buf.patch
+firmware-arm_scmi-fix-range-check-for-the-maximum-nu.patch
+cifs-fix-the-out-of-range-assignment-to-bit-fields-i.patch
+iomap-remove-the-length-variable-in-iomap_seek_data.patch
+iomap-remove-the-length-variable-in-iomap_seek_hole.patch
+arm-dts-versatile-fix-up-interrupt-controller-node-n.patch
+ipv6-ip6_finish_output2-set-sk-into-newly-allocated-.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
