- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] RDMA/cma: Do not change route.addr.src_addr.ss_family
by tangbin 21 Jun '22

21 Jun '22

From: Jason Gunthorpe <jgg(a)nvidia.com> mainline inclusion from mainline-v5.15-rc4 commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I59840 CVE: CVE-2021-4028 -------------------------------- Conflicts: The conditional statement to verify RDMA_CM_IDLE state is a little bit different from the upstream to 4.19. The commit 732d41c545bb (RDMA/cma: Make the locking for automatic state transition more clear) is missing from 4.19. So, the context has been modified. If the state is not idle then rdma_bind_addr() will immediately fail and no change to global state should happen. For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4 family, failing the test. This would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Which is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens(). Instead of trying to re-use the src_addr memory to indirectly create an any address build one explicitly on the stack and bind to that as any other normal flow would do. Link: https://lore.kernel.org/r/0-v1-9fbb33f5e201+2a-cma_listen_jgg@nvidia.com Cc: stable(a)vger.kernel.org Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear") Reported-by: syzbot+6bb0528b13611047209c(a)syzkaller.appspotmail.com Tested-by: Hao Sun <sunhao.th(a)gmail.com> Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: tangbin <tangbin(a)cmss.chinamobile.com> --- drivers/infiniband/core/cma.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index 319bfef00a4a..7444df92e7cf 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -3375,8 +3375,13 @@ int rdma_listen(struct rdma_cm_id *id, int backlog) id_priv = container_of(id, struct rdma_id_private, id); if (id_priv->state == RDMA_CM_IDLE) { - id->route.addr.src_addr.ss_family = AF_INET; - ret = rdma_bind_addr(id, cma_src_addr(id_priv)); + struct sockaddr_in any_in = { + .sin_family = AF_INET, + .sin_addr.s_addr = htonl(INADDR_ANY), + }; + + /* For a well behaved ULP state will be RDMA_CM_IDLE */ + ret = rdma_bind_addr(id, (struct sockaddr *)&any_in); if (ret) return ret; } -- 2.18.4

1 0

[PATCH openEuler-1.0-LTS] arm64: fix out-of-range error when adapting for ARM64_SPECTRE_BHB
by Yongqiang Liu 20 Jun '22

20 Jun '22

From: Chen Jiahao <chenjiahao16(a)huawei.com> hulk inclusion category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- In cpufeature.c, when num is set to ARM64_SPECTRE_BHB, it should not be passed to cpu_hwcap_keys, otherwise the out-of-range error would happen as below: UBSAN: Undefined behaviour in arch/arm64/kernel/cpufeature.c:1742:3 index 40 is out of range for type 'static_key_false [39]' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.90+ #1 Call trace: dump_backtrace+0x0/0x390 show_stack+0x24/0x30 dump_stack+0x130/0x188 ubsan_epilogue+0x14/0xa4 __ubsan_handle_out_of_bounds+0x144/0x184 __enable_cpu_capabilities+0x158/0x1d4 setup_cpu_features+0x34/0xc8 smp_cpus_done+0x44/0x13c smp_init+0x188/0x1a4 kernel_init_freeable+0x454/0x974 kernel_init+0x18/0x150 ret_from_fork+0x10/0x18 Because KABI cpu_hwcap_keys is consistent and defined with length ARM64_NCAPS, which is smaller than ARM64_SPECTRE_BHB. Fixes: 2df7cf898c5b ("arm64: fix extra cpucaps setup problem") Signed-off-by: Chen Jiahao <chenjiahao16(a)huawei.com> Reviewed-by: Liao Chang <liaochang1(a)huawei.com> Reviewed-by: Zhang Jianhua <chris.zjh(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- arch/arm64/kernel/cpufeature.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 996d3476f3c8..d7d8a4ab94b4 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1732,8 +1732,10 @@ __enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps, for (; caps->matches; caps++) { unsigned int num = caps->capability; - if (num == ARM64_SPECTRE_BHB) + if (num == ARM64_SPECTRE_BHB) { set_cap_spectre_bhb = true; + continue; + } if (!(caps->type & scope_mask) || !cpus_have_cap(num)) continue; -- 2.25.1

