--- /dev/null
+From c70222752228a62135cee3409dccefd494a24646 Mon Sep 17 00:00:00 2001
+From: Hangyu Hua <hbh25y@gmail.com>
+Date: Mon, 28 Feb 2022 16:36:39 +0800
+Subject: can: ems_usb: ems_usb_start_xmit(): fix double dev_kfree_skb() in error path
+
+From: Hangyu Hua <hbh25y@gmail.com>
+
+commit c70222752228a62135cee3409dccefd494a24646 upstream.
+
+There is no need to call dev_kfree_skb() when usb_submit_urb() fails
+beacause can_put_echo_skb() deletes the original skb and
+can_free_echo_skb() deletes the cloned skb.
+
+Link: https://lore.kernel.org/all/20220228083639.38183-1-hbh25y@gmail.com
+Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
+Cc: stable@vger.kernel.org
+Cc: Sebastian Haas <haas@ems-wuensche.com>
+Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/usb/ems_usb.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/net/can/usb/ems_usb.c
++++ b/drivers/net/can/usb/ems_usb.c
+@@ -823,7 +823,6 @@ static netdev_tx_t ems_usb_start_xmit(st
+
+ usb_unanchor_urb(urb);
+ usb_free_coherent(dev->udev, size, buf, urb->transfer_dma);
+- dev_kfree_skb(skb);
+
+ atomic_dec(&dev->active_tx_urbs);
+
--- /dev/null
+From d051cef784de4d54835f6b6836d98a8f6935772c Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Fri, 14 Jan 2022 18:28:53 +0800
+Subject: jffs2: fix memory leak in jffs2_do_mount_fs
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit d051cef784de4d54835f6b6836d98a8f6935772c upstream.
+
+If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
+we can observe the following kmemleak report:
+
+--------------------------------------------
+unreferenced object 0xffff88811b25a640 (size 64):
+ comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880
+ [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130
+ [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
+ [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
+ [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
+ [...]
+unreferenced object 0xffff88812c760000 (size 65536):
+ comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
+ hex dump (first 32 bytes):
+ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
+ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
+ backtrace:
+ [<ffffffffa493a449>] __kmalloc+0x6b9/0x910
+ [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130
+ [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
+ [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
+ [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
+ [...]
+--------------------------------------------
+
+This is because the resources allocated in jffs2_sum_init() are not
+released. Call jffs2_sum_exit() to release these resources to solve
+the problem.
+
+Fixes: e631ddba5887 ("[JFFS2] Add erase block summary support (mount time improvement)")
+Cc: stable@vger.kernel.org
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jffs2/build.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/jffs2/build.c
++++ b/fs/jffs2/build.c
+@@ -415,13 +415,15 @@ int jffs2_do_mount_fs(struct jffs2_sb_in
+ jffs2_free_ino_caches(c);
+ jffs2_free_raw_node_refs(c);
+ ret = -EIO;
+- goto out_free;
++ goto out_sum_exit;
+ }
+
+ jffs2_calc_trigger_levels(c);
+
+ return 0;
+
++ out_sum_exit:
++ jffs2_sum_exit(c);
+ out_free:
+ kvfree(c->blocks);
+
--- /dev/null
+From 9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Fri, 14 Jan 2022 18:28:54 +0800
+Subject: jffs2: fix memory leak in jffs2_scan_medium
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit 9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df upstream.
+
+If an error is returned in jffs2_scan_eraseblock() and some memory
+has been added to the jffs2_summary *s, we can observe the following
+kmemleak report:
+
+--------------------------------------------
+unreferenced object 0xffff88812b889c40 (size 64):
+ comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
+ hex dump (first 32 bytes):
+ 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.
+ 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................
+ backtrace:
+ [<ffffffffae93a3a3>] __kmalloc+0x613/0x910
+ [<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0
+ [<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794
+ [<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267
+ [<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30
+ [<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0
+ [<ffffffffb0315d64>] mtd_get_sb+0x254/0x400
+ [<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0
+ [<ffffffffb0316478>] get_tree_mtd+0x498/0x840
+ [<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30
+ [<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0
+ [<ffffffffaea7a98f>] path_mount+0x50f/0x1e50
+ [<ffffffffaea7c3d7>] do_mount+0x107/0x130
+ [<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0
+ [<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160
+ [<ffffffffb10142f5>] do_syscall_64+0x45/0x70
+unreferenced object 0xffff888114b54840 (size 32):
+ comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
+ hex dump (first 32 bytes):
+ c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............
+ 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.
+ backtrace:
+ [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
+ [<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90
+ [<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794
+ [...]
+unreferenced object 0xffff888114b57280 (size 32):
+ comm "mount", pid 692, jiffies 4294838393 (age 34.357s)
+ hex dump (first 32 bytes):
+ 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............
+ 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.
+ backtrace:
+ [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
+ [<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90
+ [<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794
+ [...]
+unreferenced object 0xffff8881116cd510 (size 16):
+ comm "mount", pid 692, jiffies 4294838395 (age 34.355s)
+ hex dump (first 16 bytes):
+ 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.
+ backtrace:
+ [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
+ [<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90
+ [<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794
+ [...]
+--------------------------------------------
+
+Therefore, we should call jffs2_sum_reset_collected(s) on exit to
+release the memory added in s. In addition, a new tag "out_buf" is
+added to prevent the NULL pointer reference caused by s being NULL.
+(thanks to Zhang Yi for this analysis)
+
+Fixes: e631ddba5887 ("[JFFS2] Add erase block summary support (mount time improvement)")
+Cc: stable@vger.kernel.org
+Co-developed-with: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jffs2/scan.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/jffs2/scan.c
++++ b/fs/jffs2/scan.c
+@@ -136,7 +136,7 @@ int jffs2_scan_medium(struct jffs2_sb_in
+ if (!s) {
+ JFFS2_WARNING("Can't allocate memory for summary\n");
+ ret = -ENOMEM;
+- goto out;
++ goto out_buf;
+ }
+ }
+
+@@ -275,13 +275,15 @@ int jffs2_scan_medium(struct jffs2_sb_in
+ }
+ ret = 0;
+ out:
++ jffs2_sum_reset_collected(s);
++ kfree(s);
++ out_buf:
+ if (buf_size)
+ kfree(flashbuf);
+ #ifndef __ECOS
+ else
+ mtd_unpoint(c->mtd, 0, c->mtd->size);
+ #endif
+- kfree(s);
+ return ret;
+ }
+
--- /dev/null
+From 4c7c44ee1650677fbe89d86edbad9497b7679b5c Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Tue, 28 Dec 2021 20:54:30 +0800
+Subject: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit 4c7c44ee1650677fbe89d86edbad9497b7679b5c upstream.
+
+When we mount a jffs2 image, assume that the first few blocks of
+the image are normal and contain at least one xattr-related inode,
+but the next block is abnormal. As a result, an error is returned
+in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then
+called in jffs2_build_filesystem() and then again in
+jffs2_do_fill_super().
+
+Finally we can observe the following report:
+ ==================================================================
+ BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac
+ Read of size 8 at addr ffff8881243384e0 by task mount/719
+
+ Call Trace:
+ dump_stack+0x115/0x16b
+ jffs2_clear_xattr_subsystem+0x95/0x6ac
+ jffs2_do_fill_super+0x84f/0xc30
+ jffs2_fill_super+0x2ea/0x4c0
+ mtd_get_sb+0x254/0x400
+ mtd_get_sb_by_nr+0x4f/0xd0
+ get_tree_mtd+0x498/0x840
+ jffs2_get_tree+0x25/0x30
+ vfs_get_tree+0x8d/0x2e0
+ path_mount+0x50f/0x1e50
+ do_mount+0x107/0x130
+ __se_sys_mount+0x1c5/0x2f0
+ __x64_sys_mount+0xc7/0x160
+ do_syscall_64+0x45/0x70
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ Allocated by task 719:
+ kasan_save_stack+0x23/0x60
+ __kasan_kmalloc.constprop.0+0x10b/0x120
+ kasan_slab_alloc+0x12/0x20
+ kmem_cache_alloc+0x1c0/0x870
+ jffs2_alloc_xattr_ref+0x2f/0xa0
+ jffs2_scan_medium.cold+0x3713/0x4794
+ jffs2_do_mount_fs.cold+0xa7/0x2253
+ jffs2_do_fill_super+0x383/0xc30
+ jffs2_fill_super+0x2ea/0x4c0
+ [...]
+
+ Freed by task 719:
+ kmem_cache_free+0xcc/0x7b0
+ jffs2_free_xattr_ref+0x78/0x98
+ jffs2_clear_xattr_subsystem+0xa1/0x6ac
+ jffs2_do_mount_fs.cold+0x5e6/0x2253
+ jffs2_do_fill_super+0x383/0xc30
+ jffs2_fill_super+0x2ea/0x4c0
+ [...]
+
+ The buggy address belongs to the object at ffff8881243384b8
+ which belongs to the cache jffs2_xattr_ref of size 48
+ The buggy address is located 40 bytes inside of
+ 48-byte region [ffff8881243384b8, ffff8881243384e8)
+ [...]
+ ==================================================================
+
+The triggering of the BUG is shown in the following stack:
+-----------------------------------------------------------
+jffs2_fill_super
+ jffs2_do_fill_super
+ jffs2_do_mount_fs
+ jffs2_build_filesystem
+ jffs2_scan_medium
+ jffs2_scan_eraseblock <--- ERROR
+ jffs2_clear_xattr_subsystem <--- free
+ jffs2_clear_xattr_subsystem <--- free again
+-----------------------------------------------------------
+
+An error is returned in jffs2_do_mount_fs(). If the error is returned
+by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to
+be executed. If the error is returned by jffs2_build_filesystem(), the
+jffs2_clear_xattr_subsystem() also does not need to be executed again.
+So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root'
+to fix this UAF problem.
+
+Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)")
+Cc: stable@vger.kernel.org
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jffs2/fs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/jffs2/fs.c
++++ b/fs/jffs2/fs.c
+@@ -602,8 +602,8 @@ out_root:
+ jffs2_free_ino_caches(c);
+ jffs2_free_raw_node_refs(c);
+ kvfree(c->blocks);
+- out_inohash:
+ jffs2_clear_xattr_subsystem(c);
++ out_inohash:
+ kfree(c->inocache_list);
+ out_wbuf:
+ jffs2_flash_cleanup(c);
--- /dev/null
+From 4e0906008cdb56381638aa17d9c32734eae6d37a Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Tue, 22 Mar 2022 14:45:59 -0700
+Subject: mempolicy: mbind_range() set_policy() after vma_merge()
+
+From: Hugh Dickins <hughd@google.com>
+
+commit 4e0906008cdb56381638aa17d9c32734eae6d37a upstream.
+
+v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced
+vma_merge() to mbind_range(); but unlike madvise, mlock and mprotect, it
+put a "continue" to next vma where its precedents go to update flags on
+current vma before advancing: that left vma with the wrong setting in the
+infamous vma_merge() case 8.
+
+v3.10 commit 1444f92c8498 ("mm: merging memory blocks resets mempolicy")
+tried to fix that in vma_adjust(), without fully understanding the issue.
+
+v3.11 commit 3964acd0dbec ("mm: mempolicy: fix mbind_range() &&
+vma_adjust() interaction") reverted that, and went about the fix in the
+right way, but chose to optimize out an unnecessary mpol_dup() with a
+prior mpol_equal() test. But on tmpfs, that also pessimized out the vital
+call to its ->set_policy(), leaving the new mbind unenforced.
+
+The user visible effect was that the pages got allocated on the local
+node (happened to be 0), after the mbind() caller had specifically
+asked for them to be allocated on node 1. There was not any page
+migration involved in the case reported: the pages simply got allocated
+on the wrong node.
+
+Just delete that optimization now (though it could be made conditional on
+vma not having a set_policy). Also remove the "next" variable: it turned
+out to be blameless, but also pointless.
+
+Link: https://lkml.kernel.org/r/319e4db9-64ae-4bca-92f0-ade85d342ff@google.com
+Fixes: 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() interaction")
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Acked-by: Oleg Nesterov <oleg@redhat.com>
+Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mempolicy.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -802,7 +802,6 @@ static int vma_replace_policy(struct vm_
+ static int mbind_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, struct mempolicy *new_pol)
+ {
+- struct vm_area_struct *next;
+ struct vm_area_struct *prev;
+ struct vm_area_struct *vma;
+ int err = 0;
+@@ -817,8 +816,7 @@ static int mbind_range(struct mm_struct
+ if (start > vma->vm_start)
+ prev = vma;
+
+- for (; vma && vma->vm_start < end; prev = vma, vma = next) {
+- next = vma->vm_next;
++ for (; vma && vma->vm_start < end; prev = vma, vma = vma->vm_next) {
+ vmstart = max(start, vma->vm_start);
+ vmend = min(end, vma->vm_end);
+
+@@ -832,10 +830,6 @@ static int mbind_range(struct mm_struct
+ new_pol, vma->vm_userfaultfd_ctx);
+ if (prev) {
+ vma = prev;
+- next = vma->vm_next;
+- if (mpol_equal(vma_policy(vma), new_pol))
+- continue;
+- /* vma_merge() joined vma && vma->next, case 8 */
+ goto replace;
+ }
+ if (vma->vm_start != vmstart) {
--- /dev/null
+From e53ac7374e64dede04d745ff0e70ff5048378d1f Mon Sep 17 00:00:00 2001
+From: Rik van Riel <riel@surriel.com>
+Date: Tue, 22 Mar 2022 14:44:09 -0700
+Subject: mm: invalidate hwpoison page cache page in fault path
+
+From: Rik van Riel <riel@surriel.com>
+
+commit e53ac7374e64dede04d745ff0e70ff5048378d1f upstream.
+
+Sometimes the page offlining code can leave behind a hwpoisoned clean
+page cache page. This can lead to programs being killed over and over
+and over again as they fault in the hwpoisoned page, get killed, and
+then get re-spawned by whatever wanted to run them.
+
+This is particularly embarrassing when the page was offlined due to
+having too many corrected memory errors. Now we are killing tasks due
+to them trying to access memory that probably isn't even corrupted.
+
+This problem can be avoided by invalidating the page from the page fault
+handler, which already has a branch for dealing with these kinds of
+pages. With this patch we simply pretend the page fault was successful
+if the page was invalidated, return to userspace, incur another page
+fault, read in the file from disk (to a new memory page), and then
+everything works again.
+
+Link: https://lkml.kernel.org/r/20220212213740.423efcea@imladris.surriel.com
+Signed-off-by: Rik van Riel <riel@surriel.com>
+Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
+Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -3676,11 +3676,16 @@ static vm_fault_t __do_fault(struct vm_f
+ return ret;
+
+ if (unlikely(PageHWPoison(vmf->page))) {
+- if (ret & VM_FAULT_LOCKED)
++ vm_fault_t poisonret = VM_FAULT_HWPOISON;
++ if (ret & VM_FAULT_LOCKED) {
++ /* Retry if a clean page was removed from the cache. */
++ if (invalidate_inode_page(vmf->page))
++ poisonret = 0;
+ unlock_page(vmf->page);
++ }
+ put_page(vmf->page);
+ vmf->page = NULL;
+- return VM_FAULT_HWPOISON;
++ return poisonret;
+ }
+
+ if (unlikely(!(ret & VM_FAULT_LOCKED)))
--- /dev/null
+From ddbc84f3f595cf1fc8234a191193b5d20ad43938 Mon Sep 17 00:00:00 2001
+From: Alistair Popple <apopple@nvidia.com>
+Date: Tue, 22 Mar 2022 14:43:26 -0700
+Subject: mm/pages_alloc.c: don't create ZONE_MOVABLE beyond the end of a node
+
+From: Alistair Popple <apopple@nvidia.com>
+
+commit ddbc84f3f595cf1fc8234a191193b5d20ad43938 upstream.
+
+ZONE_MOVABLE uses the remaining memory in each node. Its starting pfn
+is also aligned to MAX_ORDER_NR_PAGES. It is possible for the remaining
+memory in a node to be less than MAX_ORDER_NR_PAGES, meaning there is
+not enough room for ZONE_MOVABLE on that node.
+
+Unfortunately this condition is not checked for. This leads to
+zone_movable_pfn[] getting set to a pfn greater than the last pfn in a
+node.
+
+calculate_node_totalpages() then sets zone->present_pages to be greater
+than zone->spanned_pages which is invalid, as spanned_pages represents
+the maximum number of pages in a zone assuming no holes.
+
+Subsequently it is possible free_area_init_core() will observe a zone of
+size zero with present pages. In this case it will skip setting up the
+zone, including the initialisation of free_lists[].
+
+However populated_zone() checks zone->present_pages to see if a zone has
+memory available. This is used by iterators such as
+walk_zones_in_node(). pagetypeinfo_showfree() uses this to walk the
+free_list of each zone in each node, which are assumed to be initialised
+due to the zone not being empty.
+
+As free_area_init_core() never initialised the free_lists[] this results
+in the following kernel crash when trying to read /proc/pagetypeinfo:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000000
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI
+ CPU: 0 PID: 456 Comm: cat Not tainted 5.16.0 #461
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
+ RIP: 0010:pagetypeinfo_show+0x163/0x460
+ Code: 9e 82 e8 80 57 0e 00 49 8b 06 b9 01 00 00 00 4c 39 f0 75 16 e9 65 02 00 00 48 83 c1 01 48 81 f9 a0 86 01 00 0f 84 48 02 00 00 <48> 8b 00 4c 39 f0 75 e7 48 c7 c2 80 a2 e2 82 48 c7 c6 79 ef e3 82
+ RSP: 0018:ffffc90001c4bd10 EFLAGS: 00010003
+ RAX: 0000000000000000 RBX: ffff88801105f638 RCX: 0000000000000001
+ RDX: 0000000000000001 RSI: 000000000000068b RDI: ffff8880163dc68b
+ RBP: ffffc90001c4bd90 R08: 0000000000000001 R09: ffff8880163dc67e
+ R10: 656c6261766f6d6e R11: 6c6261766f6d6e55 R12: ffff88807ffb4a00
+ R13: ffff88807ffb49f8 R14: ffff88807ffb4580 R15: ffff88807ffb3000
+ FS: 00007f9c83eff5c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000000 CR3: 0000000013c8e000 CR4: 0000000000350ef0
+ Call Trace:
+ seq_read_iter+0x128/0x460
+ proc_reg_read_iter+0x51/0x80
+ new_sync_read+0x113/0x1a0
+ vfs_read+0x136/0x1d0
+ ksys_read+0x70/0xf0
+ __x64_sys_read+0x1a/0x20
+ do_syscall_64+0x3b/0xc0
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Fix this by checking that the aligned zone_movable_pfn[] does not exceed
+the end of the node, and if it does skip creating a movable zone on this
+node.
+
+Link: https://lkml.kernel.org/r/20220215025831.2113067-1-apopple@nvidia.com
+Fixes: 2a1e274acf0b ("Create the ZONE_MOVABLE zone")
+Signed-off-by: Alistair Popple <apopple@nvidia.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Acked-by: Mel Gorman <mgorman@techsingularity.net>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Zi Yan <ziy@nvidia.com>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/page_alloc.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -7402,10 +7402,17 @@ restart:
+
+ out2:
+ /* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
+- for (nid = 0; nid < MAX_NUMNODES; nid++)
++ for (nid = 0; nid < MAX_NUMNODES; nid++) {
++ unsigned long start_pfn, end_pfn;
++
+ zone_movable_pfn[nid] =
+ roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
+
++ get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
++ if (zone_movable_pfn[nid] >= end_pfn)
++ zone_movable_pfn[nid] = 0;
++ }
++
+ out:
+ /* restore the node_state */
+ node_states[N_MEMORY] = saved_node_state;
+++ /dev/null
-From 927728a34f11b5a27f4610bdb7068317d6fdc72a Mon Sep 17 00:00:00 2001
-From: Hui Wang <hui.wang@canonical.com>
-Date: Tue, 8 Mar 2022 19:00:42 +0800
-Subject: serial: sc16is7xx: Clear RS485 bits in the shutdown
-
-From: Hui Wang <hui.wang@canonical.com>
-
-commit 927728a34f11b5a27f4610bdb7068317d6fdc72a upstream.
-
-We tested RS485 function on an EVB which has SC16IS752, after
-finishing the test, we started the RS232 function test, but found the
-RTS is still working in the RS485 mode.
-
-That is because both startup and shutdown call port_update() to set
-the EFCR_REG, this will not clear the RS485 bits once the bits are set
-in the reconf_rs485(). To fix it, clear the RS485 bits in shutdown.
-
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Hui Wang <hui.wang@canonical.com>
-Link: https://lore.kernel.org/r/20220308110042.108451-1-hui.wang@canonical.com
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- drivers/tty/serial/sc16is7xx.c | 6 ++++--
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
---- a/drivers/tty/serial/sc16is7xx.c
-+++ b/drivers/tty/serial/sc16is7xx.c
-@@ -1055,10 +1055,12 @@ static void sc16is7xx_shutdown(struct ua
-
- /* Disable all interrupts */
- sc16is7xx_port_write(port, SC16IS7XX_IER_REG, 0);
-- /* Disable TX/RX */
-+ /* Disable TX/RX, clear auto RS485 and RTS invert */
- sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
- SC16IS7XX_EFCR_RXDISABLE_BIT |
-- SC16IS7XX_EFCR_TXDISABLE_BIT,
-+ SC16IS7XX_EFCR_TXDISABLE_BIT |
-+ SC16IS7XX_EFCR_AUTO_RS485_BIT |
-+ SC16IS7XX_EFCR_RTS_INVERT_BIT,
- SC16IS7XX_EFCR_RXDISABLE_BIT |
- SC16IS7XX_EFCR_TXDISABLE_BIT);
-
clk-uniphier-fix-fixed-rate-initialization.patch
ptrace-check-ptrace_o_suspend_seccomp-permission-on-ptrace_seize.patch
keys-fix-length-validation-in-keyctl_pkey_params_get_2.patch
-serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch
documentation-add-link-to-stable-release-candidate-tree.patch
documentation-update-stable-tree-link.patch
firmware-stratix10-svc-add-missing-callback-parameter-on-rsu.patch
pinctrl-samsung-drop-pin-banks-references-on-error-paths.patch
spi-mxic-fix-the-transmit-path.patch
mtd-rawnand-protect-access-to-rawnand-devices-while-in-suspend.patch
+can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch
+jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch
+jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch
+jffs2-fix-memory-leak-in-jffs2_scan_medium.patch
+mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch
+mm-invalidate-hwpoison-page-cache-page-in-fault-path.patch
+mempolicy-mbind_range-set_policy-after-vma_merge.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
