From c9c5599c6a9b6cf24e110b0bcc6a449870e3b91c Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 1 Apr 2022 14:57:21 +0200 Subject: [PATCH] 4.9-stable patches added patches: can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch jffs2-fix-memory-leak-in-jffs2_scan_medium.patch jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch mempolicy-mbind_range-set_policy-after-vma_merge.patch mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch --- ...x-double-dev_kfree_skb-in-error-path.patch | 34 ++++++ ...fix-memory-leak-in-jffs2_do_mount_fs.patch | 71 +++++++++++ ...fix-memory-leak-in-jffs2_scan_medium.patch | 110 ++++++++++++++++++ ...-free-in-jffs2_clear_xattr_subsystem.patch | 107 +++++++++++++++++ ...ind_range-set_policy-after-vma_merge.patch | 79 +++++++++++++ ...one_movable-beyond-the-end-of-a-node.patch | 105 +++++++++++++++++ ...7xx-clear-rs485-bits-in-the-shutdown.patch | 42 ------- queue-4.9/series | 7 +- 8 files changed, 512 insertions(+), 43 deletions(-) create mode 100644 queue-4.9/can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch create mode 100644 queue-4.9/jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch create mode 100644 queue-4.9/jffs2-fix-memory-leak-in-jffs2_scan_medium.patch create mode 100644 queue-4.9/jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch create mode 100644 queue-4.9/mempolicy-mbind_range-set_policy-after-vma_merge.patch create mode 100644 queue-4.9/mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch delete mode 100644 queue-4.9/serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch diff --git a/queue-4.9/can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch b/queue-4.9/can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch new file mode 100644 index 00000000000..208b3334bd3 --- /dev/null +++ b/queue-4.9/can-ems_usb-ems_usb_start_xmit-fix-double-dev_kfree_skb-in-error-path.patch @@ -0,0 +1,34 @@ +From c70222752228a62135cee3409dccefd494a24646 Mon Sep 17 00:00:00 2001 +From: Hangyu Hua +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 + +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 +Signed-off-by: Hangyu Hua +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -834,7 +834,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); + diff --git a/queue-4.9/jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch b/queue-4.9/jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch new file mode 100644 index 00000000000..1cb3e18b46d --- /dev/null +++ b/queue-4.9/jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch @@ -0,0 +1,71 @@ +From d051cef784de4d54835f6b6836d98a8f6935772c Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Fri, 14 Jan 2022 18:28:53 +0800 +Subject: jffs2: fix memory leak in jffs2_do_mount_fs + +From: Baokun Li + +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: + [] kmem_cache_alloc_trace+0x584/0x880 + [] jffs2_sum_init+0x86/0x130 + [] jffs2_do_mount_fs+0x798/0xac0 + [] jffs2_do_fill_super+0x383/0xc30 + [] 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: + [] __kmalloc+0x6b9/0x910 + [] jffs2_sum_init+0xd7/0x130 + [] jffs2_do_mount_fs+0x798/0xac0 + [] jffs2_do_fill_super+0x383/0xc30 + [] 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 +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-4.9/jffs2-fix-memory-leak-in-jffs2_scan_medium.patch b/queue-4.9/jffs2-fix-memory-leak-in-jffs2_scan_medium.patch new file mode 100644 index 00000000000..e34b7be9873 --- /dev/null +++ b/queue-4.9/jffs2-fix-memory-leak-in-jffs2_scan_medium.patch @@ -0,0 +1,110 @@ +From 9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Fri, 14 Jan 2022 18:28:54 +0800 +Subject: jffs2: fix memory leak in jffs2_scan_medium + +From: Baokun Li + +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: + [] __kmalloc+0x613/0x910 + [] jffs2_sum_add_dirent_mem+0x5c/0xa0 + [] jffs2_scan_medium.cold+0x36e5/0x4794 + [] jffs2_do_mount_fs.cold+0xa7/0x2267 + [] jffs2_do_fill_super+0x383/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 +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: + [] kmem_cache_alloc_trace+0x584/0x880 + [] jffs2_sum_add_inode_mem+0x54/0x90 + [] 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: + [] kmem_cache_alloc_trace+0x584/0x880 + [] jffs2_sum_add_xattr_mem+0x54/0x90 + [] 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: + [] kmem_cache_alloc_trace+0x584/0x880 + [] jffs2_sum_add_xref_mem+0x54/0x90 + [] 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 +Signed-off-by: Baokun Li +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } + +@@ -274,13 +274,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; + } + diff --git a/queue-4.9/jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch b/queue-4.9/jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch new file mode 100644 index 00000000000..e9aadb2a43b --- /dev/null +++ b/queue-4.9/jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch @@ -0,0 +1,107 @@ +From 4c7c44ee1650677fbe89d86edbad9497b7679b5c Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Tue, 28 Dec 2021 20:54:30 +0800 +Subject: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem + +From: Baokun Li + +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 +Signed-off-by: Baokun Li +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + fs/jffs2/fs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/jffs2/fs.c ++++ b/fs/jffs2/fs.c +@@ -596,8 +596,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); diff --git a/queue-4.9/mempolicy-mbind_range-set_policy-after-vma_merge.patch b/queue-4.9/mempolicy-mbind_range-set_policy-after-vma_merge.patch new file mode 100644 index 00000000000..4e7dda2cf2b --- /dev/null +++ b/queue-4.9/mempolicy-mbind_range-set_policy-after-vma_merge.patch @@ -0,0 +1,79 @@ +From 4e0906008cdb56381638aa17d9c32734eae6d37a Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Tue, 22 Mar 2022 14:45:59 -0700 +Subject: mempolicy: mbind_range() set_policy() after vma_merge() + +From: Hugh Dickins + +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 +Acked-by: Oleg Nesterov +Reviewed-by: Liam R. Howlett +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mempolicy.c | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -734,7 +734,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; +@@ -750,8 +749,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); + +@@ -765,10 +763,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) { diff --git a/queue-4.9/mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch b/queue-4.9/mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch new file mode 100644 index 00000000000..9c68403cee7 --- /dev/null +++ b/queue-4.9/mm-pages_alloc.c-don-t-create-zone_movable-beyond-the-end-of-a-node.patch @@ -0,0 +1,105 @@ +From ddbc84f3f595cf1fc8234a191193b5d20ad43938 Mon Sep 17 00:00:00 2001 +From: Alistair Popple +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 + +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 +Acked-by: David Hildenbrand +Acked-by: Mel Gorman +Cc: John Hubbard +Cc: Zi Yan +Cc: Anshuman Khandual +Cc: Oscar Salvador +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/page_alloc.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/page_alloc.c ++++ b/mm/page_alloc.c +@@ -6267,10 +6267,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; diff --git a/queue-4.9/serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch b/queue-4.9/serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch deleted file mode 100644 index d71bc510b8f..00000000000 --- a/queue-4.9/serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 927728a34f11b5a27f4610bdb7068317d6fdc72a Mon Sep 17 00:00:00 2001 -From: Hui Wang -Date: Tue, 8 Mar 2022 19:00:42 +0800 -Subject: serial: sc16is7xx: Clear RS485 bits in the shutdown - -From: Hui Wang - -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: -Signed-off-by: Hui Wang -Link: https://lore.kernel.org/r/20220308110042.108451-1-hui.wang@canonical.com -Signed-off-by: Greg Kroah-Hartman ---- - 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); - diff --git a/queue-4.9/series b/queue-4.9/series index 7fa47097bbf..3ccf0f8cc05 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -12,6 +12,11 @@ iio-inkern-apply-consumer-scale-on-iio_val_int-cases.patch iio-inkern-make-a-best-effort-on-offset-calculation.patch clk-uniphier-fix-fixed-rate-initialization.patch ptrace-check-ptrace_o_suspend_seccomp-permission-on-ptrace_seize.patch -serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch sunrpc-avoid-race-between-mod_timer-and-del_timer_sync.patch nfsd-prevent-underflow-in-nfssvc_decode_writeargs.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 +mempolicy-mbind_range-set_policy-after-vma_merge.patch -- 2.47.3