1 0

[Cancel] openEuler kernel SIG例会&技术分享
by openEuler conference 20 Jun '22

20 Jun '22

Sorry! The Zoom meeting will be held at 2022-06-24 14:00 scheduled by openEuler Kernel SIG has been cancelled.

1 0

openEuler kernel SIG例会&技术分享
by openEuler conference 20 Jun '22

20 Jun '22

您好！ Kernel SIG 邀请您参加 2022-06-24 14:00 召开的Zoom会议(自动录制) 会议主题：openEuler kernel SIG例会&技术分享会议内容： openEuler kernel 技术分享：执行实体创建与切换会议链接：https://us06web.zoom.us/j/83567640355?pwd=OHVRQ2VKcFNka0FhVjg2emQybG1Edz09 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID 更多资讯尽在：https://openeuler.org/zh/ Hello! openEuler Kernel SIG invites you to attend the Zoom conference(auto recording) will be held at 2022-06-24 14:00, The subject of the conference is openEuler kernel SIG例会&技术分享, Summary: openEuler kernel 技术分享：执行实体创建与切换 You can join the meeting at https://us06web.zoom.us/j/83567640355?pwd=OHVRQ2VKcFNka0FhVjg2emQybG1Edz09. Add topics at https://etherpad.openeuler.org/p/Kernel-meetings. Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. More information: https://openeuler.org/en/

1 0

openEuler kernel SIG例会&技术分享
by openEuler conference 20 Jun '22

20 Jun '22

您好！ Kernel SIG 邀请您参加 2022-06-24 14:00 召开的Zoom会议(自动录制) 会议主题：openEuler kernel SIG例会&技术分享会议内容： openEuler kernel 技术分享：执行实体创建与切换会议链接：https://us06web.zoom.us/j/81671713618?pwd=eWIxeGowd1hvNTNZQUlRRmplNlZydz09 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID 更多资讯尽在：https://openeuler.org/zh/ Hello! openEuler Kernel SIG invites you to attend the Zoom conference(auto recording) will be held at 2022-06-24 14:00, The subject of the conference is openEuler kernel SIG例会&技术分享, Summary: openEuler kernel 技术分享：执行实体创建与切换 You can join the meeting at https://us06web.zoom.us/j/81671713618?pwd=eWIxeGowd1hvNTNZQUlRRmplNlZydz09. Add topics at https://etherpad.openeuler.org/p/Kernel-meetings. Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. More information: https://openeuler.org/en/

1 0

[PATCH openEuler-1.0-LTS 1/8] xfs: abort xattr scrub if fatal signals are pending
by Laibin Qiu 18 Jun '22

18 Jun '22

From: "Darrick J. Wong" <darrick.wong(a)oracle.com> mainline inclusion from mainline-v5.1-rc1 commit 3258cb208caba74258ffdd8bd59972bbda9bfee1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5BDCU CVE: NA -------------------------------- The extended attribute scrubber should abort the "read all attrs" loop if there's a fatal signal pending on the process. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: tangbin <tangbin(a)cmss.chinamobile.com> Reviewed-by: Lihong Kou <koulihong(a)huawei.com> Reviewed-by: Xuenan Guo <guoxuenan(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> --- fs/xfs/scrub/attr.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/xfs/scrub/attr.c b/fs/xfs/scrub/attr.c index 81d5e90547a1..9960bc5b5d76 100644 --- a/fs/xfs/scrub/attr.c +++ b/fs/xfs/scrub/attr.c @@ -82,6 +82,11 @@ xchk_xattr_listent( sx = container_of(context, struct xchk_xattr, context); + if (xchk_should_terminate(sx->sc, &error)) { + context->seen_enough = 1; + return; + } + if (flags & XFS_ATTR_INCOMPLETE) { /* Incomplete attr key, just mark the inode for preening. */ xchk_ino_set_preen(sx->sc, context->dp->i_ino); -- 2.25.1

