- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 2208/2208] include/trace/stages/init.h:2:23: warning: 'str__bonding__trace_system_name' defined but not used
by kernel test robot 08 May '25

08 May '25

Hi Wei, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 66448995cc552d846c7442188f69e833f4a86676 commit: 69ddcb21328bd29cfd2f64710bdac158f4c90bf6 [2208/2208] drivers: hooks: add bonding driver vendor hooks config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20250508/202505080910.94UlZrA0-lkp@…) compiler: loongarch64-linux-gcc (GCC) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250508/202505080910.94UlZrA0-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202505080910.94UlZrA0-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from include/trace/trace_events.h:27, from include/trace/define_trace.h:102, from include/trace/hooks/bonding.h:27, from drivers/hooks/vendor_hooks.c:11: >> include/trace/stages/init.h:2:23: warning: 'str__bonding__trace_system_name' defined but not used [-Wunused-const-variable=] 2 | #define __app__(x, y) str__##x##y | ^~~~~ include/trace/stages/init.h:3:21: note: in expansion of macro '__app__' 3 | #define __app(x, y) __app__(x, y) | ^~~~~~~ include/trace/stages/init.h:5:29: note: in expansion of macro '__app' 5 | #define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name) | ^~~~~ include/trace/stages/init.h:8:27: note: in expansion of macro 'TRACE_SYSTEM_STRING' 8 | static const char TRACE_SYSTEM_STRING[] = \ | ^~~~~~~~~~~~~~~~~~~ include/trace/stages/init.h:11:1: note: in expansion of macro 'TRACE_MAKE_SYSTEM_STR' 11 | TRACE_MAKE_SYSTEM_STR(); | ^~~~~~~~~~~~~~~~~~~~~ vim +/str__bonding__trace_system_name +2 include/trace/stages/init.h af6b9668e85ffd Steven Rostedt (Google 2022-03-03 @2) #define __app__(x, y) str__##x##y af6b9668e85ffd Steven Rostedt (Google 2022-03-03 3) #define __app(x, y) __app__(x, y) af6b9668e85ffd Steven Rostedt (Google 2022-03-03 4) :::::: The code at line 2 was first introduced by commit :::::: af6b9668e85ffd1502aada8036ccbf4dbd481708 tracing: Move the defines to create TRACE_EVENTS into their own files :::::: TO: Steven Rostedt (Google) <rostedt(a)goodmis.org> :::::: CC: Steven Rostedt (Google) <rostedt(a)goodmis.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 2208/2208] drivers/net/ethernet/yunsilicon/xsc/pci/xsc_lag.c:1128:21: warning: variable 'bond_dev' set but not used
by kernel test robot 08 May '25

