- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] usb: dwc3: gadget: Free gadget structure only after freeing endpoints
by Zheng Zucheng 04 Mar '24

04 Mar '24

From: Jack Pham <jackp(a)codeaurora.org> mainline inclusion from mainline-v5.13-rc2 commit bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94JH6 CVE: CVE-2021-46986 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Reviewed-by: Peter Chen <peter.chen(a)kernel.org> Signed-off-by: Jack Pham <jackp(a)codeaurora.org> Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/dwc3/gadget.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index a6e682a000fc..c733f71d1506 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3224,8 +3224,9 @@ int dwc3_gadget_init(struct dwc3 *dwc) void dwc3_gadget_exit(struct dwc3 *dwc) { - usb_del_gadget_udc(&dwc->gadget); + usb_del_gadget(dwc->gadget); dwc3_gadget_free_endpoints(dwc); + usb_put_gadget(dwc->gadget); dma_free_coherent(dwc->sysdev, DWC3_BOUNCE_SIZE, dwc->bounce, dwc->bounce_addr); kfree(dwc->setup_buf); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: qualcomm: rmnet: fix global oob in rmnet_policy
by Xia Fukun 04 Mar '24

04 Mar '24

From: Lin Ma <linma(a)zju.edu.cn> mainline inclusion from mainline-v6.8-rc6 commit b33fb5b801c6db408b774a68e7c8722796b59ecc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EDF CVE: CVE-2024-26597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The variable rmnet_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below: ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK> The buggy address belongs to the variable: rmnet_policy+0x30/0xe0 The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here. Fixes: 14452ca3b5ce ("net: qualcomm: rmnet: Export mux_id and flags to netlink") Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Reviewed-by: Subash Abhinov Kasiviswanathan <quic_subashab(a)quicinc.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Jiri Pirko <jiri(a)nvidia.com> Link: https://lore.kernel.org/r/20240110061400.3356108-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c index 4c476fac7835..a7360fb3e45c 100644 --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c @@ -376,7 +376,7 @@ static int rmnet_fill_info(struct sk_buff *skb, const struct net_device *dev) struct rtnl_link_ops rmnet_link_ops __read_mostly = { .kind = "rmnet", - .maxtype = __IFLA_RMNET_MAX, + .maxtype = IFLA_RMNET_MAX, .priv_size = sizeof(struct rmnet_priv), .setup = rmnet_vnd_setup, .validate = rmnet_rtnl_validate, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
by Zheng Yejian 04 Mar '24

04 Mar '24

From: Hans de Goede <hdegoede(a)redhat.com> mainline inclusion from mainline-v5.13-rc3 commit 3a53587423d25c87af4b4126a806a0575104b45e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956GN CVE: CVE-2021-47073 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this. Cc: Mario Limonciello <mario.limonciello(a)outlook.com> Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)outlook.com> Reviewed-by: Mark Gross <mgross(a)linux.intel.com> Link: https://lore.kernel.org/r/20210518125027.21824-1-hdegoede@redhat.com Conflict: drivers/platform/x86/dell-smbios-wmi.c Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/platform/x86/dell-smbios-wmi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/dell-smbios-wmi.c b/drivers/platform/x86/dell-smbios-wmi.c index cf2229ece9ff..ccccce9b67ef 100644 --- a/drivers/platform/x86/dell-smbios-wmi.c +++ b/drivers/platform/x86/dell-smbios-wmi.c @@ -274,7 +274,8 @@ int init_dell_smbios_wmi(void) void exit_dell_smbios_wmi(void) { - wmi_driver_unregister(&dell_smbios_wmi_driver); + if (wmi_supported) + wmi_driver_unregister(&dell_smbios_wmi_driver); } MODULE_ALIAS("wmi:" DELL_WMI_SMBIOS_GUID); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] i2c: validate user data in compat ioctl
by Hongbo Li 04 Mar '24

04 Mar '24

Fix CVE-2021-46934 Pavel Skripkin (1): i2c: validate user data in compat ioctl drivers/i2c/i2c-dev.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
by Zheng Yejian 04 Mar '24

04 Mar '24