1 7

[PATCH openEuler-1.0-LTS 0/8] xfs: fix the xfstests problem
by tangbin 18 Jun '22

18 Jun '22

Hi all: These patches are used to resolve the xfs problem when perform xfstests. For details about how to fix the problem, we can see the link below: https://lore.kernel.org/linux-xfs/154697976479.2839.3584921201780682011.stg… https://lore.kernel.org/linux-xfs/157232182246.593721.4902116478429075171.s… Thanks --- Darrick J. Wong (8): xfs: abort xattr scrub if fatal signals are pending xfs: scrub should flag dir/attr offsets that aren't mappable with xfs_dablk_t xfs: check directory name validity xfs: check attribute name validity xfs: check attribute leaf block structure xfs: namecheck attribute names before listing them xfs: namecheck directory entry names before listing them xfs: replace -EIO with -EFSCORRUPTED for corrupt metadata fs/xfs/libxfs/xfs_attr.c | 17 +++++++++ fs/xfs/libxfs/xfs_attr.h | 2 +- fs/xfs/libxfs/xfs_attr_leaf.c | 68 +++++++++++++++++++++++++++++++++-- fs/xfs/libxfs/xfs_attr_leaf.h | 4 +-- fs/xfs/libxfs/xfs_bmap.c | 6 ++-- fs/xfs/libxfs/xfs_dir2.c | 17 +++++++++ fs/xfs/libxfs/xfs_dir2.h | 1 + fs/xfs/libxfs/xfs_types.c | 11 ++++++ fs/xfs/libxfs/xfs_types.h | 1 + fs/xfs/scrub/attr.c | 11 ++++++ fs/xfs/scrub/bmap.c | 27 ++++++++++++++ fs/xfs/scrub/dir.c | 6 ++++ fs/xfs/xfs_attr_inactive.c | 6 ++-- fs/xfs/xfs_attr_list.c | 60 ++++++++++++++++++++----------- fs/xfs/xfs_dir2_readdir.c | 27 +++++++++++--- fs/xfs/xfs_dquot.c | 2 +- 16 files changed, 228 insertions(+), 38 deletions(-) -- 2.18.4

2 9

[PATCH OLK_5.10] update via-cputemp driver
by LeoLiuoc 17 Jun '22

17 Jun '22

