- Kernel - mailweb.openeuler.org

[PATCH v3 openEuler-23.09 00/25] backport etmem feature from OLK-5.10
by liubo 15 Aug '23

15 Aug '23

This patch set is used to backport etmem feature patches to version 23.09. etmem is a tiered memory extension technology that uses DRAM+memory compression/high-performance storage media to form tiered memory storage. Memory data is tiered, and cold data is migrated from memory media to high-performance storage media to release memory space and reduce memory costs. v2 -> v3 - fix the build problem in riscv64 arch. v1 -> v2 - some cleanup fix Kemeng Shi (11): etmem: add ioctl for mm idle scan etmem: x86: support scan hugetlb of vm etmem_scan: x86: support scan 4 level ept under 5 level host page table etmem scan: fix memleak in vm_idle_read etmem: fix concurrent access to export file operations etmem: fix potential UAF when walk ept page table etmem_scan: release CPU after scan walk_step size etmem_scan: add pte_hole callback acpi/numa: memorize node type from SRAT table hugepage: add sysctl for hugepage alloc and mig x86: hugepage: use nt copy hugepage to AEP in x86 liubo (14): memig: add memig-scan feature to openEuler memig: add memig-swap feature to openEuler memig: fix compile error when CONFIG_NUMA is turned off etmem: Modify the memig feature name to etmem move ETMEM feature CONFIG to mm/Kconfig and add architecture dependency etmem: etmem scan module Replace WARN_ONCE() with debug_printk for "nothing read" add ETMEM feature CONFIG to mm/Kconfig config: enable CONFIG_ETMEM by default etmem: add CONFIG_ETMEM macro definition for etmem feature etmem: add original kernel swap enabled options etmem: add swapcache reclaim to etmem etmem: Add a scan flag to support specified page swap-out etmem: fix the div 0 problem in swapcache reclaim process etmem: fix some problem during backport etmem patches arch/arm64/configs/openeuler_defconfig | 3 + arch/x86/configs/openeuler_defconfig | 3 + arch/x86/include/asm/page_64.h | 7 + arch/x86/lib/Makefile | 1 + arch/x86/lib/copy_highpages.c | 107 ++ arch/x86/lib/copy_page_64.S | 73 ++ drivers/acpi/numa/srat.c | 5 + fs/proc/Makefile | 2 + fs/proc/base.c | 8 + fs/proc/etmem_scan.c | 1383 ++++++++++++++++++++++++ fs/proc/etmem_scan.h | 149 +++ fs/proc/etmem_swap.c | 282 +++++ fs/proc/internal.h | 4 + fs/proc/task_mmu.c | 194 ++++ include/linux/highmem.h | 17 + include/linux/hugetlb.h | 6 + include/linux/list.h | 17 + include/linux/mm.h | 4 + include/linux/mm_types.h | 18 +- include/linux/numa.h | 12 + include/linux/swap.h | 38 + include/uapi/asm-generic/mman-common.h | 3 + kernel/sysctl.c | 20 + mm/Kconfig | 25 + mm/huge_memory.c | 1 + mm/hugetlb.c | 7 +- mm/internal.h | 1 - mm/madvise.c | 17 +- mm/page_alloc.c | 13 + mm/pagewalk.c | 1 + mm/swap_state.c | 37 + mm/util.c | 11 +- mm/vmscan.c | 390 +++++++ virt/kvm/kvm_main.c | 6 + 34 files changed, 2852 insertions(+), 13 deletions(-) create mode 100644 arch/x86/lib/copy_highpages.c create mode 100644 fs/proc/etmem_scan.c create mode 100644 fs/proc/etmem_scan.h create mode 100644 fs/proc/etmem_swap.c -- 2.27.0

2 26

[PATCH openEuler-1.0-LTS 0/5] workqueue: Make flush_workqueue() also watch flush_work()
by Zeng Heng 15 Aug '23

15 Aug '23

Lai Jiangshan (5): workqueue: Rename "delayed" (delayed by active management) to "inactive" workqueue: Change arguement of pwq_dec_nr_in_flight() workqueue: Change the code of calculating work_flags in insert_wq_barrier() workqueue: Mark barrier work with WORK_STRUCT_INACTIVE workqueue: Assign a color to barrier work items include/linux/workqueue.h | 4 +- kernel/workqueue.c | 135 ++++++++++++++++++++++-------------- kernel/workqueue_internal.h | 3 +- 3 files changed, 87 insertions(+), 55 deletions(-) -- 2.25.1

1 5

[PATCH 0/5] workqueue: Make flush_workqueue() also watch flush_work()
by Zeng Heng 15 Aug '23