08 May '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 66448995cc552d846c7442188f69e833f4a86676 commit: d0888acfac5d4aca4538e40f027e80d9230c5002 [2208/2208] drivers: update Yunsilicon drivers to version rel_2412_std_card config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20250508/202505080526.qCQgtY7V-lkp@…) compiler: clang version 20.1.2 (https://github.com/llvm/llvm-project 58df0ef89dd64126512e4ee27b4ac3fd8ddf6247) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250508/202505080526.qCQgtY7V-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202505080526.qCQgtY7V-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/ethernet/yunsilicon/xsc/pci/xsc_lag.c:1128:21: warning: variable 'bond_dev' set but not used [-Wunused-but-set-variable] 1128 | struct net_device *bond_dev; | ^ 1 warning generated. -- >> drivers/net/ethernet/yunsilicon/xsc/pci/sriov_sysfs.c:911:31: warning: unused variable 'vf_type_ib' [-Wunused-const-variable] 911 | static const struct kobj_type vf_type_ib = { | ^~~~~~~~~~ 1 warning generated. vim +/bond_dev +1128 drivers/net/ethernet/yunsilicon/xsc/pci/xsc_lag.c 601fb01dc16f74 tianx 2024-04-11 1122 bcfb3e65a5707c Tian Xin 2024-10-30 1123 static void xsc_handle_changelowerstate_event(struct xsc_board_lag *board_lag, bcfb3e65a5707c Tian Xin 2024-10-30 1124 struct net_device *ndev, bcfb3e65a5707c Tian Xin 2024-10-30 1125 struct netdev_notifier_changelowerstate_info *info) 601fb01dc16f74 tianx 2024-04-11 1126 { bcfb3e65a5707c Tian Xin 2024-10-30 1127 struct netdev_lag_lower_state_info *lag_lower_info; bcfb3e65a5707c Tian Xin 2024-10-30 @1128 struct net_device *bond_dev; bcfb3e65a5707c Tian Xin 2024-10-30 1129 struct slave *slave; bcfb3e65a5707c Tian Xin 2024-10-30 1130 struct xsc_lag *lag; bcfb3e65a5707c Tian Xin 2024-10-30 1131 u8 bond_id; bcfb3e65a5707c Tian Xin 2024-10-30 1132 enum lag_slave_status slave_status = XSC_LAG_SLAVE_INACTIVE; d0888acfac5d4a Xin Tian 2025-04-29 1133 struct xsc_adapter *adapter; d0888acfac5d4a Xin Tian 2025-04-29 1134 struct xsc_core_device *xdev; 601fb01dc16f74 tianx 2024-04-11 1135 bcfb3e65a5707c Tian Xin 2024-10-30 1136 if (!netif_is_lag_port(ndev) || !info->lower_state_info) bcfb3e65a5707c Tian Xin 2024-10-30 1137 return; 601fb01dc16f74 tianx 2024-04-11 1138 bcfb3e65a5707c Tian Xin 2024-10-30 1139 rcu_read_lock(); bcfb3e65a5707c Tian Xin 2024-10-30 1140 slave = bond_slave_get_rtnl(ndev); bcfb3e65a5707c Tian Xin 2024-10-30 1141 rcu_read_unlock(); bcfb3e65a5707c Tian Xin 2024-10-30 1142 if (!slave || !slave->bond || !slave->bond->dev) bcfb3e65a5707c Tian Xin 2024-10-30 1143 return; 601fb01dc16f74 tianx 2024-04-11 1144 bcfb3e65a5707c Tian Xin 2024-10-30 1145 bond_dev = slave->bond->dev; bcfb3e65a5707c Tian Xin 2024-10-30 1146 bcfb3e65a5707c Tian Xin 2024-10-30 1147 lag_lower_info = info->lower_state_info; bcfb3e65a5707c Tian Xin 2024-10-30 1148 if (lag_lower_info->link_up && lag_lower_info->tx_enabled) bcfb3e65a5707c Tian Xin 2024-10-30 1149 slave_status = XSC_LAG_SLAVE_ACTIVE; bcfb3e65a5707c Tian Xin 2024-10-30 1150 bcfb3e65a5707c Tian Xin 2024-10-30 1151 mutex_lock(&board_lag->lock); bcfb3e65a5707c Tian Xin 2024-10-30 1152 if (!xsc_board_lag_filter(board_lag, ndev)) { bcfb3e65a5707c Tian Xin 2024-10-30 1153 mutex_unlock(&board_lag->lock); bcfb3e65a5707c Tian Xin 2024-10-30 1154 return; 601fb01dc16f74 tianx 2024-04-11 1155 } 601fb01dc16f74 tianx 2024-04-11 1156 d0888acfac5d4a Xin Tian 2025-04-29 1157 adapter = netdev_priv(ndev); d0888acfac5d4a Xin Tian 2025-04-29 1158 xdev = adapter->xdev; d0888acfac5d4a Xin Tian 2025-04-29 1159 bond_id = xdev->bond_id; bcfb3e65a5707c Tian Xin 2024-10-30 1160 if (bond_id == BOND_ID_INVALID) { bcfb3e65a5707c Tian Xin 2024-10-30 1161 mutex_unlock(&board_lag->lock); bcfb3e65a5707c Tian Xin 2024-10-30 1162 return; 601fb01dc16f74 tianx 2024-04-11 1163 } 601fb01dc16f74 tianx 2024-04-11 1164 bcfb3e65a5707c Tian Xin 2024-10-30 1165 lag = &board_lag->xsc_lag[bond_id]; bcfb3e65a5707c Tian Xin 2024-10-30 1166 pack_lag_update_member_status(lag, ndev, slave_status); bcfb3e65a5707c Tian Xin 2024-10-30 1167 mutex_unlock(&board_lag->lock); bcfb3e65a5707c Tian Xin 2024-10-30 1168 bcfb3e65a5707c Tian Xin 2024-10-30 1169 return; 601fb01dc16f74 tianx 2024-04-11 1170 } 601fb01dc16f74 tianx 2024-04-11 1171 :::::: The code at line 1128 was first introduced by commit :::::: bcfb3e65a5707ca4caf593a33276f26b993ad71e drivers: update Yunsilicon driver to version 2406_rc16 :::::: TO: Tian Xin <tianx(a)yunsilicon.com> :::::: CC: Tian Xin <tianx(a)yunsilicon.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