zhaoxin inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I52DS7 CVE: NA -------------------------------- Optimize driver code and add support for Zhaoxin CPU. Signed-off-by: LeoLiuoc <LeoLiu-oc(a)zhaoxin.com> --- drivers/hwmon/Makefile | 3 +- drivers/hwmon/via-cputemp.c | 69 ++++++++++++++++++++----------------- 2 files changed, 39 insertions(+), 33 deletions(-) diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index c22a5316bd91..115c0e002718 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -183,7 +183,8 @@ obj-$(CONFIG_SENSORS_TMP401) += tmp401.o obj-$(CONFIG_SENSORS_TMP421) += tmp421.o obj-$(CONFIG_SENSORS_TMP513) += tmp513.o obj-$(CONFIG_SENSORS_VEXPRESS) += vexpress-hwmon.o -obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o +obj-$(CONFIG_SENSORS_VIA_CPUTEMP) += cputemp-hwmon.o +cputemp-hwmon-objs := via-cputemp.o obj-$(CONFIG_SENSORS_VIA686A) += via686a.o obj-$(CONFIG_SENSORS_VT1211) += vt1211.o obj-$(CONFIG_SENSORS_VT8231) += vt8231.o diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c index e5d18dac8ee7..1599440cc451 100644 --- a/drivers/hwmon/via-cputemp.c +++ b/drivers/hwmon/via-cputemp.c @@ -26,7 +26,8 @@ #include <asm/processor.h> #include <asm/cpu_device_id.h> -#define DRVNAME "via_cputemp" +#define VIA_DRVNAME "via_cputemp" +#define ZHAOXIN_DRVNAME "zhaoxin_cputemp" enum { SHOW_TEMP, SHOW_LABEL, SHOW_NAME }; @@ -114,17 +115,17 @@ static int via_cputemp_probe(struct platform_device *pdev) int err; u32 eax, edx; - data = devm_kzalloc(&pdev->dev, sizeof(struct via_cputemp_data), - GFP_KERNEL); + data = devm_kzalloc(&pdev->dev, sizeof(struct via_cputemp_data), GFP_KERNEL); if (!data) return -ENOMEM; data->id = pdev->id; - data->name = "via_cputemp"; if (c->x86 == 7) { + data->name = ZHAOXIN_DRVNAME; data->msr_temp = 0x1423; } else { + data->name = VIA_DRVNAME; switch (c->x86_model) { case 0xA: /* C7 A */ @@ -145,8 +146,7 @@ static int via_cputemp_probe(struct platform_device *pdev) /* test if we can access the TEMPERATURE MSR */ err = rdmsr_safe_on_cpu(data->id, data->msr_temp, &eax, &edx); if (err) { - dev_err(&pdev->dev, - "Unable to access TEMPERATURE MSR, giving up\n"); + dev_err(&pdev->dev, "Unable to access TEMPERATURE MSR, giving up\n"); return err; } @@ -165,11 +165,10 @@ static int via_cputemp_probe(struct platform_device *pdev) goto exit_remove; } - data->hwmon_dev = hwmon_device_register(&pdev->dev); + data->hwmon_dev = hwmon_device_register_with_info(&pdev->dev, data->name, NULL, NULL, NULL); if (IS_ERR(data->hwmon_dev)) { err = PTR_ERR(data->hwmon_dev); - dev_err(&pdev->dev, "Class registration failed (%d)\n", - err); + dev_err(&pdev->dev, "Class registration failed (%d)\n", err); goto exit_remove; } @@ -194,13 +193,12 @@ static int via_cputemp_remove(struct platform_device *pdev) } static struct platform_driver via_cputemp_driver = { - .driver = { - .name = DRVNAME, - }, .probe = via_cputemp_probe, .remove = via_cputemp_remove, }; +static struct platform_device_info cputemp_device_info; + struct pdev_entry { struct list_head list; struct platform_device *pdev; @@ -216,23 +214,20 @@ static int via_cputemp_online(unsigned int cpu) struct platform_device *pdev; struct pdev_entry *pdev_entry; - pdev = platform_device_alloc(DRVNAME, cpu); - if (!pdev) { - err = -ENOMEM; - pr_err("Device allocation failed\n"); + cputemp_device_info.id = cpu; + + pdev = platform_device_register_full(&cputemp_device_info); + if (IS_ERR(pdev)) { + err = PTR_ERR(pdev); + pr_err("Device registration failed (%d)\n", err); goto exit; } pdev_entry = kzalloc(sizeof(struct pdev_entry), GFP_KERNEL); if (!pdev_entry) { err = -ENOMEM; - goto exit_device_put; - } - - err = platform_device_add(pdev); - if (err) { - pr_err("Device addition failed (%d)\n", err); - goto exit_device_free; + pr_err("Pdev_entry alloc failed (%d)\n", err); + goto exit_device_unregister; } pdev_entry->pdev = pdev; @@ -243,10 +238,8 @@ static int via_cputemp_online(unsigned int cpu) return 0; -exit_device_free: - kfree(pdev_entry); -exit_device_put: - platform_device_put(pdev); +exit_device_unregister: + platform_device_unregister(pdev); exit: return err; } @@ -270,10 +263,11 @@ static int via_cputemp_down_prep(unsigned int cpu) } static const struct x86_cpu_id __initconst cputemp_ids[] = { - X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_C7_A, NULL), - X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_C7_D, NULL), - X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_NANO, NULL), - X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 7, X86_MODEL_ANY, NULL), + X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_C7_A, NULL), + X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_C7_D, NULL), + X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 6, X86_CENTAUR_FAM6_NANO, NULL), + X86_MATCH_VENDOR_FAM_MODEL(CENTAUR, 7, X86_MODEL_ANY, NULL), + X86_MATCH_VENDOR_FAM_MODEL(ZHAOXIN, 7, X86_MODEL_ANY, NULL), {} }; MODULE_DEVICE_TABLE(x86cpu, cputemp_ids); @@ -283,15 +277,26 @@ static enum cpuhp_state via_temp_online; static int __init via_cputemp_init(void) { int err; + char *cpuhp_name; if (!x86_match_cpu(cputemp_ids)) return -ENODEV; + if (boot_cpu_data.x86 == 0x7) { + via_cputemp_driver.driver.name = ZHAOXIN_DRVNAME; + cputemp_device_info.name = ZHAOXIN_DRVNAME; + cpuhp_name = "hwmon/zhaoxin:online"; + } else { + via_cputemp_driver.driver.name = VIA_DRVNAME; + cputemp_device_info.name = VIA_DRVNAME; + cpuhp_name = "hwmon/via:online"; + } + err = platform_driver_register(&via_cputemp_driver); if (err) goto exit; - err = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "hwmon/via:online", + err = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, cpuhp_name, via_cputemp_online, via_cputemp_down_prep); if (err < 0) goto exit_driver_unreg; -- 2.20.1