15 Aug '23

Lai Jiangshan (5): workqueue: Rename "delayed" (delayed by active management) to "inactive" workqueue: Change arguement of pwq_dec_nr_in_flight() workqueue: Change the code of calculating work_flags in insert_wq_barrier() workqueue: Mark barrier work with WORK_STRUCT_INACTIVE workqueue: Assign a color to barrier work items include/linux/workqueue.h | 4 +- kernel/workqueue.c | 135 ++++++++++++++++++++++-------------- kernel/workqueue_internal.h | 3 +- 3 files changed, 87 insertions(+), 55 deletions(-) -- 2.25.1

1 5

[PATCH openEuler-22.03-LTS-SP1] mm/pagealloc: sysctl: change watermark_scale_factor max limit to 30%
by wujiangtao 15 Aug '23

15 Aug '23

From surenb <surenb(a)google.com> mainline inclusion from mainline-v5.17-rc1 commit 39c65a94cd9661532be150e88f8b02f4a6844a35 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7T82I CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Upstream commit 39c65a94cd9661532be150e88f8b02f4a6844a35 change watermark_scale_factor max limit to 30%, but we don't backport it. The current limit of watermark_scale_factor is 10%. As described in the patch, the limit of watermark_scale_factor may need to be increased in some scenarios to reduce application performance fluctuations due to direct recycling -------------------------------- For embedded systems with low total memory, having to run applications with relatively large memory requirements, 10% max limitation for watermark_scale_factor poses an issue of triggering direct reclaim every time such application is started. This results in slow application startup times and bad end-user experience. By increasing watermark_scale_factor max limit we allow vendors more flexibility to choose the right level of kswapd aggressiveness for their device and workload requirements. Link: https://lkml.kernel.org/r/20211124193604.2758863-1-surenb@google.com Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Lukas Middendorf <kernel(a)tuxforce.de> Cc: Antti Palosaari <crope(a)iki.fi> Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Kees Cook <keescook(a)chromium.org> Cc: Iurii Zaikin <yzaikin(a)google.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: Fengfei Xi <xi.fengfei(a)h3c.com> Cc: Mike Rapoport <rppt(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- Documentation/admin-guide/sysctl/vm.rst | 2 +- kernel/sysctl.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index a84bef7aa864..06500c423592 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -996,7 +996,7 @@ how much memory needs to be free before kswapd goes back to sleep. The unit is in fractions of 10,000. The default value of 10 means the distances between watermarks are 0.1% of the available memory in the -node/system. The maximum value is 1000, or 10% of memory. +node/system. The maximum value is 3000, or 30% of memory. A high rate of threads entering direct reclaim (allocstall) or kswapd going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicate diff --git a/kernel/sysctl.c b/kernel/sysctl.c index d290ba2d8fee..fd82beb9a743 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -122,6 +122,7 @@ static unsigned long long_max = LONG_MAX; static int one_hundred = 100; static int two_hundred = 200; static int one_thousand = 1000; +static int three_thousand = 3000; #ifdef CONFIG_PRINTK static int ten_thousand = 10000; #endif @@ -2983,7 +2984,7 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = watermark_scale_factor_sysctl_handler, .extra1 = SYSCTL_ONE, - .extra2 = &one_thousand, + .extra2 = &three_thousand, }, { .procname = "percpu_pagelist_fraction", -- 2.27.0

2 1

[PATCH OLK-5.10] bonding: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves
by Ziyang Xuan 15 Aug '23

15 Aug '23