openEuler Kernel SIG双周例会
by openEuler conference 07 May '25

07 May '25

您好！ Kernel 邀请您参加 2025-05-09 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 议题征集中（新增议题可回复此邮件申请，也可直接填报至会议纪要看板。）会议链接：https://meeting.huaweicloud.com:36443/#/j/964960259 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! Kernel invites you to attend the WeLink conference(auto recording) will be held at 2025-05-09 14:00, The subject of the conference is openEuler Kernel SIG双周例会 Summary: 1. 进展update 2. 议题征集中（新增议题可回复此邮件申请，也可直接填报至会议纪要看板。） You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/964960259 Add topics at https://etherpad.openeuler.org/p/Kernel-meetings More information: https://www.openeuler.org/en/

1 0

[PATCH OLK-6.6] ksmbd: Fix dangling pointer in krb_authenticate
by Wang Zhaolong 07 May '25

07 May '25

From: Sean Heelan <seanheelan(a)gmail.com> stable inclusion from stable-v6.6.88 commit 1db2451de23e98bc864c6a6e52aa0d82c91cb325 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC5BMV CVE: CVE-2025-37778 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e440d5b25b7efccb3defe542a73c51005799a5f upstream. krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user. Cc: stable(a)vger.kernel.org Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/smb/server/smb2pdu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 2074d977d5c9..80ef2f4b9210 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -1591,12 +1591,14 @@ static int krb5_authenticate(struct ksmbd_work *work, /* Check previous session */ prev_sess_id = le64_to_cpu(req->PreviousSessionId); if (prev_sess_id && prev_sess_id != sess->id) destroy_previous_session(conn, sess->user, prev_sess_id); - if (sess->state == SMB2_SESSION_VALID) + if (sess->state == SMB2_SESSION_VALID) { ksmbd_free_user(sess->user); + sess->user = NULL; + } retval = ksmbd_krb5_authenticate(sess, in_blob, in_len, out_blob, &out_len); if (retval) { ksmbd_debug(SMB, "krb5 authentication failed\n"); -- 2.34.3

2 1

[PATCH OLK-6.6] vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp
by Tengda Wu 07 May '25

07 May '25

From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from stable-6.6.89 commit c4312c4d244aa58e811ff0297e013124d115e793 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC5I61 CVE: CVE-2025-37799 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4c2227656d9003f4d77afc76f34dd81b95e4c2c4 upstream. vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that is, packet sizes between 128 - 3k bytes). We noticed MTU-related connectivity issues with Cilium's service load- balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP backend service where the XDP LB was doing IPIP encap led to overly large packet sizes but only for *some* of the packets (e.g. HTTP GET request) while others (e.g. the prior TCP 3WHS) looked completely fine on the wire. In fact, the pcap recording on the backend node actually revealed that the node with the XDP LB was leaking uninitialized kernel data onto the wire for the affected packets, for example, while the packets should have been 152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes was padded with whatever other data was in that page at the time (e.g. we saw user/payload data from prior processed packets). We only noticed this through an MTU issue, e.g. when the XDP LB node and the backend node both had the same MTU (e.g. 1500) then the curl request got dropped on the backend node's NIC given the packet was too large even though the IPIP-encapped packet normally would never even come close to the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let the curl request succeed (which also indicates that the kernel ignored the padding, and thus the issue wasn't very user-visible). Commit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs to stick to rcd->len which is the actual packet length from the descriptor. The latter we also feed into vmxnet3_process_xdp_small(), by the way, and it indicates the correct length needed to initialize the xdp->{data,data_end} parts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the relevant part was adapting xdp_init_buff() to address the warning given the xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on the wire looks good again. Fixes: e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Tested-by: Andrew Sauber <andrew.sauber(a)isovalent.com> Cc: Anton Protopopov <aspsk(a)isovalent.com> Cc: William Tu <witu(a)nvidia.com> Cc: Martin Zaharinov <micron10(a)gmail.com> Cc: Ronak Doshi <ronak.doshi(a)broadcom.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250423133600.176689-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/net/vmxnet3/vmxnet3_xdp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/vmxnet3/vmxnet3_xdp.c b/drivers/net/vmxnet3/vmxnet3_xdp.c index 616ecc38d172..5f470499e600 100644 --- a/drivers/net/vmxnet3/vmxnet3_xdp.c +++ b/drivers/net/vmxnet3/vmxnet3_xdp.c @@ -397,7 +397,7 @@ vmxnet3_process_xdp(struct vmxnet3_adapter *adapter, xdp_init_buff(&xdp, PAGE_SIZE, &rq->xdp_rxq); xdp_prepare_buff(&xdp, page_address(page), rq->page_pool->p.offset, - rbi->len, false); + rcd->len, false); xdp_buff_clear_frags_flag(&xdp); xdp_prog = rcu_dereference(rq->adapter->xdp_bpf_prog); -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] fix CVE-2023-53093
by Tengda Wu 07 May '25

07 May '25

fix CVE-2023-53093. Steven Rostedt (Google) (2): tracing: Do not let histogram values have some modifiers tracing/histograms: Allow variables to have some modifiers kernel/trace/trace_events_hist.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- 2.34.1

2 3

[PATCH OLK-5.10] vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
by Yin Tirui 07 May '25

07 May '25

From: Mike Christie <michael.christie(a)oracle.com> mainline inclusion from mainline-v6.15-rc1 commit 5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP35K CVE: CVE-2025-22083 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first. Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session") Fixes: 4f7f46d32c98 ("tcm_vhost: Use vq->private_data to indicate if the endpoint is setup") Reported-by: Haoran Zhang <wh1sper(a)zju.edu.cn> Closes: https://lore.kernel.org/virtualization/e418a5ee-45ca-4d18-9b5d-6f8b6b1add8e… Signed-off-by: Mike Christie <michael.christie(a)oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com> Message-Id: <20250129210922.121533-1-michael.christie(a)oracle.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Acked-by: Stefano Garzarella <sgarzare(a)redhat.com> Conflicts: drivers/vhost/scsi.c [Fixing context conflicts] Signed-off-by: Yin Tirui <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/vhost/scsi.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index a23a65e7d828..f896c8a83f1a 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -1589,14 +1589,19 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, } } + if (vs->vs_tpg) { + pr_err("vhost-scsi endpoint already set for %s.\n", + vs->vs_vhost_wwpn); + ret = -EEXIST; + goto out; + } + len = sizeof(vs_tpg[0]) * VHOST_SCSI_MAX_TARGET; vs_tpg = kzalloc(len, GFP_KERNEL); if (!vs_tpg) { ret = -ENOMEM; goto out; } - if (vs->vs_tpg) - memcpy(vs_tpg, vs->vs_tpg, len); list_for_each_entry(tpg, &vhost_scsi_list, tv_tpg_list) { mutex_lock(&tpg->tv_tpg_mutex); @@ -1611,11 +1616,6 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, tv_tport = tpg->tport; if (!strcmp(tv_tport->tport_name, t->vhost_wwpn)) { - if (vs->vs_tpg && vs->vs_tpg[tpg->tport_tpgt]) { - mutex_unlock(&tpg->tv_tpg_mutex); - ret = -EEXIST; - goto undepend; - } /* * In order to ensure individual vhost-scsi configfs * groups cannot be removed while in use by vhost ioctl, @@ -1660,15 +1660,15 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, } ret = 0; } else { - ret = -EEXIST; + ret = -ENODEV; + goto free_tpg; } /* - * Act as synchronize_rcu to make sure access to - * old vs->vs_tpg is finished. + * Act as synchronize_rcu to make sure requests after this point + * see a fully setup device. */ vhost_scsi_flush(vs); - kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; goto out; @@ -1685,6 +1685,7 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, target_undepend_item(&tpg->se_tpg.tpg_group.cg_item); } } +free_tpg: kfree(vs_tpg); out: mutex_unlock(&vs->dev.mutex); @@ -1773,6 +1774,7 @@ vhost_scsi_clear_endpoint(struct vhost_scsi *vs, vhost_scsi_flush(vs); kfree(vs->vs_tpg); vs->vs_tpg = NULL; + memset(vs->vs_vhost_wwpn, 0, sizeof(vs->vs_vhost_wwpn)); WARN_ON(vs->vs_events_nr); mutex_unlock(&vs->dev.mutex); mutex_unlock(&vhost_scsi_mutex); -- 2.22.0

2 1

[PATCH OLK-5.10] ice: fix memory leak in aRFS after reset
by Yin Tirui 07 May '25

07 May '25

From: Grzegorz Nitka <grzegorz.nitka(a)intel.com> mainline inclusion from mainline-v6.14-rc7 commit 23d97f18901ef5e4e264e3b1777fe65c760186b5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBY42R CVE: CVE-2025-21981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... Fixes: 28bf26724fdb ("ice: Implement aRFS") Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka(a)intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/ice/ice_arfs.c [context conflict] Signed-off-by: Tirui Yin <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c index eca2ba2eea8c..085b1a0d67c5 100644 --- a/drivers/net/ethernet/intel/ice/ice_arfs.c +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c @@ -510,7 +510,7 @@ void ice_init_arfs(struct ice_vsi *vsi) struct hlist_head *arfs_fltr_list; unsigned int i; - if (!vsi || vsi->type != ICE_VSI_PF) + if (!vsi || vsi->type != ICE_VSI_PF || ice_is_arfs_active(vsi)) return; arfs_fltr_list = kzalloc(sizeof(*arfs_fltr_list) * ICE_MAX_ARFS_LIST, -- 2.22.0

2 1

[PATCH OLK-6.6] vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
by Yin Tirui 07 May '25

07 May '25

From: Mike Christie <michael.christie(a)oracle.com> stable inclusion from stable-v6.6.87 commit 2b34bdc42df047794542f3e220fe989124e4499a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP35K CVE: CVE-2025-22083 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6 ] If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first. Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session") Fixes: 4f7f46d32c98 ("tcm_vhost: Use vq->private_data to indicate if the endpoint is setup") Reported-by: Haoran Zhang <wh1sper(a)zju.edu.cn> Closes: https://lore.kernel.org/virtualization/e418a5ee-45ca-4d18-9b5d-6f8b6b1add8e… Signed-off-by: Mike Christie <michael.christie(a)oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com> Message-Id: <20250129210922.121533-1-michael.christie(a)oracle.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Acked-by: Stefano Garzarella <sgarzare(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yin Tirui <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/vhost/scsi.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 99813232c25e..8d8a22504d71 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -1688,14 +1688,19 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, } } + if (vs->vs_tpg) { + pr_err("vhost-scsi endpoint already set for %s.\n", + vs->vs_vhost_wwpn); + ret = -EEXIST; + goto out; + } + len = sizeof(vs_tpg[0]) * VHOST_SCSI_MAX_TARGET; vs_tpg = kzalloc(len, GFP_KERNEL); if (!vs_tpg) { ret = -ENOMEM; goto out; } - if (vs->vs_tpg) - memcpy(vs_tpg, vs->vs_tpg, len); mutex_lock(&vhost_scsi_mutex); list_for_each_entry(tpg, &vhost_scsi_list, tv_tpg_list) { @@ -1711,12 +1716,6 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, tv_tport = tpg->tport; if (!strcmp(tv_tport->tport_name, t->vhost_wwpn)) { - if (vs->vs_tpg && vs->vs_tpg[tpg->tport_tpgt]) { - mutex_unlock(&tpg->tv_tpg_mutex); - mutex_unlock(&vhost_scsi_mutex); - ret = -EEXIST; - goto undepend; - } /* * In order to ensure individual vhost-scsi configfs * groups cannot be removed while in use by vhost ioctl, @@ -1763,15 +1762,15 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, } ret = 0; } else { - ret = -EEXIST; + ret = -ENODEV; + goto free_tpg; } /* - * Act as synchronize_rcu to make sure access to - * old vs->vs_tpg is finished. + * Act as synchronize_rcu to make sure requests after this point + * see a fully setup device. */ vhost_scsi_flush(vs); - kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; goto out; @@ -1791,6 +1790,7 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs, target_undepend_item(&tpg->se_tpg.tpg_group.cg_item); } } +free_tpg: kfree(vs_tpg); out: mutex_unlock(&vs->dev.mutex); @@ -1893,6 +1893,7 @@ vhost_scsi_clear_endpoint(struct vhost_scsi *vs, vhost_scsi_flush(vs); kfree(vs->vs_tpg); vs->vs_tpg = NULL; + memset(vs->vs_vhost_wwpn, 0, sizeof(vs->vs_vhost_wwpn)); WARN_ON(vs->vs_events_nr); mutex_unlock(&vs->dev.mutex); return 0; -- 2.22.0

2 1

[PATCH OLK-6.6] ice: fix memory leak in aRFS after reset
by Yin Tirui 07 May '25

07 May '25

From: Grzegorz Nitka <grzegorz.nitka(a)intel.com> stable inclusion from stable-v6.6.84 commit 5d30d256661fc11b6e73fac6c3783a702e1006a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBY42R CVE: CVE-2025-21981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 23d97f18901ef5e4e264e3b1777fe65c760186b5 ] Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... Fixes: 28bf26724fdb ("ice: Implement aRFS") Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka(a)intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yin Tirui <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c index cca0e753f38f..d7e0116f6773 100644 --- a/drivers/net/ethernet/intel/ice/ice_arfs.c +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c @@ -510,7 +510,7 @@ void ice_init_arfs(struct ice_vsi *vsi) struct hlist_head *arfs_fltr_list; unsigned int i; - if (!vsi || vsi->type != ICE_VSI_PF) + if (!vsi || vsi->type != ICE_VSI_PF || ice_is_arfs_active(vsi)) return; arfs_fltr_list = kcalloc(ICE_MAX_ARFS_LIST, sizeof(*arfs_fltr_list), -- 2.22.0

2 1