July 2021 - Linux-stable-mirror

[PATCH 4.14] mac80211: fix memory corruption in EAPOL handling

by Davis Mosenkovs

Commit 557bb37533a3 ("mac80211: do not accept/forward invalid EAPOL frames") uses skb_mac_header() before eth_type_trans() is called leading to incorrect pointer, the pointer gets written to. This issue has appeared during backporting to 4.4, 4.9 and 4.14. Fixes: 557bb37533a3 ("mac80211: do not accept/forward invalid EAPOL frames") Link: https://lore.kernel.org/r/CAHQn7pKcyC_jYmGyTcPCdk9xxATwW5QPNph=bsZV8d-HPwNs… Cc: <stable(a)vger.kernel.org> # 4.14.x Signed-off-by: Davis Mosenkovs <davis(a)mosenkovs.lv> --- net/mac80211/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index ac2c52709e1c..87926c6fe0bf 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -2404,7 +2404,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx) #endif if (skb) { - struct ethhdr *ehdr = (void *)skb_mac_header(skb); + struct ethhdr *ehdr = (struct ethhdr *)skb->data; /* deliver to local stack */ skb->protocol = eth_type_trans(skb, dev); -- 2.25.1

3 years, 5 months

2
1
0 0

[PATCH stable 4.4 4.9] can: gw: synchronize rcu operations before removing gw job entry

by Oliver Hartkopp

From: Oliver Hartkopp <socketcan(a)hartkopp.net> commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream. can_can_gw_rcv() is called under RCU protection, so after calling can_rx_unregister(), we have to call synchronize_rcu in order to wait for any RCU read-side critical sections to finish before removing the kmem_cache entry with the referenced gw job entry. Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing") Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- net/can/gw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/can/gw.c b/net/can/gw.c index 81650affa3fa..1867000f8a65 100644 --- a/net/can/gw.c +++ b/net/can/gw.c @@ -495,10 +495,11 @@ static int cgw_notifier(struct notifier_block *nb, hlist_for_each_entry_safe(gwj, nx, &cgw_list, list) { if (gwj->src.dev == dev || gwj->dst.dev == dev) { hlist_del(&gwj->list); cgw_unregister_filter(gwj); + synchronize_rcu(); kmem_cache_free(cgw_cache, gwj); } } } @@ -939,10 +940,11 @@ static void cgw_remove_all_jobs(void) ASSERT_RTNL(); hlist_for_each_entry_safe(gwj, nx, &cgw_list, list) { hlist_del(&gwj->list); cgw_unregister_filter(gwj); + synchronize_rcu(); kmem_cache_free(cgw_cache, gwj); } } static int cgw_remove_job(struct sk_buff *skb, struct nlmsghdr *nlh) @@ -1006,10 +1008,11 @@ static int cgw_remove_job(struct sk_buff *skb, struct nlmsghdr *nlh) if (memcmp(&gwj->ccgw, &ccgw, sizeof(ccgw))) continue; hlist_del(&gwj->list); cgw_unregister_filter(gwj); + synchronize_rcu(); kmem_cache_free(cgw_cache, gwj); err = 0; break; } -- 2.30.2

3 years, 5 months

2
2
0 0

FAILED: patch "[PATCH] fuse: reject internal errno" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 Mon Sep 17 00:00:00 2001 From: Miklos Szeredi <mszeredi(a)redhat.com> Date: Tue, 22 Jun 2021 09:15:35 +0200 Subject: [PATCH] fuse: reject internal errno Don't allow userspace to report errors that could be kernel-internal. Reported-by: Anatoly Trosinenko <anatoly.trosinenko(a)gmail.com> Fixes: 334f485df85a ("[PATCH] FUSE - device functions") Cc: <stable(a)vger.kernel.org> # v2.6.14 Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 6e63bcba2a40..b8d58aa08206 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -1867,7 +1867,7 @@ static ssize_t fuse_dev_do_write(struct fuse_dev *fud, } err = -EINVAL; - if (oh.error <= -1000 || oh.error > 0) + if (oh.error <= -512 || oh.error > 0) goto copy_finish; spin_lock(&fpq->lock);