mainline inclusion from mainline-v6.5-rc6 commit 01f4fd27087078c90a0e22860d1dfa2cd0510791 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7T6MN CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- BUG_ON(!vlan_info) is triggered in unregister_vlan_dev() with following testcase: # ip netns add ns1 # ip netns exec ns1 ip link add bond0 type bond mode 0 # ip netns exec ns1 ip link add bond_slave_1 type veth peer veth2 # ip netns exec ns1 ip link set bond_slave_1 master bond0 # ip netns exec ns1 ip link add link bond_slave_1 name vlan10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link add link bond0 name bond0_vlan10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link set bond_slave_1 nomaster # ip netns del ns1 The logical analysis of the problem is as follows: 1. create ETH_P_8021AD protocol vlan10 for bond_slave_1: register_vlan_dev() vlan_vid_add() vlan_info_alloc() __vlan_vid_add() // add [ETH_P_8021AD, 10] vid to bond_slave_1 2. create ETH_P_8021AD protocol bond0_vlan10 for bond0: register_vlan_dev() vlan_vid_add() __vlan_vid_add() vlan_add_rx_filter_info() if (!vlan_hw_filter_capable(dev, proto)) // condition established because bond0 without NETIF_F_HW_VLAN_STAG_FILTER return 0; if (netif_device_present(dev)) return dev->netdev_ops->ndo_vlan_rx_add_vid(dev, proto, vid); // will be never called // The slaves of bond0 will not refer to the [ETH_P_8021AD, 10] vid. 3. detach bond_slave_1 from bond0: __bond_release_one() vlan_vids_del_by_dev() list_for_each_entry(vid_info, &vlan_info->vid_list, list) vlan_vid_del(dev, vid_info->proto, vid_info->vid); // bond_slave_1 [ETH_P_8021AD, 10] vid will be deleted. // bond_slave_1->vlan_info will be assigned NULL. 4. delete vlan10 during delete ns1: default_device_exit_batch() dev->rtnl_link_ops->dellink() // unregister_vlan_dev() for vlan10 vlan_info = rtnl_dereference(real_dev->vlan_info); // real_dev of vlan10 is bond_slave_1 BUG_ON(!vlan_info); // bond_slave_1->vlan_info is NULL now, bug is triggered!!! Add S-VLAN tag related features support to bond driver. So the bond driver will always propagate the VLAN info to its slaves. Fixes: 8ad227ff89a7 ("net: vlan: add 802.1ad support") Suggested-by: Ido Schimmel <idosch(a)idosch.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://lore.kernel.org/r/20230802114320.4156068-1-william.xuanziyang@huawe… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- drivers/net/bonding/bond_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 9bf010e88da7..be0c4d655cf9 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -5313,7 +5313,9 @@ void bond_setup(struct net_device *bond_dev) bond_dev->hw_features = BOND_VLAN_FEATURES | NETIF_F_HW_VLAN_CTAG_RX | - NETIF_F_HW_VLAN_CTAG_FILTER; + NETIF_F_HW_VLAN_CTAG_FILTER | + NETIF_F_HW_VLAN_STAG_RX | + NETIF_F_HW_VLAN_STAG_FILTER; bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4; #ifdef CONFIG_XFRM_OFFLOAD -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] bonding: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves
by Ziyang Xuan 15 Aug '23

15 Aug '23

mainline inclusion from mainline-v6.5-rc6 commit 01f4fd27087078c90a0e22860d1dfa2cd0510791 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7T6MN CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- BUG_ON(!vlan_info) is triggered in unregister_vlan_dev() with following testcase: # ip netns add ns1 # ip netns exec ns1 ip link add bond0 type bond mode 0 # ip netns exec ns1 ip link add bond_slave_1 type veth peer veth2 # ip netns exec ns1 ip link set bond_slave_1 master bond0 # ip netns exec ns1 ip link add link bond_slave_1 name vlan10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link add link bond0 name bond0_vlan10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link set bond_slave_1 nomaster # ip netns del ns1 The logical analysis of the problem is as follows: 1. create ETH_P_8021AD protocol vlan10 for bond_slave_1: register_vlan_dev() vlan_vid_add() vlan_info_alloc() __vlan_vid_add() // add [ETH_P_8021AD, 10] vid to bond_slave_1 2. create ETH_P_8021AD protocol bond0_vlan10 for bond0: register_vlan_dev() vlan_vid_add() __vlan_vid_add() vlan_add_rx_filter_info() if (!vlan_hw_filter_capable(dev, proto)) // condition established because bond0 without NETIF_F_HW_VLAN_STAG_FILTER return 0; if (netif_device_present(dev)) return dev->netdev_ops->ndo_vlan_rx_add_vid(dev, proto, vid); // will be never called // The slaves of bond0 will not refer to the [ETH_P_8021AD, 10] vid. 3. detach bond_slave_1 from bond0: __bond_release_one() vlan_vids_del_by_dev() list_for_each_entry(vid_info, &vlan_info->vid_list, list) vlan_vid_del(dev, vid_info->proto, vid_info->vid); // bond_slave_1 [ETH_P_8021AD, 10] vid will be deleted. // bond_slave_1->vlan_info will be assigned NULL. 4. delete vlan10 during delete ns1: default_device_exit_batch() dev->rtnl_link_ops->dellink() // unregister_vlan_dev() for vlan10 vlan_info = rtnl_dereference(real_dev->vlan_info); // real_dev of vlan10 is bond_slave_1 BUG_ON(!vlan_info); // bond_slave_1->vlan_info is NULL now, bug is triggered!!! Add S-VLAN tag related features support to bond driver. So the bond driver will always propagate the VLAN info to its slaves. Fixes: 8ad227ff89a7 ("net: vlan: add 802.1ad support") Suggested-by: Ido Schimmel <idosch(a)idosch.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://lore.kernel.org/r/20230802114320.4156068-1-william.xuanziyang@huawe… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- drivers/net/bonding/bond_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index fe28cbec4a4c..99c792fab45a 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -4452,7 +4452,9 @@ void bond_setup(struct net_device *bond_dev) bond_dev->hw_features = BOND_VLAN_FEATURES | NETIF_F_HW_VLAN_CTAG_RX | - NETIF_F_HW_VLAN_CTAG_FILTER; + NETIF_F_HW_VLAN_CTAG_FILTER | + NETIF_F_HW_VLAN_STAG_RX | + NETIF_F_HW_VLAN_STAG_FILTER; bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4; bond_dev->features |= bond_dev->hw_features; -- 2.25.1