From: Hans de Goede <hdegoede(a)redhat.com> init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this. Cc: Mario Limonciello <mario.limonciello(a)outlook.com> Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)outlook.com> Reviewed-by: Mark Gross <mgross(a)linux.intel.com> Link: https://lore.kernel.org/r/20210518125027.21824-1-hdegoede@redhat.com Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Conflict: drivers/platform/x86/dell-smbios-wmi.c Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/platform/x86/dell-smbios-wmi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/dell-smbios-wmi.c b/drivers/platform/x86/dell-smbios-wmi.c index cf2229ece9ff..ccccce9b67ef 100644 --- a/drivers/platform/x86/dell-smbios-wmi.c +++ b/drivers/platform/x86/dell-smbios-wmi.c @@ -274,7 +274,8 @@ int init_dell_smbios_wmi(void) void exit_dell_smbios_wmi(void) { - wmi_driver_unregister(&dell_smbios_wmi_driver); + if (wmi_supported) + wmi_driver_unregister(&dell_smbios_wmi_driver); } MODULE_ALIAS("wmi:" DELL_WMI_SMBIOS_GUID); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] arm64/mpam: Skip updates of unrelated ctrl type
by Zeng Heng 04 Mar '24

04 Mar '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I95IFB CVE: NA ---------------------------------------- Add ctrl_updated variable and only when ctrl_updated is true, the new control configuration needs to deliver. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/include/asm/resctrl.h | 1 + arch/arm64/kernel/mpam/mpam_ctrlmon.c | 24 +++++++++++++++++------- arch/arm64/kernel/mpam/mpam_resctrl.c | 2 ++ 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/resctrl.h b/arch/arm64/include/asm/resctrl.h index 2865397740b4..d46b9ffe6c88 100644 --- a/arch/arm64/include/asm/resctrl.h +++ b/arch/arm64/include/asm/resctrl.h @@ -295,6 +295,7 @@ do { \ struct resctrl_staged_config { hw_closid_t hw_closid; u32 new_ctrl[SCHEMA_NUM_CTRL_TYPE]; + bool ctrl_updated[SCHEMA_NUM_CTRL_TYPE]; bool have_new_ctrl; enum resctrl_conf_type conf_type; enum resctrl_ctrl_type ctrl_type; diff --git a/arch/arm64/kernel/mpam/mpam_ctrlmon.c b/arch/arm64/kernel/mpam/mpam_ctrlmon.c index 9bf4f68fb2f5..7659b29e6fe3 100644 --- a/arch/arm64/kernel/mpam/mpam_ctrlmon.c +++ b/arch/arm64/kernel/mpam/mpam_ctrlmon.c @@ -265,7 +265,8 @@ static void resctrl_group_update_domain_ctrls(struct rdtgroup *rdtgrp, closid.intpartid = hw_closid_val(cfg[i].hw_closid); for_each_ctrl_type(type) { /* if ctrl group's config has changed, refresh it first. */ - if (dom->ctrl_val[closid.intpartid] != cfg[i].new_ctrl) { + if (dom->ctrl_val[type][closid.intpartid] != cfg[i].new_ctrl[type] && + cfg[i].ctrl_updated[type] == true) { /* * duplicate ctrl group's configuration indexed * by intpartid from domain ctrl_val array. @@ -400,6 +401,7 @@ ssize_t resctrl_group_schemata_write(struct kernfs_open_file *of, struct mpam_resctrl_res *res; enum resctrl_conf_type conf_type; struct resctrl_staged_config *cfg; + enum resctrl_ctrl_type t; char *tok, *resname; u32 closid; int ret = 0; @@ -422,13 +424,17 @@ ssize_t resctrl_group_schemata_write(struct kernfs_open_file *of, for_each_supported_resctrl_exports(res) { r = &res->resctrl_res; - if (r->alloc_enabled) { - list_for_each_entry(dom, &r->domains, list) { - dom->have_new_ctrl = false; - for_each_conf_type(conf_type) { - cfg = &dom->staged_cfg[conf_type]; - cfg->have_new_ctrl = false; + if (!r->alloc_enabled) + continue; + + list_for_each_entry(dom, &r->domains, list) { + dom->have_new_ctrl = false; + for_each_conf_type(conf_type) { + cfg = &dom->staged_cfg[conf_type]; + for_each_ctrl_type(t) { + cfg->ctrl_updated[t] = false; } + cfg->have_new_ctrl = false; } } } @@ -908,11 +914,13 @@ static void rdtgroup_init_mba(struct resctrl_schema *s, u32 closid) cfg = &d->staged_cfg[CDP_BOTH]; cfg->cdp_both_ctrl = s->cdp_mc_both; cfg->new_ctrl[SCHEMA_COMM] = rr->ctrl_features[SCHEMA_COMM].default_ctrl; + cfg->ctrl_updated[SCHEMA_COMM] = true; resctrl_cdp_mpamid_map(closid, CDP_BOTH, cfg->hw_closid); cfg->have_new_ctrl = true; /* Set extension ctrl default value, e.g. priority/hardlimit */ for_each_extend_ctrl_type(t) { cfg->new_ctrl[t] = rr->ctrl_features[t].default_ctrl; + cfg->ctrl_updated[t] = true; } } } @@ -965,6 +973,7 @@ static int rdtgroup_init_cat(struct resctrl_schema *s, u32 closid) } resctrl_cdp_mpamid_map(closid, conf_type, cfg->hw_closid); + cfg->ctrl_updated[SCHEMA_COMM] = true; cfg->have_new_ctrl = true; /* @@ -974,6 +983,7 @@ static int rdtgroup_init_cat(struct resctrl_schema *s, u32 closid) for_each_extend_ctrl_type(ctrl_type) { cfg->new_ctrl[ctrl_type] = rr->ctrl_features[ctrl_type].default_ctrl; + cfg->ctrl_updated[ctrl_type] = true; } } diff --git a/arch/arm64/kernel/mpam/mpam_resctrl.c b/arch/arm64/kernel/mpam/mpam_resctrl.c index 5901261d17fc..7dcb75accf86 100644 --- a/arch/arm64/kernel/mpam/mpam_resctrl.c +++ b/arch/arm64/kernel/mpam/mpam_resctrl.c @@ -322,6 +322,7 @@ parse_cache(char *buf, struct resctrl_resource *r, return -EINVAL; cfg->new_ctrl[type] = data; + cfg->ctrl_updated[type] = true; cfg->have_new_ctrl = true; return 0; @@ -364,6 +365,7 @@ parse_bw(char *buf, struct resctrl_resource *r, return -EINVAL; cfg->new_ctrl[type] = data; + cfg->ctrl_updated[type] = true; cfg->have_new_ctrl = true; return 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] arm64/mpam: set default feedback of last_cmd_status interface as null string
by Zeng Heng 04 Mar '24

04 Mar '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I95IFO CVE: NA ---------------------------------------- Set default feedback of last_cmd_status interface as null string, in case misunderstanding the execution result of the previous command. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/kernel/mpam/mpam_resctrl.c | 2 +- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/mpam/mpam_resctrl.c b/arch/arm64/kernel/mpam/mpam_resctrl.c index 60d3d8706a38..5901261d17fc 100644 --- a/arch/arm64/kernel/mpam/mpam_resctrl.c +++ b/arch/arm64/kernel/mpam/mpam_resctrl.c @@ -1749,7 +1749,7 @@ static int resctrl_last_cmd_status_show(struct kernfs_open_file *of, if (len) seq_printf(seq, "%.*s", len, last_cmd_status_buf); else - seq_puts(seq, "ok\n"); + seq_puts(seq, ""); mutex_unlock(&resctrl_group_mutex); return 0; } diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c index a2d7e6646cce..686f685c8c7e 100644 --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c @@ -743,7 +743,7 @@ static int rdt_last_cmd_status_show(struct kernfs_open_file *of, if (len) seq_printf(seq, "%.*s", len, last_cmd_status_buf); else - seq_puts(seq, "ok\n"); + seq_puts(seq, ""); mutex_unlock(&rdtgroup_mutex); return 0; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] arm64/mpam: support resctrl fs to show mounting option
by Zeng Heng 04 Mar '24

04 Mar '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I95IFL CVE: NA ---------------------------------------- Support to display MPAM mounting options: # mount -t resctrl resctrl /sys/fs/resctrl/ -o cdpl3,mbMin,mbMax,mbHdl,caPbm # mount | grep resctrl resctrl on /sys/fs/resctrl type resctrl (rw,relatime,cdpl3,caPbm,mbMax,mbMin,mbHdl) Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/include/asm/resctrl.h | 5 +--- arch/arm64/kernel/mpam/mpam_ctrlmon.c | 34 +++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/resctrl.h b/arch/arm64/include/asm/resctrl.h index 3fceaa482e5a..2865397740b4 100644 --- a/arch/arm64/include/asm/resctrl.h +++ b/arch/arm64/include/asm/resctrl.h @@ -415,10 +415,7 @@ void resctrl_resource_reset(void); int resctrl_group_init_alloc(struct rdtgroup *rdtgrp); -static inline int __resctrl_group_show_options(struct seq_file *seq) -{ - return 0; -} +int __resctrl_group_show_options(struct seq_file *seq); int resctrl_update_groups_config(struct rdtgroup *rdtgrp); diff --git a/arch/arm64/kernel/mpam/mpam_ctrlmon.c b/arch/arm64/kernel/mpam/mpam_ctrlmon.c index 4b8429ceddb6..9bf4f68fb2f5 100644 --- a/arch/arm64/kernel/mpam/mpam_ctrlmon.c +++ b/arch/arm64/kernel/mpam/mpam_ctrlmon.c @@ -1027,3 +1027,37 @@ int resctrl_update_groups_config(struct rdtgroup *rdtgrp) return ret; } + +int __resctrl_group_show_options(struct seq_file *seq) +{ + struct resctrl_resource *res; + struct raw_resctrl_resource *r; + + res = mpam_resctrl_get_resource(RDT_RESOURCE_L3); + if (res && res->cdp_enable) + seq_puts(seq, ",cdpl3"); + + res = mpam_resctrl_get_resource(RDT_RESOURCE_L2); + if (res && res->cdp_enable) + seq_puts(seq, ",cdpl2"); + + r = mpam_get_raw_resctrl_resource(RDT_RESOURCE_L3); + if (r && r->ctrl_features[SCHEMA_PBM].enabled) + seq_puts(seq, ",caPbm"); + if (r && r->ctrl_features[SCHEMA_MAX].enabled) + seq_puts(seq, ",caMax"); + if (r && r->ctrl_features[SCHEMA_PRI].enabled) + seq_puts(seq, ",caPrio"); + + r = mpam_get_raw_resctrl_resource(RDT_RESOURCE_MC); + if (r && r->ctrl_features[SCHEMA_MAX].enabled) + seq_puts(seq, ",mbMax"); + if (r && r->ctrl_features[SCHEMA_MIN].enabled) + seq_puts(seq, ",mbMin"); + if (r && r->ctrl_features[SCHEMA_HDL].enabled) + seq_puts(seq, ",mbHdl"); + if (r && r->ctrl_features[SCHEMA_PRI].enabled) + seq_puts(seq, ",mbPrio"); + + return 0; +} -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
by Zhengchao Shao 04 Mar '24

04 Mar '24

From: Yuxuan Hu <20373622(a)buaa.edu.cn> mainline inclusion from mainline-v6.8-rc7 commit 2535b848fa0f42ddff3e5255cf5e742c9b77bb26 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8YV3O CVE: CVE-2024-22099 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx. Signed-off-by: Yuxuan Hu <20373622(a)buaa.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/bluetooth/rfcomm/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c index 8d6fce9005bd..4f54c7df3a94 100644 --- a/net/bluetooth/rfcomm/core.c +++ b/net/bluetooth/rfcomm/core.c @@ -1937,7 +1937,7 @@ static struct rfcomm_session *rfcomm_process_rx(struct rfcomm_session *s) /* Get data directly from socket receive queue without copying it. */ while ((skb = skb_dequeue(&sk->sk_receive_queue))) { skb_orphan(skb); - if (!skb_linearize(skb)) { + if (!skb_linearize(skb) && sk->sk_state != BT_CLOSED) { s = rfcomm_recv_frame(s, skb); if (!s) break; -- 2.34.1

2 1

[PATCH OLK-5.10] Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
by Zhengchao Shao 04 Mar '24

04 Mar '24

From: Yuxuan Hu <20373622(a)buaa.edu.cn> mainline inclusion from mainline-v6.8-rc7 commit 2535b848fa0f42ddff3e5255cf5e742c9b77bb26 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8YV3O CVE: CVE-2024-22099 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx. Signed-off-by: Yuxuan Hu <20373622(a)buaa.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/bluetooth/rfcomm/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c index 8d6fce9005bd..4f54c7df3a94 100644 --- a/net/bluetooth/rfcomm/core.c +++ b/net/bluetooth/rfcomm/core.c @@ -1937,7 +1937,7 @@ static struct rfcomm_session *rfcomm_process_rx(struct rfcomm_session *s) /* Get data directly from socket receive queue without copying it. */ while ((skb = skb_dequeue(&sk->sk_receive_queue))) { skb_orphan(skb); - if (!skb_linearize(skb)) { + if (!skb_linearize(skb) && sk->sk_state != BT_CLOSED) { s = rfcomm_recv_frame(s, skb); if (!s) break; -- 2.34.1

2 1