]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.4
authorSasha Levin <sashal@kernel.org>
Thu, 29 Jul 2021 11:58:13 +0000 (07:58 -0400)
committerSasha Levin <sashal@kernel.org>
Thu, 29 Jul 2021 11:58:13 +0000 (07:58 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.4/arm-dts-versatile-fix-up-interrupt-controller-node-n.patch [new file with mode: 0644]
queue-4.4/hfs-add-lock-nesting-notation-to-hfs_find_init.patch [new file with mode: 0644]
queue-4.4/hfs-add-missing-clean-up-in-hfs_fill_super.patch [new file with mode: 0644]
queue-4.4/hfs-fix-high-memory-mapping-in-hfs_bnode_read.patch [new file with mode: 0644]
queue-4.4/net-802-garp-fix-memleak-in-garp_request_join.patch [new file with mode: 0644]
queue-4.4/net-802-mrp-fix-memleak-in-mrp_request_join.patch [new file with mode: 0644]
queue-4.4/sctp-move-198-addresses-from-unusable-to-private-sco.patch [new file with mode: 0644]
queue-4.4/series

diff --git a/queue-4.4/arm-dts-versatile-fix-up-interrupt-controller-node-n.patch b/queue-4.4/arm-dts-versatile-fix-up-interrupt-controller-node-n.patch
new file mode 100644 (file)
index 0000000..d0d95c0
--- /dev/null
@@ -0,0 +1,72 @@
+From e9644f4217d3939d6c8fad46866542022dd3d173 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 3279bf1a17a1..9bedd2478787 100644
+--- a/arch/arm/boot/dts/versatile-ab.dts
++++ b/arch/arm/boot/dts/versatile-ab.dts
+@@ -93,16 +93,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 33a8eb28374e..3a23164c2c2d 100644
+--- a/arch/arm/boot/dts/versatile-pb.dts
++++ b/arch/arm/boot/dts/versatile-pb.dts
+@@ -6,7 +6,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
+
diff --git a/queue-4.4/hfs-add-lock-nesting-notation-to-hfs_find_init.patch b/queue-4.4/hfs-add-lock-nesting-notation-to-hfs_find_init.patch
new file mode 100644 (file)
index 0000000..491d816
--- /dev/null
@@ -0,0 +1,90 @@
+From 64df80efde1899ae352ce31160e5b219065e9835 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 de69d8a24f6d..7f2ef95dcd05 100644
+--- a/fs/hfs/bfind.c
++++ b/fs/hfs/bfind.c
+@@ -24,7 +24,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 2715f416b5a8..308b5f1af65b 100644
+--- a/fs/hfs/btree.h
++++ b/fs/hfs/btree.h
+@@ -12,6 +12,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
+
diff --git a/queue-4.4/hfs-add-missing-clean-up-in-hfs_fill_super.patch b/queue-4.4/hfs-add-missing-clean-up-in-hfs_fill_super.patch
new file mode 100644 (file)
index 0000000..2729126
--- /dev/null
@@ -0,0 +1,86 @@
+From 5ac03887a5d4081b84e7fa7104afa52e930e694a 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 4574fdd3d421..3eb815bb2c78 100644
+--- a/fs/hfs/super.c
++++ b/fs/hfs/super.c
+@@ -426,14 +426,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);
+@@ -449,6 +447,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
+
diff --git a/queue-4.4/hfs-fix-high-memory-mapping-in-hfs_bnode_read.patch b/queue-4.4/hfs-fix-high-memory-mapping-in-hfs_bnode_read.patch
new file mode 100644 (file)
index 0000000..ea5a01c
--- /dev/null
@@ -0,0 +1,139 @@
+From 4174e21e0e8426ec6e4c658e0625336b7b1b6791 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 221719eac5de..2cda99e61cae 100644
+--- a/fs/hfs/bnode.c
++++ b/fs/hfs/bnode.c
+@@ -14,16 +14,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
+
diff --git a/queue-4.4/net-802-garp-fix-memleak-in-garp_request_join.patch b/queue-4.4/net-802-garp-fix-memleak-in-garp_request_join.patch
new file mode 100644 (file)
index 0000000..085f6e1
--- /dev/null
@@ -0,0 +1,84 @@
+From 1e7db678801e2a21b0af8fc79cd1b5d8332c1f6f 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 b38ee6dcba45..5239b8f244e7 100644
+--- a/net/802/garp.c
++++ b/net/802/garp.c
+@@ -206,6 +206,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;
+@@ -612,6 +625,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
+
diff --git a/queue-4.4/net-802-mrp-fix-memleak-in-mrp_request_join.patch b/queue-4.4/net-802-mrp-fix-memleak-in-mrp_request_join.patch
new file mode 100644 (file)
index 0000000..4a0ddd4
--- /dev/null
@@ -0,0 +1,90 @@
+From 00ded3ed633228a2a26cc4695a165f637c810b45 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 72db2785ef2c..4ee3af3d400b 100644
+--- a/net/802/mrp.c
++++ b/net/802/mrp.c
+@@ -295,6 +295,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;
+@@ -900,6 +913,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
+
diff --git a/queue-4.4/sctp-move-198-addresses-from-unusable-to-private-sco.patch b/queue-4.4/sctp-move-198-addresses-from-unusable-to-private-sco.patch
new file mode 100644 (file)
index 0000000..56dcc14
--- /dev/null
@@ -0,0 +1,68 @@
+From be7f6d174e598338b60f6ba029d6d346ba6eeaf3 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 bf03bab93d9e..15cfec311500 100644
+--- a/include/net/sctp/constants.h
++++ b/include/net/sctp/constants.h
+@@ -344,8 +344,7 @@ typedef enum {
+ } sctp_scope_policy_t;
+ /* 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.
+  */
+@@ -353,7 +352,6 @@ typedef 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 b0e401dfe160..8c62792658b6 100644
+--- a/net/sctp/protocol.c
++++ b/net/sctp/protocol.c
+@@ -411,7 +411,8 @@ static sctp_scope_t 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
+
index a0bc239e4ed7858e54e71ffa0d82b0565742738d..546a0939c58edab42c479dc907892586e4478d1b 100644 (file)
@@ -1,3 +1,10 @@
 net-split-out-functions-related-to-registering-inflight-socket-files.patch
 af_unix-fix-garbage-collect-vs-msg_peek.patch
 workqueue-fix-uaf-in-pwq_unbound_release_workfn.patch
+net-802-mrp-fix-memleak-in-mrp_request_join.patch
+net-802-garp-fix-memleak-in-garp_request_join.patch
+sctp-move-198-addresses-from-unusable-to-private-sco.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
+arm-dts-versatile-fix-up-interrupt-controller-node-n.patch