3 years, 5 months

3
2
0 0

FAILED: patch "[PATCH] serial: mvebu-uart: fix calculation of clock divisor" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 9078204ca5c33ba20443a8623a41a68a9995a70d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali(a)kernel.org> Date: Fri, 25 Jun 2021 00:49:00 +0200 Subject: [PATCH] serial: mvebu-uart: fix calculation of clock divisor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The clock divisor should be rounded to the closest value. Signed-off-by: Pali Rohár <pali(a)kernel.org> Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Cc: stable(a)vger.kernel.org # 0e4cf69ede87 ("serial: mvebu-uart: clarify the baud rate derivation") Link: https://lore.kernel.org/r/20210624224909.6350-2-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c index 04c41689d81c..f3ecbcf495ee 100644 --- a/drivers/tty/serial/mvebu-uart.c +++ b/drivers/tty/serial/mvebu-uart.c @@ -463,7 +463,7 @@ static int mvebu_uart_baud_rate_set(struct uart_port *port, unsigned int baud) * makes use of D to configure the desired baudrate. */ m_divisor = OSAMP_DEFAULT_DIVISOR; - d_divisor = DIV_ROUND_UP(port->uartclk, baud * m_divisor); + d_divisor = DIV_ROUND_CLOSEST(port->uartclk, baud * m_divisor); brdv = readl(port->membase + UART_BRDV); brdv &= ~BRDV_BAUD_MASK;

3 years, 5 months

3
2
0 0

[Backport for 5.10.y PATCH 0/7] Patches for 5.10.y

by Hanjun Guo

Hi Greg, Sasha, Patches below are some collections of bugfixes, those fixes are found when we are using the stable 5.10 kernel, please consider to apply them, I also Cced the author and maintainer for each patch to see if any objections. Patch 2/7 will fix the failure of LTP test case 'move_pages 12', and patch 3/7 is not a bugfix but a preparation for later bugfixes, other patches are obvious bugfixes. Gulam Mohamed (1): scsi: iscsi: Fix race condition between login and sync thread Jens Axboe (1): io_uring: convert io_buffer_idr to XArray Matthew Wilcox (Oracle) (1): io_uring: Convert personality_idr to XArray Mauricio Faria de Oliveira (1): loop: fix I/O error on fsync() in detached loop devices Mike Christie (1): scsi: iscsi: Fix iSCSI cls conn state Oscar Salvador (1): mm,hwpoison: return -EBUSY when migration fails Yejune Deng (1): io_uring: simplify io_remove_personalities() drivers/block/loop.c | 3 + drivers/scsi/libiscsi.c | 26 +------- drivers/scsi/scsi_transport_iscsi.c | 28 ++++++++- fs/io_uring.c | 116 +++++++++++++++--------------------- include/scsi/scsi_transport_iscsi.h | 1 + mm/memory-failure.c | 6 +- 6 files changed, 85 insertions(+), 95 deletions(-) -- 1.7.12.4

3 years, 5 months

2
8
0 0