2 1

[PATCH OLK-5.10] xen/netback: Fix buffer overrun triggered by unusual packet
by Zhengchao Shao 15 Aug '23

15 Aug '23

From: Ross Lagerwall <ross.lagerwall(a)citrix.com> stable inclusion from stable-v5.10.189 commit f9167a2d6b943f30743de6ff8163d1981c34f9a9 category: bugfix bugzilla: 189119 CVE: CVE-2023-34319 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 534fc31d09b706a16d83533e16b5dc855caf7576 upstream. It is possible that a guest can send a packet that contains a head + 18 slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots to underflow in xenvif_get_requests() which then causes the subsequent loop's termination condition to be wrong, causing a buffer overrun of queue->tx_map_ops. Rework the code to account for the extra frag_overflow slots. This is CVE-2023-34319 / XSA-432. Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com> Reviewed-by: Paul Durrant <paul(a)xen.org> Reviewed-by: Wei Liu <wei.liu(a)kernel.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/net/xen-netback/netback.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/xen-netback/netback.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index f9373a88cf37..24b4f73fb336 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -393,7 +393,7 @@ static void xenvif_get_requests(struct xenvif_queue *queue, struct gnttab_map_grant_ref *gop = queue->tx_map_ops + *map_ops; struct xen_netif_tx_request *txp = first; - nr_slots = shinfo->nr_frags + 1; + nr_slots = shinfo->nr_frags + frag_overflow + 1; copy_count(skb) = 0; @@ -448,8 +448,8 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } } - for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; - shinfo->nr_frags++, gop++) { + for (shinfo->nr_frags = 0; nr_slots > 0 && shinfo->nr_frags < MAX_SKB_FRAGS; + shinfo->nr_frags++, gop++, nr_slots--) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; xenvif_tx_create_map_op(queue, pending_idx, txp, @@ -462,12 +462,12 @@ static void xenvif_get_requests(struct xenvif_queue *queue, txp++; } - if (frag_overflow) { + if (nr_slots > 0) { shinfo = skb_shinfo(nskb); frags = shinfo->frags; - for (shinfo->nr_frags = 0; shinfo->nr_frags < frag_overflow; + for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; shinfo->nr_frags++, txp++, gop++) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; @@ -478,6 +478,11 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } skb_shinfo(skb)->frag_list = nskb; + } else if (nskb) { + /* A frag_list skb was allocated but it is no longer needed + * because enough slots were converted to copy ops above. + */ + kfree_skb(nskb); } (*copy_ops) = cop - queue->tx_copy_ops; -- 2.34.1

2 1

[PATCH] xen/netback: Fix buffer overrun triggered by unusual packet
by Zhengchao Shao 15 Aug '23

15 Aug '23

