- 14 6月, 2022 35 次提交
-
-
由 Hao Chen 提交于
mainline inclusion from mainline-origin commit 2373b35c category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2373b35c24ff ---------------------------------------------------------------------- For the active tx spare buffer size maybe changed according to the page size, so add log to notice it. Signed-off-by: NHao Chen <chenhao288@hisilicon.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jie Wang 提交于
mainline inclusion from mainline-origin commit bcc7a98f category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcc7a98f0d3c ---------------------------------------------------------------------- Currently, There is a low probability that pf mtu configuration fails, but the information in logs is insufficient for problem locating when the VF mtu value is illegally modified. So record the vf index and vf mtu value at the failure scenario. Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jian Shen 提交于
mainline inclusion from mainline-origin commit 6fde96df category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fde96df0447 ---------------------------------------------------------------------- The struct hclge_pf_to_vf_msg is used for mailbox message from PF to VF, including both response and request. But its definition can only indicate respone, which makes the message data copy in function hclge_send_mbx_msg() unreadable. So refine it by edding a general message definition into it. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Hao Chen 提交于
mainline inclusion from mainline-origin commit 07fdc163 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07fdc163ac88 ---------------------------------------------------------------------- Use struct hns3_ring_param to replace variable new/old_xxx and add hns3_is_ringparam_changed() to judge them if is changed to improve code readability. Signed-off-by: NHao Chen <chenhao288@hisilicon.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-origin commit 286c61e7 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=286c61e72797 ---------------------------------------------------------------------- For DEVICE_VERSION_V2, the hardware does not support the CQE mode. So add capability bit for coalesce CQE mode and add parameter check for it in ethtool. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-v5.18-rc1 commit 7ed258f1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ed258f12ec5 ---------------------------------------------------------------------- When user delete vlan 0, as driver will not delete vlan 0 for hardware in function hclge_set_vlan_filter_hw(), so vlan 0 in software vlan talbe should not be deleted. Fixes: fe4144d4 ("net: hns3: sync VLAN filter entries when kill VLAN ID failed") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-v5.18-rc1 commit 9c9a0421 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c9a04212fa3 ---------------------------------------------------------------------- Currently, the debugfs mechanism is that all functions share a global variable to save the pointer for obtaining data. When different functions concurrently access the same file node, repeated release exceptions occur. Therefore, the granularity of the pointer for storing the obtained data is adjusted to be private for each function. Fixes: 5e69ea7e ("net: hns3: refactor the debugfs process") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jean-Philippe Brucker 提交于
mainline inclusion from mainline-v5.18-rc2 commit 1effe8ca category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I56XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1effe8ca4e34 ---------------------------------------------------------------------- Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce(). Fixes: 53e0961d ("page_pool: add frag page recycling support in page pool") Suggested-by: NAlexander Duyck <alexanderduyck@fb.com> Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: NYunsheng Lin <linyunsheng@huawei.com> Reviewed-by: NAlexander Duyck <alexanderduyck@fb.com> Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: NJesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com> Reviewed-by: NJian Shen <shenjian15@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from stable-v5.10.120 commit c0aff1faf66b6b7a19103f83e6a5d0fdc64b9048 category: bugfix bugzilla: 186913 https://gitee.com/src-openeuler/kernel/issues/I5B69E CVE: CVE-2022-1972 -------------------------------- commit fecf31ee upstream. Add several sanity checks for nft_set_desc_concat_parse(): - validate desc->field_count not larger than desc->field_len array. - field length cannot be larger than desc->field_len (ie. U8_MAX) - total length of the concatenation cannot be larger than register array. Joint work with Florian Westphal. Fixes: f3a2181e ("netfilter: nf_tables: Support for sets with multiple ranged fields") Reported-by: <zhangziming.zzm@antgroup.com> Reviewed-by: NStefano Brivio <sbrivio@redhat.com> Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tianjia Zhang 提交于
mainline inclusion from mainline-v5.19-rc1 commit b45b0a12 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220411031313.35449-1-tianjia.zhang@linux.alibaba.com/ -------------------------------- Commit d2825fa9 ("crypto: sm3,sm4 - move into crypto directory") moved the sm4 library implementation from the lib/crypto directory to the crypto directory and configured the name as CRYPTO_SM4. The arm64 SM4 NEON/CE implementation depends on this and needs to be modified uniformly. Fixes: 4f1aef9b ("crypto: arm64/sm4 - add ARMv8 NEON implementation") Fixes: 5b33e0ec ("crypto: arm64/sm4 - add ARMv8 Crypto Extensions implementation") Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tianjia Zhang 提交于
mainline inclusion from mainline-v5.19-rc1 commit 5b33e0ec category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220315094454.45269-5-tianjia.zhang@linux.alibaba.com/ -------------------------------- This adds ARMv8 implementations of SM4 in ECB, CBC, CFB and CTR modes using Crypto Extensions, also includes key expansion operations because the Crypto Extensions instruction is much faster than software implementations. The Crypto Extensions for SM4 can only run on ARMv8 implementations that have support for these optional extensions. Benchmark on T-Head Yitian-710 2.75 GHz, the data comes from the 218 mode of tcrypt. The abscissas are blocks of different lengths. The data is tabulated and the unit is Mb/s: sm4-generic | 16 64 128 256 1024 1420 4096 ECB enc | 80.05 91.42 93.66 94.77 95.69 95.77 95.86 ECB dec | 79.98 91.41 93.64 94.76 95.66 95.77 95.85 CBC enc | 78.55 86.50 88.02 88.77 89.36 89.42 89.48 CBC dec | 76.82 89.06 91.52 92.77 93.75 93.83 93.96 CFB enc | 77.64 86.13 87.62 88.42 89.08 88.83 89.18 CFB dec | 77.57 88.34 90.36 91.45 92.34 92.00 92.44 CTR enc | 77.80 88.28 90.23 91.22 92.11 91.81 92.25 CTR dec | 77.83 88.22 90.22 91.22 92.04 91.82 92.28 sm4-neon ECB enc | 28.31 112.77 203.03 209.89 215.49 202.11 210.59 ECB dec | 28.36 113.45 203.23 210.00 215.52 202.13 210.65 CBC enc | 79.32 87.02 88.51 89.28 89.85 89.89 89.97 CBC dec | 28.29 112.20 203.30 209.82 214.99 201.51 209.95 CFB enc | 79.59 87.16 88.54 89.30 89.83 89.62 89.92 CFB dec | 28.12 111.05 202.47 209.02 214.21 210.90 209.12 CTR enc | 28.04 108.81 200.62 206.65 211.78 208.78 206.74 CTR dec | 28.02 108.82 200.45 206.62 211.78 208.74 206.70 sm4-ce-cipher ECB enc | 336.79 587.13 682.70 747.37 803.75 811.52 818.06 ECB dec | 339.18 584.52 679.72 743.68 798.82 803.83 811.54 CBC enc | 316.63 521.47 597.00 647.14 690.82 695.21 700.55 CBC dec | 291.80 503.79 585.66 640.82 689.86 695.16 701.72 CFB enc | 294.79 482.31 552.13 594.71 631.60 628.91 638.92 CFB dec | 293.09 466.44 526.56 563.17 594.41 592.26 601.97 CTR enc | 309.61 506.13 576.86 620.47 656.38 654.51 665.10 CTR dec | 306.69 505.57 576.84 620.18 657.09 654.52 665.32 sm4-ce ECB enc | 366.96 1329.81 2024.29 2755.50 3790.07 3861.91 4051.40 ECB dec | 367.30 1323.93 2018.72 2747.43 3787.39 3862.55 4052.62 CBC enc | 358.09 682.68 807.24 885.35 958.29 963.60 973.73 CBC dec | 366.51 1303.63 1978.64 2667.93 3624.53 3683.41 3856.08 CFB enc | 351.51 681.26 807.81 893.10 968.54 969.17 985.83 CFB dec | 354.98 1266.61 1929.63 2634.81 3614.23 3611.59 3841.68 CTR enc | 324.23 1121.25 1689.44 2256.70 2981.90 3007.79 3060.74 CTR dec | 324.18 1120.44 1694.31 2258.32 2982.01 3010.09 3060.99 Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tianjia Zhang 提交于
mainline inclusion from mainline-v5.19-rc1 commit 4f1aef9b category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220315094454.45269-4-tianjia.zhang@linux.alibaba.com/ -------------------------------- This adds ARMv8 NEON implementations of SM4 in ECB, CBC, CFB and CTR modes. This implementation uses the plain NEON instruction set, All S-BOX substitutions uses the tbl/tbx instructions of ARMv8, combined with the out-of-order execution in CPU, this optimization supports encryption of up to 8 blocks at the same time. The performance of encrypting one block is not as good as software implementation, so the encryption operations of CBC and CFB still use pure software algorithms. Benchmark on T-Head Yitian-710 2.75 GHz, the data comes from the 218 mode of tcrypt. The abscissas are blocks of different lengths. The data is tabulated and the unit is Mb/s: sm4-generic | 16 64 128 256 1024 1420 4096 ECB enc | 80.05 91.42 93.66 94.77 95.69 95.77 95.86 ECB dec | 79.98 91.41 93.64 94.76 95.66 95.77 95.85 CBC enc | 78.55 86.50 88.02 88.77 89.36 89.42 89.48 CBC dec | 76.82 89.06 91.52 92.77 93.75 93.83 93.96 CFB enc | 77.64 86.13 87.62 88.42 89.08 88.83 89.18 CFB dec | 77.57 88.34 90.36 91.45 92.34 92.00 92.44 CTR enc | 77.80 88.28 90.23 91.22 92.11 91.81 92.25 CTR dec | 77.83 88.22 90.22 91.22 92.04 91.82 92.28 sm4-neon ECB enc | 28.31 112.77 203.03 209.89 215.49 202.11 210.59 ECB dec | 28.36 113.45 203.23 210.00 215.52 202.13 210.65 CBC enc | 79.32 87.02 88.51 89.28 89.85 89.89 89.97 CBC dec | 28.29 112.20 203.30 209.82 214.99 201.51 209.95 CFB enc | 79.59 87.16 88.54 89.30 89.83 89.62 89.92 CFB dec | 28.12 111.05 202.47 209.02 214.21 210.90 209.12 CTR enc | 28.04 108.81 200.62 206.65 211.78 208.78 206.74 CTR dec | 28.02 108.82 200.45 206.62 211.78 208.74 206.70 Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tianjia Zhang 提交于
mainline inclusion from mainline-v5.19-rc1 commit 02436762 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220315094454.45269-3-tianjia.zhang@linux.alibaba.com/ -------------------------------- The subsequent patches of the series will have an implementation of SM4-ECB/CBC/CFB/CTR accelerated by the CE instruction set, which conflicts with the current module name. In order to keep the naming rules of the AES algorithm consistent, the sm4-ce algorithm is renamed to sm4-ce-cipher. In addition, the speed of sm4-ce-cipher is better than that of SM4 NEON. By the way, the priority of the algorithm is adjusted to 300, which is also to leave room for the priority of SM4 NEON. Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tianjia Zhang 提交于
mainline inclusion from mainline-v5.19-rc1 commit 73c919d3 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220315094454.45269-2-tianjia.zhang@linux.alibaba.com/ -------------------------------- Export the constant arrays fk, ck, sbox of the SM4 algorithm, and add the 'crypto_sm4_' prefix, where sbox is used in the SM4 NEON implementation for the tbl/tbx instruction to replace the S-BOX, and the fk, ck arrays are used in the SM4 CE implementation. Use the sm4ekey instruction to speed up key expansion operations. Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jason A. Donenfeld 提交于
mainline inclusion from mainline-v5.19-rc1 commit d2825fa9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I50ABL CVE: NA Reference: https://patchwork.kernel.org/project/linux-crypto/patch/20220314031101.663883-1-Jason@zx2c4.com/ -------------------------------- The lib/crypto libraries live in lib because they are used by various drivers of the kernel. In contrast, the various helper functions in crypto are there because they're used exclusively by the crypto API. The SM3 and SM4 helper functions were erroniously moved into lib/crypto/ instead of crypto/, even though there are no in-kernel users outside of the crypto API of those functions. This commit moves them into crypto/. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Conflicts: lib/crypto/Kconfig Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.116 commit 29f077d070519a88a793fbc70f1e6484dc6d9e35 category: bugfix bugzilla: 186865,https://gitee.com/src-openeuler/kernel/issues/I593SI CVE: CVE-2022-1786 -------------------------------- If the ring is setup with IORING_SETUP_IOPOLL and we have more than one task doing submissions on a ring, we can up in a situation where we assign the context from the current task rather than the request originator. Always use req->task rather than assume it's the same as current. No upstream patch exists for this issue, as only older kernels with the non-native workers have this problem. Reported-by: NKyle Zeng <zengyhkyle@gmail.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chengming Zhou 提交于
stable inclusion from stable-v5.10.107 commit 8fdaab341bad8a8449fcdca349e5081e6f62db09 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8fdaab341bad8a8449fcdca349e5081e6f62db09 -------------------------------- [ Upstream commit b773827e ] The error message when I build vm tests on debian10 (GLIBC 2.28): userfaultfd.c: In function `userfaultfd_pagemap_test': userfaultfd.c:1393:37: error: `MADV_PAGEOUT' undeclared (first use in this function); did you mean `MADV_RANDOM'? if (madvise(area_dst, test_pgsize, MADV_PAGEOUT)) ^~~~~~~~~~~~ MADV_RANDOM This patch includes these newer definitions from UAPI linux/mman.h, is useful to fix tests build on systems without these definitions in glibc sys/mman.h. Link: https://lkml.kernel.org/r/20220227055330.43087-2-zhouchengming@bytedance.comSigned-off-by: NChengming Zhou <zhouchengming@bytedance.com> Reviewed-by: NShuah Khan <skhan@linuxfoundation.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Niels Dossche 提交于
stable inclusion from stable-v5.10.107 commit 2490695ffdbafbe79fb9c204df33a4597b1473b4 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2490695ffdbafbe79fb9c204df33a4597b1473b4 -------------------------------- [ Upstream commit f1fb205e ] seqno could be read as a stale value outside of the lock. The lock is already acquired to protect the modification of seqno against a possible race condition. Place the reading of this value also inside this locking to protect it against a possible race condition. Signed-off-by: NNiels Dossche <dossche.niels@gmail.com> Acked-by: NMartin Habets <habetsm.xilinx@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Eric Dumazet 提交于
stable inclusion from stable-v5.10.107 commit 2fad5b6948963bac235eac8261d4cd9165eaf1c2 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2fad5b6948963bac235eac8261d4cd9165eaf1c2 -------------------------------- [ Upstream commit e3d5ea2c ] If recv_actor() returns an incorrect value, tcp_read_sock() might loop forever. Instead, issue a one time warning and make sure to make progress. Signed-off-by: NEric Dumazet <edumazet@google.com> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Acked-by: NJakub Sitnicki <jakub@cloudflare.com> Acked-by: NDaniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20220302161723.3910001-2-eric.dumazet@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sreeramya Soratkal 提交于
stable inclusion from stable-v5.10.107 commit 3f9a8f8a952c4678594d22b601943ad95c62fa18 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f9a8f8a952c4678594d22b601943ad95c62fa18 -------------------------------- [ Upstream commit e50b88c4 ] The wdev channel information is updated post channel switch only for the station mode and not for the other modes. Due to this, the P2P client still points to the old value though it moved to the new channel when the channel change is induced from the P2P GO. Update the bss channel after CSA channel switch completion for P2P client interface as well. Signed-off-by: NSreeramya Soratkal <quic_ssramya@quicinc.com> Link: https://lore.kernel.org/r/1646114600-31479-1-git-send-email-quic_ssramya@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Manasi Navare 提交于
stable inclusion from stable-v5.10.107 commit 0ba557d330946c23559aaea2d51ea649fdeca98a bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0ba557d330946c23559aaea2d51ea649fdeca98a -------------------------------- [ Upstream commit 62929726 ] VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225013055.9282-1-manasi.d.navare@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Golan Ben Ami 提交于
stable inclusion from stable-v5.10.107 commit 9a8e4a5c5b73b4445ccb6bc71f23bbc18bc96d42 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a8e4a5c5b73b4445ccb6bc71f23bbc18bc96d42 -------------------------------- [ Upstream commit 1db5fcbb ] Some APs misbehave when TWT is used and cause our firmware to crash. We don't know a reasonable way to detect and work around this problem in the FW yet. To prevent these crashes, disable TWT in the driver by stopping to advertise TWT support. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215523Signed-off-by: NGolan Ben Ami <golan.ben.ami@intel.com> [reworded the commit message] Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20220301072926.153969-1-luca@coelho.fiSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jia-Ju Bai 提交于
stable inclusion from stable-v5.10.107 commit c5ea0221c8161350c61983479cb3d088fbf6ede4 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5ea0221c8161350c61983479cb3d088fbf6ede4 -------------------------------- [ Upstream commit d4e26aae ] The function ioremap() in fs_init() can fail, so its return value should be checked. Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lad Prabhakar 提交于
stable inclusion from stable-v5.10.107 commit efdd92c18ed4f39602d50dbc4a9d918109715b8d bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=efdd92c18ed4f39602d50dbc4a9d918109715b8d -------------------------------- [ Upstream commit c5048a7b ] Register the CAN device only when all the necessary initialization is completed. This patch makes sure all the data structures and locks are initialized before registering the CAN device. Link: https://lore.kernel.org/all/20220221225935.12300-1-prabhakar.mahadev-lad.rj@bp.renesas.comReported-by: NPavel Machek <pavel@denx.de> Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: NPavel Machek <pavel@denx.de> Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Julian Braha 提交于
stable inclusion from stable-v5.10.107 commit ebe106eac68675a1e6373723d0d8765a6adf3290 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ebe106eac68675a1e6373723d0d8765a6adf3290 -------------------------------- [ Upstream commit 11c57c3b ] Resending this to properly add it to the patch tracker - thanks for letting me know, Arnd :) When ARM is enabled, and BITREVERSE is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for HAVE_ARCH_BITREVERSE Depends on [n]: BITREVERSE [=n] Selected by [y]: - ARM [=y] && (CPU_32v7M [=n] || CPU_32v7 [=y]) && !CPU_32v6 [=n] This is because ARM selects HAVE_ARCH_BITREVERSE without selecting BITREVERSE, despite HAVE_ARCH_BITREVERSE depending on BITREVERSE. This unmet dependency bug was found by Kismet, a static analysis tool for Kconfig. Please advise if this is not the appropriate solution. Signed-off-by: NJulian Braha <julianbraha@gmail.com> Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alexander Lobakin 提交于
stable inclusion from stable-v5.10.107 commit e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b -------------------------------- [ Upstream commit f2703def ] After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on MIPS). A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them: [ 0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35efSigned-off-by: NAlexander Lobakin <alobakin@pm.me> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johannes Berg 提交于
stable inclusion from stable-v5.10.107 commit 8c70b9b470046c9c5f2badfa3048f120d89722e8 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c70b9b470046c9c5f2badfa3048f120d89722e8 -------------------------------- [ Upstream commit a6bce782 ] If an MFP station isn't authorized, the receiver will (or at least should) drop the action frame since it's a robust management frame, but if we're not authorized we haven't installed keys yet. Refuse attempts to start a session as they'd just time out. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20220203201528.ff4d5679dce9.I34bb1f2bc341e161af2d6faf74f91b332ba11285@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Corentin Labbe 提交于
stable inclusion from stable-v5.10.107 commit d687d7559e2460ad306484f64b85a943d7127508 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d687d7559e2460ad306484f64b85a943d7127508 -------------------------------- [ Upstream commit 3916c361 ] crypto-controller had a typo, fix it. In the same time, rename it to just crypto Signed-off-by: NCorentin Labbe <clabbe@baylibre.com> Acked-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220209120355.1985707-1-clabbe@baylibre.comSigned-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sascha Hauer 提交于
stable inclusion from stable-v5.10.107 commit 6f0a94931c479632f1875aec0b53dd33d90dfe11 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6f0a94931c479632f1875aec0b53dd33d90dfe11 -------------------------------- [ Upstream commit be4e65bd ] The binding specifies the clock order to "iahb", "isfr", "cec". Reorder the clocks accordingly. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20220210142353.3420859-1-s.hauer@pengutronix.deSigned-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dinh Nguyen 提交于
stable inclusion from stable-v5.10.107 commit 6493c6aa8b4467c587444aa4b12805f6cc7307c9 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6493c6aa8b4467c587444aa4b12805f6cc7307c9 -------------------------------- [ Upstream commit 268a491a ] The DWC2 USB controller on the Agilex platform does not support clock gating, so use the chip specific "intel,socfpga-agilex-hsotg" compatible. Signed-off-by: NDinh Nguyen <dinguyen@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sascha Hauer 提交于
stable inclusion from stable-v5.10.107 commit c5c8c649fee0833c69c0f768cc3e9531c7701b3b bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5c8c649fee0833c69c0f768cc3e9531c7701b3b -------------------------------- [ Upstream commit 2e8a8b59 ] The binding specifies the clock order to "cec", "grf", "vpll". Reorder the clocks accordingly. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20220126145549.617165-19-s.hauer@pengutronix.deSigned-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jakob Unterwurzacher 提交于
stable inclusion from stable-v5.10.107 commit f7f062919f4101505ff7ce2efccc9dcec5c334cd bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f7f062919f4101505ff7ce2efccc9dcec5c334cd -------------------------------- [ Upstream commit 62966cbd ] There are signal integrity issues running the eMMC at 200MHz on Puma RK3399-Q7. Similar to the work-around found for RK3399 Gru boards, lowering the frequency to 100MHz made the eMMC much more stable, so let's lower the frequency to 100MHz. It might be possible to run at 150MHz as on RK3399 Gru boards but only 100MHz was extensively tested. Cc: Quentin Schulz <foss+kernel@0leil.net> Signed-off-by: NJakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com> Signed-off-by: NQuentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20220119134948.1444965-1-quentin.schulz@theobroma-systems.comSigned-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yan Yan 提交于
stable inclusion from stable-v5.10.107 commit ca142038a54f44ffd407ae2f6c65958f5e382ec6 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ca142038a54f44ffd407ae2f6c65958f5e382ec6 -------------------------------- [ Upstream commit e03c3bba ] xfrm_migrate cannot handle address family change of an xfrm_state. The symptons are the xfrm_state will be migrated to a wrong address, and sending as well as receiving packets wil be broken. This commit fixes it by breaking the original xfrm_state_clone method into two steps so as to update the props.family before running xfrm_init_state. As the result, xfrm_state's inner mode, outer mode, type and IP header length in xfrm_state_migrate can be updated with the new address family. Tested with additions to Android's kernel unit test suite: https://android-review.googlesource.com/c/kernel/tests/+/1885354Signed-off-by: NYan Yan <evitayan@google.com> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yan Yan 提交于
stable inclusion from stable-v5.10.107 commit d8889a445b538dbcc25d9a8c118d18228b5bbab5 bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d8889a445b538dbcc25d9a8c118d18228b5bbab5 -------------------------------- [ Upstream commit c1aca308 ] This patch enables distinguishing SAs and SPs based on if_id during the xfrm_migrate flow. This ensures support for xfrm interfaces throughout the SA/SP lifecycle. When there are multiple existing SPs with the same direction, the same xfrm_selector and different endpoint addresses, xfrm_migrate might fail with ENODATA. Specifically, the code path for performing xfrm_migrate is: Stage 1: find policy to migrate with xfrm_migrate_policy_find(sel, dir, type, net) Stage 2: find and update state(s) with xfrm_migrate_state_find(mp, net) Stage 3: update endpoint address(es) of template(s) with xfrm_policy_migrate(pol, m, num_migrate) Currently "Stage 1" always returns the first xfrm_policy that matches, and "Stage 3" looks for the xfrm_tmpl that matches the old endpoint address. Thus if there are multiple xfrm_policy with same selector, direction, type and net, "Stage 1" might rertun a wrong xfrm_policy and "Stage 3" will fail with ENODATA because it cannot find a xfrm_tmpl with the matching endpoint address. The fix is to allow userspace to pass an if_id and add if_id to the matching rule in Stage 1 and Stage 2 since if_id is a unique ID for xfrm_policy and xfrm_state. For compatibility, if_id will only be checked if the attribute is set. Tested with additions to Android's kernel unit test suite: https://android-review.googlesource.com/c/kernel/tests/+/1668886Signed-off-by: NYan Yan <evitayan@google.com> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kai Lueke 提交于
stable inclusion from stable-v5.10.107 commit bdf0316982f00010d6e56f1379a51cd0568d51cd bugzilla: https://gitee.com/openeuler/kernel/issues/I574A2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bdf0316982f00010d6e56f1379a51cd0568d51cd -------------------------------- commit a3d9001b upstream. This reverts commit 68ac0f38 because ID 0 was meant to be used for configuring the policy/state without matching for a specific interface (e.g., Cilium is affected, see https://github.com/cilium/cilium/pull/18789 and https://github.com/cilium/cilium/pull/19019). Signed-off-by: NKai Lueke <kailueke@linux.microsoft.com> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 07 6月, 2022 5 次提交
-
-
由 Jann Horn 提交于
stable inclusion from stable-v5.10.110 commit 5a41a3033a9344d7683340e3d83f5435ffb06501 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I57IYD CVE: CVE-2022-30594 -------------------------------- commit ee1fee90 upstream. Setting PTRACE_O_SUSPEND_SECCOMP is supposed to be a highly privileged operation because it allows the tracee to completely bypass all seccomp filters on kernels with CONFIG_CHECKPOINT_RESTORE=y. It is only supposed to be settable by a process with global CAP_SYS_ADMIN, and only if that process is not subject to any seccomp filters at all. However, while these permission checks were done on the PTRACE_SETOPTIONS path, they were missing on the PTRACE_SEIZE path, which also sets user-specified ptrace flags. Move the permissions checks out into a helper function and let both ptrace_attach() and ptrace_setoptions() call it. Cc: stable@kernel.org Fixes: 13c4a901 ("seccomp: add ptrace options for suspend/resume") Signed-off-by: NJann Horn <jannh@google.com> Link: https://lkml.kernel.org/r/20220319010838.1386861-1-jannh@google.comSigned-off-by: NEric W. Biederman <ebiederm@xmission.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: 186846, https://gitee.com/openeuler/kernel/issues/I5A80Q -------------------------------- Commit 7bc3e6e5 ("proc: Use a list of inodes to flush from proc") moved proc_flush_task() behind __exit_signal(). Then, process systemd can take long period high cpu usage during releasing task in following concurrent processes: systemd ps kernel_waitid stat(/proc/tgid) do_wait filename_lookup wait_consider_task lookup_fast release_task __exit_signal __unhash_process detach_pid __change_pid // remove task->pid_links d_revalidate -> pid_revalidate // 0 d_invalidate(/proc/tgid) shrink_dcache_parent(/proc/tgid) d_walk(/proc/tgid) spin_lock_nested(/proc/tgid/fd) // iterating opened fd proc_flush_pid | d_invalidate (/proc/tgid/fd) | shrink_dcache_parent(/proc/tgid/fd) | shrink_dentry_list(subdirs) ↓ shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock Function d_invalidate() will remove dentry from hash firstly, but why does proc_flush_pid() process dentry '/proc/tgid/fd' before dentry '/proc/tgid'? That's because proc_pid_make_inode() adds proc inode in reverse order by invoking hlist_add_head_rcu(). But proc should not add any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by adding inode into 'pid->inodes' only if the inode is /proc/tgid or /proc/tgid/task/pid. Performance regression: Create 200 tasks, each task open one file for 50,000 times. Kill all tasks when opened files exceed 10,000,000 (cat /proc/sys/fs/file-nr). Before fix: $ time killall -wq aa real 4m40.946s # During this period, we can see 'ps' and 'systemd' taking high cpu usage. After fix: $ time killall -wq aa real 1m20.732s # During this period, we can see 'systemd' taking high cpu usage. Fixes: 7bc3e6e5 ("proc: Use a list of inodes to flush from proc") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-v5.19-rc1 commit af117837 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I59I14 CVE: CVE-2021-33135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af117837ceb9a78e995804ade4726ad2c2c8981f -------------------------------- Haitao reported encountering a WARN triggered by the ENCLS[ELDU] instruction faulting with a #GP. The WARN is encountered when the reclaimer evicts a range of pages from the enclave when the same pages are faulted back right away. Consider two enclave pages (ENCLAVE_A and ENCLAVE_B) sharing a PCMD page (PCMD_AB). ENCLAVE_A is in the enclave memory and ENCLAVE_B is in the backing store. PCMD_AB contains just one entry, that of ENCLAVE_B. Scenario proceeds where ENCLAVE_A is being evicted from the enclave while ENCLAVE_B is faulted in. sgx_reclaim_pages() { ... /* * Reclaim ENCLAVE_A */ mutex_lock(&encl->lock); /* * Get a reference to ENCLAVE_A's * shmem page where enclave page * encrypted data will be stored * as well as a reference to the * enclave page's PCMD data page, * PCMD_AB. * Release mutex before writing * any data to the shmem pages. */ sgx_encl_get_backing(...); encl_page->desc |= SGX_ENCL_PAGE_BEING_RECLAIMED; mutex_unlock(&encl->lock); /* * Fault ENCLAVE_B */ sgx_vma_fault() { mutex_lock(&encl->lock); /* * Get reference to * ENCLAVE_B's shmem page * as well as PCMD_AB. */ sgx_encl_get_backing(...) /* * Load page back into * enclave via ELDU. */ /* * Release reference to * ENCLAVE_B' shmem page and * PCMD_AB. */ sgx_encl_put_backing(...); /* * PCMD_AB is found empty so * it and ENCLAVE_B's shmem page * are truncated. */ /* Truncate ENCLAVE_B backing page */ sgx_encl_truncate_backing_page(); /* Truncate PCMD_AB */ sgx_encl_truncate_backing_page(); mutex_unlock(&encl->lock); ... } mutex_lock(&encl->lock); encl_page->desc &= ~SGX_ENCL_PAGE_BEING_RECLAIMED; /* * Write encrypted contents of * ENCLAVE_A to ENCLAVE_A shmem * page and its PCMD data to * PCMD_AB. */ sgx_encl_put_backing(...) /* * Reference to PCMD_AB is * dropped and it is truncated. * ENCLAVE_A's PCMD data is lost. */ mutex_unlock(&encl->lock); } What happens next depends on whether it is ENCLAVE_A being faulted in or ENCLAVE_B being evicted - but both end up with ENCLS[ELDU] faulting with a #GP. If ENCLAVE_A is faulted then at the time sgx_encl_get_backing() is called a new PCMD page is allocated and providing the empty PCMD data for ENCLAVE_A would cause ENCLS[ELDU] to #GP If ENCLAVE_B is evicted first then a new PCMD_AB would be allocated by the reclaimer but later when ENCLAVE_A is faulted the ENCLS[ELDU] instruction would #GP during its checks of the PCMD value and the WARN would be encountered. Noting that the reclaimer sets SGX_ENCL_PAGE_BEING_RECLAIMED at the time it obtains a reference to the backing store pages of an enclave page it is in the process of reclaiming, fix the race by only truncating the PCMD page after ensuring that no page sharing the PCMD page is in the process of being reclaimed. Cc: stable@vger.kernel.org Fixes: 08999b24 ("x86/sgx: Free backing memory after faulting the enclave page") Reported-by: NHaitao Huang <haitao.huang@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Link: https://lkml.kernel.org/r/ed20a5db516aa813873268e125680041ae11dfcf.1652389823.git.reinette.chatre@intel.comSigned-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-v5.19-rc1 commit 2154e1c1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I59I14 CVE: CVE-2021-33135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2154e1c11b7080aa19f47160bd26b6f39bbd7824 -------------------------------- Recent commit 08999b24 ("x86/sgx: Free backing memory after faulting the enclave page") expanded __sgx_encl_eldu() to clear an enclave page's PCMD (Paging Crypto MetaData) from the PCMD page in the backing store after the enclave page is restored to the enclave. Since the PCMD page in the backing store is modified the page should be marked as dirty to ensure the modified data is retained. Cc: stable@vger.kernel.org Fixes: 08999b24 ("x86/sgx: Free backing memory after faulting the enclave page") Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Link: https://lkml.kernel.org/r/00cd2ac480db01058d112e347b32599c1a806bc4.1652389823.git.reinette.chatre@intel.comSigned-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jarkko Sakkinen 提交于
mainline inclusion from mainline-v5.17-rc8 commit 08999b24 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I59I14 CVE: CVE-2021-33135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=08999b2489b4c9b939d7483dbd03702ee4576d96 -------------------------------- There is a limited amount of SGX memory (EPC) on each system. When that memory is used up, SGX has its own swapping mechanism which is similar in concept but totally separate from the core mm/* code. Instead of swapping to disk, SGX swaps from EPC to normal RAM. That normal RAM comes from a shared memory pseudo-file and can itself be swapped by the core mm code. There is a hierarchy like this: EPC <-> shmem <-> disk After data is swapped back in from shmem to EPC, the shmem backing storage needs to be freed. Currently, the backing shmem is not freed. This effectively wastes the shmem while the enclave is running. The memory is recovered when the enclave is destroyed and the backing storage freed. Sort this out by freeing memory with shmem_truncate_range(), as soon as a page is faulted back to the EPC. In addition, free the memory for PCMD pages as soon as all PCMD's in a page have been marked as unused by zeroing its contents. Cc: stable@vger.kernel.org Fixes: 1728ab54 ("x86/sgx: Add a page reclaimer") Reported-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/20220303223859.273187-1-jarkko@kernel.orgSigned-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-