FAILED: patch "[PATCH] mm/page_alloc: fix memory map initialization for descending" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 122e093c1734361dedb64f65c99b93e28e4624f4 Mon Sep 17 00:00:00 2001 From: Mike Rapoport <rppt(a)kernel.org> Date: Mon, 28 Jun 2021 19:33:26 -0700 Subject: [PATCH] mm/page_alloc: fix memory map initialization for descending nodes On systems with memory nodes sorted in descending order, for instance Dell Precision WorkStation T5500, the struct pages for higher PFNs and respectively lower nodes, could be overwritten by the initialization of struct pages corresponding to the holes in the memory sections. For example for the below memory layout [ 0.245624] Early memory node ranges [ 0.248496] node 1: [mem 0x0000000000001000-0x0000000000090fff] [ 0.251376] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] [ 0.254256] node 1: [mem 0x0000000100000000-0x0000001423ffffff] [ 0.257144] node 0: [mem 0x0000001424000000-0x0000002023ffffff] the range 0x1424000000 - 0x1428000000 in the beginning of node 0 starts in the middle of a section and will be considered as a hole during the initialization of the last section in node 1. The wrong initialization of the memory map causes panic on boot when CONFIG_DEBUG_VM is enabled. Reorder loop order of the memory map initialization so that the outer loop will always iterate over populated memory regions in the ascending order and the inner loop will select the zone corresponding to the PFN range. This way initialization of the struct pages for the memory holes will be always done for the ranges that are actually not populated. [akpm(a)linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/YNXlMqBbL+tBG7yq@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=213073 Link: https://lkml.kernel.org/r/20210624062305.10940-1-rppt@kernel.org Fixes: 0740a50b9baa ("mm/page_alloc.c: refactor initialization of struct page for holes in memory layout") Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com> Cc: Boris Petkov <bp(a)alien8.de> Cc: Robert Shteynfeld <robert.shteynfeld(a)gmail.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/include/linux/mm.h b/include/linux/mm.h index 8ae31622deef..9afb8998e7e5 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2474,7 +2474,6 @@ extern void set_dma_reserve(unsigned long new_dma_reserve); extern void memmap_init_range(unsigned long, int, unsigned long, unsigned long, unsigned long, enum meminit_context, struct vmem_altmap *, int migratetype); -extern void memmap_init_zone(struct zone *zone); extern void setup_per_zone_wmarks(void); extern int __meminit init_per_zone_wmark_min(void); extern void mem_init(void); diff --git a/mm/page_alloc.c b/mm/page_alloc.c index ef2265f86b91..5b5c9f5813b9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6400,7 +6400,7 @@ void __ref memmap_init_zone_device(struct zone *zone, return; /* - * The call to memmap_init_zone should have already taken care + * The call to memmap_init should have already taken care * of the pages reserved for the memmap, so we can just jump to * the end of that region and start processing the device pages. */ @@ -6465,7 +6465,7 @@ static void __meminit zone_init_free_lists(struct zone *zone) /* * Only struct pages that correspond to ranges defined by memblock.memory * are zeroed and initialized by going through __init_single_page() during - * memmap_init_zone(). + * memmap_init_zone_range(). * * But, there could be struct pages that correspond to holes in * memblock.memory. This can happen because of the following reasons: @@ -6484,9 +6484,9 @@ static void __meminit zone_init_free_lists(struct zone *zone) * zone/node above the hole except for the trailing pages in the last * section that will be appended to the zone/node below. */ -static u64 __meminit init_unavailable_range(unsigned long spfn, - unsigned long epfn, - int zone, int node) +static void __init init_unavailable_range(unsigned long spfn, + unsigned long epfn, + int zone, int node) { unsigned long pfn; u64 pgcnt = 0; @@ -6502,56 +6502,77 @@ static u64 __meminit init_unavailable_range(unsigned long spfn, pgcnt++; } - return pgcnt; + if (pgcnt) + pr_info("On node %d, zone %s: %lld pages in unavailable ranges", + node, zone_names[zone], pgcnt); } #else -static inline u64 init_unavailable_range(unsigned long spfn, unsigned long epfn, - int zone, int node) +static inline void init_unavailable_range(unsigned long spfn, + unsigned long epfn, + int zone, int node) { - return 0; } #endif -void __meminit __weak memmap_init_zone(struct zone *zone) +static void __init memmap_init_zone_range(struct zone *zone, + unsigned long start_pfn, + unsigned long end_pfn, + unsigned long *hole_pfn) { unsigned long zone_start_pfn = zone->zone_start_pfn; unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages; - int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone); - static unsigned long hole_pfn; + int nid = zone_to_nid(zone), zone_id = zone_idx(zone); + + start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn); + end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn); + + if (start_pfn >= end_pfn) + return; + + memmap_init_range(end_pfn - start_pfn, nid, zone_id, start_pfn, + zone_end_pfn, MEMINIT_EARLY, NULL, MIGRATE_MOVABLE); + + if (*hole_pfn < start_pfn) + init_unavailable_range(*hole_pfn, start_pfn, zone_id, nid); + + *hole_pfn = end_pfn; +} + +static void __init memmap_init(void) +{ unsigned long start_pfn, end_pfn; - u64 pgcnt = 0; + unsigned long hole_pfn = 0; + int i, j, zone_id, nid; - for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) { - start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn); - end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn); + for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) { + struct pglist_data *node = NODE_DATA(nid); + + for (j = 0; j < MAX_NR_ZONES; j++) { + struct zone *zone = node->node_zones + j; - if (end_pfn > start_pfn) - memmap_init_range(end_pfn - start_pfn, nid, - zone_id, start_pfn, zone_end_pfn, - MEMINIT_EARLY, NULL, MIGRATE_MOVABLE); + if (!populated_zone(zone)) + continue; - if (hole_pfn < start_pfn) - pgcnt += init_unavailable_range(hole_pfn, start_pfn, - zone_id, nid); - hole_pfn = end_pfn; + memmap_init_zone_range(zone, start_pfn, end_pfn, + &hole_pfn); + zone_id = j; + } } #ifdef CONFIG_SPARSEMEM /* - * Initialize the hole in the range [zone_end_pfn, section_end]. - * If zone boundary falls in the middle of a section, this hole - * will be re-initialized during the call to this function for the - * higher zone. + * Initialize the memory map for hole in the range [memory_end, + * section_end]. + * Append the pages in this hole to the highest zone in the last + * node. + * The call to init_unavailable_range() is outside the ifdef to + * silence the compiler warining about zone_id set but not used; + * for FLATMEM it is a nop anyway */ - end_pfn = round_up(zone_end_pfn, PAGES_PER_SECTION); + end_pfn = round_up(end_pfn, PAGES_PER_SECTION); if (hole_pfn < end_pfn) - pgcnt += init_unavailable_range(hole_pfn, end_pfn, - zone_id, nid); #endif - - if (pgcnt) - pr_info(" %s zone: %llu pages in unavailable ranges\n", - zone->name, pgcnt); + init_unavailable_range(hole_pfn, end_pfn, zone_id, nid); } static int zone_batchsize(struct zone *zone) @@ -7254,7 +7275,6 @@ static void __init free_area_init_core(struct pglist_data *pgdat) set_pageblock_order(); setup_usemap(zone); init_currently_empty_zone(zone, zone->zone_start_pfn, size); - memmap_init_zone(zone); } } @@ -7780,6 +7800,8 @@ void __init free_area_init(unsigned long *max_zone_pfn) node_set_state(nid, N_MEMORY); check_for_memory(pgdat, nid); } + + memmap_init(); } static int __init cmdline_parse_core(char *p, unsigned long *core,

3 years, 5 months

3
2
0 0

[PATCH stable 5.10 0/2] arm64: dts: Fix USB 3 for rk3328 Rock64 boards

by Andres Salomon

Hi, At some point the USB 3 port broke on Rock64 boards; users report it working back on 4.4 kernels, but by 5.3 it wasn't any more (eg, https://forum.armbian.com/topic/12439-rock64-usb-3-broken/). These two patches add a USB3 node to the device-tree, which allows it to work again. I've tested a gigabit nic and was able to get close to 1000mbit speeds over the USB 3 ports. I'd love to see these two unintrusive patches added to 5.10. Thanks, Andres Cameron Nemo (2): arm64: dts: rockchip: add rk3328 dwc3 usb controller node arm64: dts: rockchip: Enable USB3 for rk3328 Rock64 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 5 +++++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 19 +++++++++++++++++++ 2 files changed, 24 insertions(+)

3 years, 5 months

2
3
0 0

perf: bench/sched-messaging.c:73:13: error: 'dummy' may be used uninitialized

by Naresh Kamboju

LKFT have noticed these warnings / errors when we have updated gcc version from gcc-9 to gcc-11 on stable-rc linux-5.4.y branch. I have provided the steps to reproduce in this email below. Following perf builds failed with gcc-11 with linux-5.4.y branch. - build-arm-gcc-11-perf - build-arm64-gcc-11-perf - build-i386-gcc-11-perf - build-x86-gcc-11-perf Build error log: -------------------- find: 'x86_64-linux-gnu-gcc/arch': No such file or directory error: Found argument '-I' which wasn't expected, or isn't valid in this context USAGE: sccache [FLAGS] [OPTIONS] [cmd]... For more information try --help error: Found argument '-I' which wasn't expected, or isn't valid in this context USAGE: sccache [FLAGS] [OPTIONS] [cmd]... For more information try --help In function 'ready', inlined from 'sender' at bench/sched-messaging.c:87:2: bench/sched-messaging.c:73:13: error: 'dummy' may be used uninitialized [-Werror=maybe-uninitialized] 73 | if (write(ready_out, &dummy, 1) != 1) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from bench/sched-messaging.c:22: bench/sched-messaging.c: In function 'sender': /usr/x86_64-linux-gnu/include/unistd.h:366:16: note: by argument 2 of type 'const void *' to 'write' declared here 366 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur; | ^~~~~ bench/sched-messaging.c:69:14: note: 'dummy' declared here 69 | char dummy; | ^~~~~ cc1: all warnings being treated as errors ref: https://builds.tuxbuild.com/1vEIWryaujwVtL4wmodXkz1djUa/ https://builds.tuxbuild.com/1vEIX7NTo5OpaN9nrs2UvO74oxB/ Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Steps to reproduce: --------------------------- tuxmake --runtime podman --target-arch x86_64 --toolchain gcc-11 --kconfig defconfig --kconfig-add https://builds.tuxbuild.com/1vEIWryaujwVtL4wmodXkz1djUa/config headers kernel modules perf -- Linaro LKFT https://lkft.linaro.org

3 years, 5 months

3
3
0 0

[PATCH for 5.10.y] ath11k: unlock on error path in ath11k_mac_op_add_interface()

by Nobuhiro Iwamatsu

From: Dan Carpenter <dan.carpenter(a)oracle.com> commit 59ec8e2fa5aaed6afd18d5362dc131aab92406e7 upstream. These error paths need to drop the &ar->conf_mutex before returning. Fixes: 690ace20ff79 ("ath11k: peer delete synchronization with firmware") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Link: https://lore.kernel.org/r/X85sVGVP/0XvlrEJ@mwanda Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu(a)toshiba.co.jp> --- drivers/net/wireless/ath/ath11k/mac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c index e9e6b0c4de220a..7b9acb265a5628 100644 --- a/drivers/net/wireless/ath/ath11k/mac.c +++ b/drivers/net/wireless/ath/ath11k/mac.c @@ -4597,13 +4597,13 @@ static int ath11k_mac_op_add_interface(struct ieee80211_hw *hw, if (ret) { ath11k_warn(ar->ab, "failed to delete peer vdev_id %d addr %pM\n", arvif->vdev_id, vif->addr); - return ret; + goto err; } ret = ath11k_wait_for_peer_delete_done(ar, arvif->vdev_id, vif->addr); if (ret) - return ret; + goto err; ar->num_peers--; } -- 2.32.0

3 years, 5 months

2
1
0 0

Fix: Please help to cherry-pick patch "bdi: Do not use freezable workqueue" to stable tree

by Macpaul Lin

Dear Greg, Our customers have feedback some similar issues as below link on Android kernel-4.14 and kernel-4.19. Link: https://marc.info/?l=linux-kernel&m=138695698516487 They've reported system become abnormal when OTG U-disk has been plugged out after the system has been suspended. After debugging, we've found the root cause is the same of the issue (link) has been reported. We've also tested the patch "bdi: Do not use freezable workqueue" is worked. Link: https://lkml.org/lkml/2019/10/4/176 commit id in Linus tree: a2b90f11217790ec0964ba9c93a4abb369758c26 However, we've checked that patch seems hasn't been applied to stable tree (We've checked 4.14 and 4.19). Would you please help to cherry-pick this patch to stable trees (and to Android trees)? Thanks! Macpaul Lin

3 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2021