From: Ross Lagerwall <ross.lagerwall(a)citrix.com> stable inclusion from stable-v5.10.189 commit f9167a2d6b943f30743de6ff8163d1981c34f9a9 category: bugfix bugzilla: 189119 CVE: CVE-2023-34319 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 534fc31d09b706a16d83533e16b5dc855caf7576 upstream. It is possible that a guest can send a packet that contains a head + 18 slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots to underflow in xenvif_get_requests() which then causes the subsequent loop's termination condition to be wrong, causing a buffer overrun of queue->tx_map_ops. Rework the code to account for the extra frag_overflow slots. This is CVE-2023-34319 / XSA-432. Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com> Reviewed-by: Paul Durrant <paul(a)xen.org> Reviewed-by: Wei Liu <wei.liu(a)kernel.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/net/xen-netback/netback.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/xen-netback/netback.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index f9373a88cf37..24b4f73fb336 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -393,7 +393,7 @@ static void xenvif_get_requests(struct xenvif_queue *queue, struct gnttab_map_grant_ref *gop = queue->tx_map_ops + *map_ops; struct xen_netif_tx_request *txp = first; - nr_slots = shinfo->nr_frags + 1; + nr_slots = shinfo->nr_frags + frag_overflow + 1; copy_count(skb) = 0; @@ -448,8 +448,8 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } } - for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; - shinfo->nr_frags++, gop++) { + for (shinfo->nr_frags = 0; nr_slots > 0 && shinfo->nr_frags < MAX_SKB_FRAGS; + shinfo->nr_frags++, gop++, nr_slots--) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; xenvif_tx_create_map_op(queue, pending_idx, txp, @@ -462,12 +462,12 @@ static void xenvif_get_requests(struct xenvif_queue *queue, txp++; } - if (frag_overflow) { + if (nr_slots > 0) { shinfo = skb_shinfo(nskb); frags = shinfo->frags; - for (shinfo->nr_frags = 0; shinfo->nr_frags < frag_overflow; + for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; shinfo->nr_frags++, txp++, gop++) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; @@ -478,6 +478,11 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } skb_shinfo(skb)->frag_list = nskb; + } else if (nskb) { + /* A frag_list skb was allocated but it is no longer needed + * because enough slots were converted to copy ops above. + */ + kfree_skb(nskb); } (*copy_ops) = cop - queue->tx_copy_ops; -- 2.34.1

1 0

[PATCH openEuler-1.0-LTS] xen/netback: Fix buffer overrun triggered by unusual packet
by Zhengchao Shao 14 Aug '23

14 Aug '23

From: Ross Lagerwall <ross.lagerwall(a)citrix.com> stable inclusion from stable-v4.19.290 commit 11e6919ae028b5de1fc48007354ea07069561b31 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7RQ63 CVE: CVE-2023-34319 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 534fc31d09b706a16d83533e16b5dc855caf7576 upstream. It is possible that a guest can send a packet that contains a head + 18 slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots to underflow in xenvif_get_requests() which then causes the subsequent loop's termination condition to be wrong, causing a buffer overrun of queue->tx_map_ops. Rework the code to account for the extra frag_overflow slots. This is CVE-2023-34319 / XSA-432. Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com> Reviewed-by: Paul Durrant <paul(a)xen.org> Reviewed-by: Wei Liu <wei.liu(a)kernel.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/net/xen-netback/netback.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/xen-netback/netback.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index 649049df922f..103f2c09d785 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -384,7 +384,7 @@ static void xenvif_get_requests(struct xenvif_queue *queue, struct gnttab_map_grant_ref *gop = queue->tx_map_ops + *map_ops; struct xen_netif_tx_request *txp = first; - nr_slots = shinfo->nr_frags + 1; + nr_slots = shinfo->nr_frags + frag_overflow + 1; copy_count(skb) = 0; @@ -439,8 +439,8 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } } - for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; - shinfo->nr_frags++, gop++) { + for (shinfo->nr_frags = 0; nr_slots > 0 && shinfo->nr_frags < MAX_SKB_FRAGS; + shinfo->nr_frags++, gop++, nr_slots--) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; xenvif_tx_create_map_op(queue, pending_idx, txp, @@ -453,12 +453,12 @@ static void xenvif_get_requests(struct xenvif_queue *queue, txp++; } - if (frag_overflow) { + if (nr_slots > 0) { shinfo = skb_shinfo(nskb); frags = shinfo->frags; - for (shinfo->nr_frags = 0; shinfo->nr_frags < frag_overflow; + for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; shinfo->nr_frags++, txp++, gop++) { index = pending_index(queue->pending_cons++); pending_idx = queue->pending_ring[index]; @@ -469,6 +469,11 @@ static void xenvif_get_requests(struct xenvif_queue *queue, } skb_shinfo(skb)->frag_list = nskb; + } else if (nskb) { + /* A frag_list skb was allocated but it is no longer needed + * because enough slots were converted to copy ops above. + */ + kfree_skb(nskb); } (*copy_ops) = cop - queue->tx_copy_ops; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS, v2 0/2] tun/tap: fix CVE-2023-4194
by Dong Chenchen 14 Aug '23

14 Aug '23

The original patches fixing CVE-2023-1076 are incorrect. The patches in this series are supposed to "re-fix" CVE-2023-1076 New CVE is CVE-2023-4194. Laszlo Ersek (2): net: tun_chr_open(): set sk_uid from current_fsuid() net: tap_open(): set sk_uid from current_fsuid() drivers/net/tap.c | 2 +- drivers/net/tun.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

1 2