1 0

[PATCH openEuler-1.0-LTS 1/2] tcp: change source port randomizarion at connect() time
by Yongqiang Liu 17 Jun '22

17 Jun '22

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.246 commit ddec440133913a6b8880e53b896d521a4b7ff24f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5C3A9 CVE: CVE-2022-32296 -------------------------------- commit 190cc82489f46f9d88e73c81a47e14f80a791e1a upstream. RFC 6056 (Recommendations for Transport-Protocol Port Randomization) provides good summary of why source selection needs extra care. David Dworken reminded us that linux implements Algorithm 3 as described in RFC 6056 3.3.3 Quoting David : In the context of the web, this creates an interesting info leak where websites can count how many TCP connections a user's computer is establishing over time. For example, this allows a website to count exactly how many subresources a third party website loaded. This also allows: - Distinguishing between different users behind a VPN based on distinct source port ranges. - Tracking users over time across multiple networks. - Covert communication channels between different browsers/browser profiles running on the same computer - Tracking what applications are running on a computer based on the pattern of how fast source ports are getting incremented. Section 3.3.4 describes an enhancement, that reduces attackers ability to use the basic information currently stored into the shared 'u32 hint'. This change also decreases collision rate when multiple applications need to connect() to different destinations. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: David Dworken <ddworken(a)google.com> Cc: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [SG: Adjusted context] Signed-off-by: Stefan Ghinea <stefan.ghinea(a)windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: net/ipv4/inet_hashtables.c Signed-off-by: Baisong Zhong <zhongbaisong(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/ipv4/inet_hashtables.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c index bd0108aaa45b..72b8b6f44add 100644 --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -666,6 +666,17 @@ void inet_unhash(struct sock *sk) } EXPORT_SYMBOL_GPL(inet_unhash); +/* RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm + * Note that we use 32bit integers (vs RFC 'short integers') + * because 2^16 is not a multiple of num_ephemeral and this + * property might be used by clever attacker. + * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, + * we use 256 instead to really give more isolation and + * privacy, this only consumes 1 KB of kernel memory. + */ +#define INET_TABLE_PERTURB_SHIFT 8 +static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT]; + int __inet_hash_connect(struct inet_timewait_death_row *death_row, struct sock *sk, u64 port_offset, int (*check_established)(struct inet_timewait_death_row *, @@ -679,8 +690,8 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, struct inet_bind_bucket *tb; u32 remaining, offset; int ret, i, low, high; - static u32 hint; int l3mdev; + u32 index; if (port) { head = &hinfo->bhash[inet_bhashfn(net, port, @@ -707,7 +718,10 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, if (likely(remaining > 1)) remaining &= ~1U; - offset = hint + port_offset; + net_get_random_once(table_perturb, sizeof(table_perturb)); + index = hash_32(port_offset, INET_TABLE_PERTURB_SHIFT); + + offset = READ_ONCE(table_perturb[index]) + port_offset; offset %= remaining; /* In first pass we try ports of @low parity. * inet_csk_get_port() does the opposite choice. @@ -762,7 +776,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, return -EADDRNOTAVAIL; ok: - hint += i + 2; + WRITE_ONCE(table_perturb[index], READ_ONCE(table_perturb[index]) + i + 2); /* Head lock still held and bh's disabled */ inet_bind_hash(sk, tb, port); -- 2.25.1

1 1

[PATCH openEuler-1.0-LTS] arm64: fix extra cpucaps setup problem
by Yongqiang Liu 16 Jun '22

16 Jun '22

From: Chen Jiahao <chenjiahao16(a)huawei.com> hulk inclusion category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- When introducing a new cpucaps macro ARM64_SPECTRE_BHB, ARM64_NCAPS was not able to modified easily due to KABI consistency. Here introduce a workaround to properly setup ARM64_SPECTRE_BHB beyond ARM64_NCAPS range. Fixes: def2df575d30 ("KVM: arm64: Add templates for BHB mitigation sequences") Signed-off-by: Chen Jiahao <chenjiahao16(a)huawei.com> Reviewed-by: Zhang Jianhua <chris.zjh(a)huawei.com> Reviewed-by: Liao Chang <liaochang1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- arch/arm64/include/asm/cpufeature.h | 15 +++++++++++++++ arch/arm64/kernel/alternative.c | 5 +++++ arch/arm64/kernel/cpufeature.c | 3 +++ 3 files changed, 23 insertions(+) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h index bfb699957880..ffb0a1ec0088 100644 --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -368,6 +368,8 @@ extern struct static_key_false arm64_const_caps_ready; #define ARM64_NPATCHABLE (ARM64_NCAPS + 1) extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE); +extern bool set_cap_spectre_bhb; + bool this_cpu_has_cap(unsigned int cap); static inline bool cpu_have_feature(unsigned int num) @@ -378,15 +380,23 @@ static inline bool cpu_have_feature(unsigned int num) /* System capability check for constant caps */ static __always_inline bool __cpus_have_const_cap(int num) { + if (num == ARM64_SPECTRE_BHB) + return set_cap_spectre_bhb; + if (num >= ARM64_NCAPS) return false; + return static_branch_unlikely(&cpu_hwcap_keys[num]); } static inline bool cpus_have_cap(unsigned int num) { + if (num == ARM64_SPECTRE_BHB) + return set_cap_spectre_bhb; + if (num >= ARM64_NCAPS) return false; + return test_bit(num, cpu_hwcaps); } @@ -400,6 +410,11 @@ static __always_inline bool cpus_have_const_cap(int num) static inline void cpus_set_cap(unsigned int num) { + if (num == ARM64_SPECTRE_BHB) { + set_cap_spectre_bhb = true; + return; + } + if (num >= ARM64_NCAPS) { pr_warn("Attempt to set an illegal CPU capability (%d >= %d)\n", num, ARM64_NCAPS); diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c index 8511fc3b94bb..ce5a26080b46 100644 --- a/arch/arm64/kernel/alternative.c +++ b/arch/arm64/kernel/alternative.c @@ -41,8 +41,13 @@ struct alt_region { struct alt_instr *end; }; +bool set_cap_spectre_bhb; + bool alternative_is_applied(u16 cpufeature) { + if (cpufeature == ARM64_SPECTRE_BHB) + return set_cap_spectre_bhb; + if (WARN_ON(cpufeature >= ARM64_NCAPS)) return false; diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index aa9178e9acc6..996d3476f3c8 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1732,6 +1732,9 @@ __enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps, for (; caps->matches; caps++) { unsigned int num = caps->capability; + if (num == ARM64_SPECTRE_BHB) + set_cap_spectre_bhb = true; + if (!(caps->type & scope_mask) || !cpus_have_cap(num)) continue; -- 2.25.1

1 0