- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-40968
by Liao Chen 17 Jul '24

17 Jul '24

MIPS: Octeon: Add PCIe link status check Songyang Li (1): MIPS: Octeon: Add PCIe link status check arch/mips/pci/pcie-octeon.c | 6 ++++++ 1 file changed, 6 insertions(+) mode change 100644 => 100755 arch/mips/pci/pcie-octeon.c -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
by Zhengchao Shao 17 Jul '24

17 Jul '24

From: David Ruth <druth(a)chromium.org> mainline inclusion from mainline-v6.10-rc5 commit d864319871b05fadd153e0aede4811ca7008f5d6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2K CVE: CVE-2024-40995 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481 Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action") Reported-by: syzbot+b87c222546179f4513a7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b87c222546179f4513a7 Signed-off-by: David Ruth <druth(a)chromium.org> Reviewed-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Link: https://lore.kernel.org/r/20240614190326.1349786-1-druth@chromium.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/sched/act_api.c [The conflict occurs because the commit 4b55e86736d5("net/sched: act_api: rely on rcu in tcf_idr_check_alloc") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/sched/act_api.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/sched/act_api.c b/net/sched/act_api.c index 26851ca5566a..3249b8f407e1 100644 --- a/net/sched/act_api.c +++ b/net/sched/act_api.c @@ -440,7 +440,6 @@ int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index, struct tc_action *p; int ret; -again: spin_lock(&idrinfo->lock); if (*index) { p = idr_find(&idrinfo->action_idr, *index); @@ -449,7 +448,7 @@ int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index, * index but did not assign the pointer yet. */ spin_unlock(&idrinfo->lock); - goto again; + return -EAGAIN; } if (p) { -- 2.34.1

2 1

[PATCH OLK-6.6] drm/arm/malidp: fix a possible null pointer dereference
by Chen Zhongjin 17 Jul '24

17 Jul '24

From: Huai-Yuan Liu <qq810974084(a)gmail.com> stable inclusion from stable-v6.6.33 commit 335cc45ef2b81b68be63c698b4f867a530bdf7a5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9T5PA CVE: CVE-2024-36014 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a1f95aede6285dba6dd036d907196f35ae3a11ea ] In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector") Signed-off-by: Huai-Yuan Liu <qq810974084(a)gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau(a)arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq81097… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/gpu/drm/arm/malidp_mw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c index 626709bec6f5..2577f0cef8fc 100644 --- a/drivers/gpu/drm/arm/malidp_mw.c +++ b/drivers/gpu/drm/arm/malidp_mw.c @@ -72,7 +72,10 @@ static void malidp_mw_connector_reset(struct drm_connector *connector) __drm_atomic_helper_connector_destroy_state(connector->state); kfree(connector->state); - __drm_atomic_helper_connector_reset(connector, &mw_state->base); + connector->state = NULL; + + if (mw_state) + __drm_atomic_helper_connector_reset(connector, &mw_state->base); } static enum drm_connector_status -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] usb: host: ohci-tmio: check return value after calling platform_get_resource()
by Zheng Zucheng 17 Jul '24

17 Jul '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion from stable-v5.10.82 commit 2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEW CVE: CVE-2021-47206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Conflicts: drivers/usb/host/ohci-tmio.c [Some contexts different. No functional impact.] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index a631dbb369d7..06ee17dddc0e 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -196,7 +196,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev) if (usb_disabled()) return -ENODEV; - if (!cell) + if (!cell || !regs || !config || !sram) return -EINVAL; hcd = usb_create_hcd(&ohci_tmio_hc_driver, &dev->dev, dev_name(&dev->dev)); -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 17 Jul '24

17 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6] fpga: region: add owner module and take its refcount
by Wang Hai 17 Jul '24

17 Jul '24

From: Marco Pagani <marpagan(a)redhat.com> stable inclusion from stable-v6.6.33 commit 4d7d12b643c00e7eea51b49a60a2ead182633ec8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YMT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b7c0e1ecee403a43abc89eb3e75672b01ff2ece9 ] The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region. Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA") Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Suggested-by: Xu Yilun <yilun.xu(a)intel.com> Reviewed-by: Russ Weight <russ.weight(a)linux.dev> Signed-off-by: Marco Pagani <marpagan(a)redhat.com> Acked-by: Xu Yilun <yilun.xu(a)intel.com> Link: https://lore.kernel.org/r/20240419083601.77403-1-marpagan@redhat.com Signed-off-by: Xu Yilun <yilun.xu(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- Documentation/driver-api/fpga/fpga-region.rst | 13 ++++++---- drivers/fpga/fpga-region.c | 24 +++++++++++-------- include/linux/fpga/fpga-region.h | 13 +++++++--- 3 files changed, 32 insertions(+), 18 deletions(-) diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index dc55d60a0b4a..2d03b5fb7657 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -46,13 +46,16 @@ API to add a new FPGA region ---------------------------- * struct fpga_region - The FPGA region struct -* struct fpga_region_info - Parameter structure for fpga_region_register_full() -* fpga_region_register_full() - Create and register an FPGA region using the +* struct fpga_region_info - Parameter structure for __fpga_region_register_full() +* __fpga_region_register_full() - Create and register an FPGA region using the fpga_region_info structure to provide the full flexibility of options -* fpga_region_register() - Create and register an FPGA region using standard +* __fpga_region_register() - Create and register an FPGA region using standard arguments * fpga_region_unregister() - Unregister an FPGA region +Helper macros ``fpga_region_register()`` and ``fpga_region_register_full()`` +automatically set the module that registers the FPGA region as the owner. + The FPGA region's probe function will need to get a reference to the FPGA Manager it will be using to do the programming. This usually would happen during the region's probe function. @@ -82,10 +85,10 @@ following APIs to handle building or tearing down that list. :functions: fpga_region_info .. kernel-doc:: drivers/fpga/fpga-region.c - :functions: fpga_region_register_full + :functions: __fpga_region_register_full .. kernel-doc:: drivers/fpga/fpga-region.c - :functions: fpga_region_register + :functions: __fpga_region_register .. kernel-doc:: drivers/fpga/fpga-region.c :functions: fpga_region_unregister diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c index b364a929425c..753cd142503e 100644 --- a/drivers/fpga/fpga-region.c +++ b/drivers/fpga/fpga-region.c @@ -53,7 +53,7 @@ static struct fpga_region *fpga_region_get(struct fpga_region *region) } get_device(dev); - if (!try_module_get(dev->parent->driver->owner)) { + if (!try_module_get(region->ops_owner)) { put_device(dev); mutex_unlock(&region->mutex); return ERR_PTR(-ENODEV); @@ -75,7 +75,7 @@ static void fpga_region_put(struct fpga_region *region) dev_dbg(dev, "put\n"); - module_put(dev->parent->driver->owner); + module_put(region->ops_owner); put_device(dev); mutex_unlock(&region->mutex); } @@ -181,14 +181,16 @@ static struct attribute *fpga_region_attrs[] = { ATTRIBUTE_GROUPS(fpga_region); /** - * fpga_region_register_full - create and register an FPGA Region device + * __fpga_region_register_full - create and register an FPGA Region device * @parent: device parent * @info: parameters for FPGA Region + * @owner: module containing the get_bridges function * * Return: struct fpga_region or ERR_PTR() */ struct fpga_region * -fpga_region_register_full(struct device *parent, const struct fpga_region_info *info) +__fpga_region_register_full(struct device *parent, const struct fpga_region_info *info, + struct module *owner) { struct fpga_region *region; int id, ret = 0; @@ -213,6 +215,7 @@ fpga_region_register_full(struct device *parent, const struct fpga_region_info * region->compat_id = info->compat_id; region->priv = info->priv; region->get_bridges = info->get_bridges; + region->ops_owner = owner; mutex_init(&region->mutex); INIT_LIST_HEAD(&region->bridge_list); @@ -241,13 +244,14 @@ fpga_region_register_full(struct device *parent, const struct fpga_region_info * return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(fpga_region_register_full); +EXPORT_SYMBOL_GPL(__fpga_region_register_full); /** - * fpga_region_register - create and register an FPGA Region device + * __fpga_region_register - create and register an FPGA Region device * @parent: device parent * @mgr: manager that programs this region * @get_bridges: optional function to get bridges to a list + * @owner: module containing the get_bridges function * * This simple version of the register function should be sufficient for most users. * The fpga_region_register_full() function is available for users that need to @@ -256,17 +260,17 @@ EXPORT_SYMBOL_GPL(fpga_region_register_full); * Return: struct fpga_region or ERR_PTR() */ struct fpga_region * -fpga_region_register(struct device *parent, struct fpga_manager *mgr, - int (*get_bridges)(struct fpga_region *)) +__fpga_region_register(struct device *parent, struct fpga_manager *mgr, + int (*get_bridges)(struct fpga_region *), struct module *owner) { struct fpga_region_info info = { 0 }; info.mgr = mgr; info.get_bridges = get_bridges; - return fpga_region_register_full(parent, &info); + return __fpga_region_register_full(parent, &info, owner); } -EXPORT_SYMBOL_GPL(fpga_region_register); +EXPORT_SYMBOL_GPL(__fpga_region_register); /** * fpga_region_unregister - unregister an FPGA region diff --git a/include/linux/fpga/fpga-region.h b/include/linux/fpga/fpga-region.h index 9d4d32909340..5fbc05fe70a6 100644 --- a/include/linux/fpga/fpga-region.h +++ b/include/linux/fpga/fpga-region.h @@ -36,6 +36,7 @@ struct fpga_region_info { * @mgr: FPGA manager * @info: FPGA image info * @compat_id: FPGA region id for compatibility check. + * @ops_owner: module containing the get_bridges function * @priv: private data * @get_bridges: optional function to get bridges to a list */ @@ -46,6 +47,7 @@ struct fpga_region { struct fpga_manager *mgr; struct fpga_image_info *info; struct fpga_compat_id *compat_id; + struct module *ops_owner; void *priv; int (*get_bridges)(struct fpga_region *region); }; @@ -58,12 +60,17 @@ fpga_region_class_find(struct device *start, const void *data, int fpga_region_program_fpga(struct fpga_region *region); +#define fpga_region_register_full(parent, info) \ + __fpga_region_register_full(parent, info, THIS_MODULE) struct fpga_region * -fpga_region_register_full(struct device *parent, const struct fpga_region_info *info); +__fpga_region_register_full(struct device *parent, const struct fpga_region_info *info, + struct module *owner); +#define fpga_region_register(parent, mgr, get_bridges) \ + __fpga_region_register(parent, mgr, get_bridges, THIS_MODULE) struct fpga_region * -fpga_region_register(struct device *parent, struct fpga_manager *mgr, - int (*get_bridges)(struct fpga_region *)); +__fpga_region_register(struct device *parent, struct fpga_manager *mgr, + int (*get_bridges)(struct fpga_region *), struct module *owner); void fpga_region_unregister(struct fpga_region *region); #endif /* _FPGA_REGION_H */ -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-40995
by Zhengchao Shao 17 Jul '24

17 Jul '24

Fix CVE-2024-40995. David Ruth (1): net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() Pedro Tammela (1): net/sched: act_api: rely on rcu in tcf_idr_check_alloc net/sched/act_api.c | 66 +++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 23 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] fix CVE-2024-40995
by Zhengchao Shao 17 Jul '24

17 Jul '24

Fix CVE-2024-40995. David Ruth (1): net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() Pedro Tammela (1): net/sched: act_api: rely on rcu in tcf_idr_check_alloc net/sched/act_api.c | 66 +++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 23 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] fix CVE-2024-40995
by Zhengchao Shao 17 Jul '24

17 Jul '24

Fix CVE-2024-40995. David Ruth (1): net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() Pedro Tammela (1): net/sched: act_api: rely on rcu in tcf_idr_check_alloc net/sched/act_api.c | 66 +++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 23 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 17 Jul '24

17 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/5] nfs: Ensure that the NFS client returns a correct writeback error code
by Wang Zhaolong 17 Jul '24

17 Jul '24

Backport community mainline patch to make close and writeback return correct return values: Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes: Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-6.6] KVM: arm64: Disassociate vcpus from redistributor region on teardown
by Li Huafei 17 Jul '24

17 Jul '24

From: Marc Zyngier <maz(a)kernel.org> stable inclusion from stable-v6.6.36 commit 48bb62859d47c5c4197a8c01128d0fa4f46ee58c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZC CVE: CVE-2024-40989 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0d92e4a7ffd5c42b9fa864692f82476c0bf8bcc8 upstream. When tearing down a redistributor region, make sure we don't have any dangling pointer to that region stored in a vcpu. Fixes: e5a35635464b ("kvm: arm64: vgic-v3: Introduce vgic_v3_free_redist_region()") Reported-by: Alexander Potapenko <glider(a)google.com> Reviewed-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20240605175637.1635653-1-maz@kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- arch/arm64/kvm/vgic/vgic-init.c | 2 +- arch/arm64/kvm/vgic/vgic-mmio-v3.c | 15 +++++++++++++-- arch/arm64/kvm/vgic/vgic.h | 2 +- 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c index a8590ca54ad2..b9816bca4a2a 100644 --- a/arch/arm64/kvm/vgic/vgic-init.c +++ b/arch/arm64/kvm/vgic/vgic-init.c @@ -384,7 +384,7 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm) if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { list_for_each_entry_safe(rdreg, next, &dist->rd_regions, list) - vgic_v3_free_redist_region(rdreg); + vgic_v3_free_redist_region(kvm, rdreg); INIT_LIST_HEAD(&dist->rd_regions); } else { dist->vgic_cpu_base = VGIC_ADDR_UNDEF; diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c index 09db8c8f8d44..c29c0b5669a6 100644 --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c @@ -1022,8 +1022,19 @@ static int vgic_v3_alloc_redist_region(struct kvm *kvm, uint32_t index, return ret; } -void vgic_v3_free_redist_region(struct vgic_redist_region *rdreg) +void vgic_v3_free_redist_region(struct kvm *kvm, struct vgic_redist_region *rdreg) { + struct kvm_vcpu *vcpu; + unsigned long c; + + lockdep_assert_held(&kvm->arch.config_lock); + + /* Garbage collect the region */ + kvm_for_each_vcpu(c, vcpu, kvm) { + if (vcpu->arch.vgic_cpu.rdreg == rdreg) + vcpu->arch.vgic_cpu.rdreg = NULL; + } + list_del(&rdreg->list); kfree(rdreg); } @@ -1048,7 +1059,7 @@ int vgic_v3_set_redist_base(struct kvm *kvm, u32 index, u64 addr, u32 count) mutex_lock(&kvm->arch.config_lock); rdreg = vgic_v3_rdist_region_from_index(kvm, index); - vgic_v3_free_redist_region(rdreg); + vgic_v3_free_redist_region(kvm, rdreg); mutex_unlock(&kvm->arch.config_lock); return ret; } diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h index e38bf7d94d3b..5135c690839e 100644 --- a/arch/arm64/kvm/vgic/vgic.h +++ b/arch/arm64/kvm/vgic/vgic.h @@ -322,7 +322,7 @@ vgic_v3_rd_region_size(struct kvm *kvm, struct vgic_redist_region *rdreg) struct vgic_redist_region *vgic_v3_rdist_region_from_index(struct kvm *kvm, u32 index); -void vgic_v3_free_redist_region(struct vgic_redist_region *rdreg); +void vgic_v3_free_redist_region(struct kvm *kvm, struct vgic_redist_region *rdreg); bool vgic_v3_rdist_overlap(struct kvm *kvm, gpa_t base, size_t size); -- 2.25.1

2 1

[PATCH OLK-6.6 0/9] CVE-2024-40955
by Yifan Qiao 17 Jul '24

17 Jul '24

Baokun Li (9): ext4: avoid overflow when setting values via sysfs ext4: refactor out ext4_generic_attr_store() ext4: refactor out ext4_generic_attr_show() ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() ext4: add new attr pointer attr_mb_order ext4: add positive int attr pointer to avoid sysfs variables overflow ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow ext4: set the type of max_zeroout to unsigned int to avoid overflow ext4: clean up s_mb_rb_lock to fix build warnings with C=1 fs/ext4/mballoc.h | 2 +- fs/ext4/extents.c | 3 +- fs/ext4/mballoc.c | 5 +- fs/ext4/sysfs.c | 174 ++++++++++++++++++++++++++++------------------ 4 files changed, 112 insertions(+), 72 deletions(-) -- 2.39.2

2 10

[PATCH openEuler-1.0-LTS] usb: host: ohci-tmio: check return value after calling platform_get_resource()
by Zheng Zucheng 17 Jul '24

17 Jul '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion form stable-v5.10.82 commit 2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEW CVE: CVE-2021-47206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Conflicts: drivers/usb/host/ohci-tmio.c [Some contexts different. No functional impact.] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index a631dbb369d7..06ee17dddc0e 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -196,7 +196,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev) if (usb_disabled()) return -ENODEV; - if (!cell) + if (!cell || !regs || !config || !sram) return -EINVAL; hcd = usb_create_hcd(&ohci_tmio_hc_driver, &dev->dev, dev_name(&dev->dev)); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 17 Jul '24

17 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/amdgpu/kv_dpm.c drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c [yyl: The directory is renamed from amdgpu to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c index f046348362e3..e74e53bdec49 100644 --- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c +++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c @@ -164,6 +164,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 17 Jul '24

17 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c [yyl: The directory is renamed from powerplay to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c index 6eb6f05c1136..56e15f5bc822 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c +++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c @@ -163,6 +163,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-5.10] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 17 Jul '24

17 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c [yyl: The directory is renamed from powerplay to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c index 6eb6f05c1136..56e15f5bc822 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c +++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c @@ -163,6 +163,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-6.6] bpf: Set run context for rawtp test_run callback
by Liu Jian 17 Jul '24

17 Jul '24

From: Jiri Olsa <jolsa(a)kernel.org> stable inclusion from stable-v6.6.35 commit d387805d4b4a46ee01e3dae133c81b6d80195e5b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS7Y CVE: CVE-2024-40908 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit d0d1df8ba18abc57f28fb3bc053b2bf319367f2c ] syzbot reported crash when rawtp program executed through the test_run interface calls bpf_get_attach_cookie helper or any other helper that touches task->bpf_ctx pointer. Setting the run context (task->bpf_ctx pointer) for test_run callback. Fixes: 7adfc6c9b315 ("bpf: Add bpf_get_attach_cookie() BPF helper to access bpf_cookie value") Reported-by: syzbot+3ab78ff125b7979e45f9(a)syzkaller.appspotmail.com Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Closes: https://syzkaller.appspot.com/bug?extid=3ab78ff125b7979e45f9 Link: https://lore.kernel.org/bpf/20240604150024.359247-1-jolsa@kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/bpf/test_run.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index 478ee7aba85f..12a2934b28ff 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -707,10 +707,16 @@ static void __bpf_prog_test_run_raw_tp(void *data) { struct bpf_raw_tp_test_run_info *info = data; + struct bpf_trace_run_ctx run_ctx = {}; + struct bpf_run_ctx *old_run_ctx; + + old_run_ctx = bpf_set_run_ctx(&run_ctx.run_ctx); rcu_read_lock(); info->retval = bpf_prog_run(info->prog, info->ctx); rcu_read_unlock(); + + bpf_reset_run_ctx(old_run_ctx); } int bpf_prog_test_run_raw_tp(struct bpf_prog *prog, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] serial: imx: Introduce timeout when waiting on transmitter empty
by felix 17 Jul '24

17 Jul '24

From: Esben Haabendal <esben(a)geanix.com> mainline inclusion from mainline-v6.10-rc1 commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0R6 CVE: CVE-2024-40967 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. Signed-off-by: Esben Haabendal <esben(a)geanix.com> Acked-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.17128376… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/imx.c [Fix context conflicts] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/tty/serial/imx.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 989ca7d662f3..51b8624a11e5 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -29,6 +29,7 @@ #include <linux/of.h> #include <linux/of_device.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/dma-mapping.h> #include <asm/irq.h> @@ -1912,7 +1913,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) { struct imx_port *sport = imx_uart_ports[co->index]; struct imx_port_ucrs old_ucr; - unsigned int ucr1; + unsigned int ucr1, usr2; unsigned long flags = 0; int locked = 1; int retval; @@ -1954,8 +1955,8 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) * Finally, wait for transmitter to become empty * and restore UCR1/2/3 */ - while (!(imx_uart_readl(sport, USR2) & USR2_TXDC)); - + read_poll_timeout_atomic(imx_uart_readl, usr2, usr2 & USR2_TXDC, + 0, USEC_PER_SEC, false, sport, USR2); imx_uart_ucrs_restore(sport, &old_ucr); if (locked) -- 2.34.1

2 1

[PATCH OLK-5.10] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
by felix 17 Jul '24

17 Jul '24

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.10-rc5 commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT6J CVE: CVE-2024-40953 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240510092353.2261824-1-leitao@debian.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Conflicts: virt/kvm/kvm_main.c [Fix context because of 46808a4cb89708c2e5b264eb9d1035762581921b not merged] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 53c83483653f..2b28fcb35641 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2503,12 +2503,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; int yielded = 0; int try = 3; int pass; int i; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -2538,7 +2539,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.34.1

2 3

[PATCH OLK-6.6] PCI: of_property: Return error for int_map allocation failure
by heyujie 17 Jul '24

17 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit e6f7d27df5d208b50cae817a91d128fb434bb12c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YNF CVE: CVE-2024-34030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/20240303105729.78624-1-duoming@zju.edu.cn Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/pci/of_property.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c index c2c7334152bc..03539e505372 100644 --- a/drivers/pci/of_property.c +++ b/drivers/pci/of_property.c @@ -238,6 +238,8 @@ static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs, return 0; int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL); + if (!int_map) + return -ENOMEM; mapp = int_map; list_for_each_entry(child, &pdev->subordinate->devices, bus_list) { -- 2.34.1

2 1

[PATCH OLK-5.10] serial: imx: Introduce timeout when waiting on transmitter empty
by felix 17 Jul '24

17 Jul '24

From: Esben Haabendal <esben(a)geanix.com> mainline inclusion from mainline-v6.10-rc1 commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0R6 CVE: CVE-2024-40967 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. Signed-off-by: Esben Haabendal <esben(a)geanix.com> Acked-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.17128376… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/imx.c [Fix context conflicts] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/tty/serial/imx.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 2eca7b065c0a..863dab7e3cf2 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -27,6 +27,7 @@ #include <linux/of.h> #include <linux/of_device.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/dma-mapping.h> #include <asm/irq.h> @@ -2006,7 +2007,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) { struct imx_port *sport = imx_uart_ports[co->index]; struct imx_port_ucrs old_ucr; - unsigned int ucr1; + unsigned int ucr1, usr2; unsigned long flags = 0; int locked = 1; @@ -2038,8 +2039,8 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) * Finally, wait for transmitter to become empty * and restore UCR1/2/3 */ - while (!(imx_uart_readl(sport, USR2) & USR2_TXDC)); - + read_poll_timeout_atomic(imx_uart_readl, usr2, usr2 & USR2_TXDC, + 0, USEC_PER_SEC, false, sport, USR2); imx_uart_ucrs_restore(sport, &old_ucr); if (locked) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] serial: imx: Introduce timeout when waiting on transmitter empty
by felix 17 Jul '24

17 Jul '24

From: Esben Haabendal <esben(a)geanix.com> mainline inclusion from mainline-v6.10-rc1 commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0R6 CVE: CVE-2024-40967 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. Signed-off-by: Esben Haabendal <esben(a)geanix.com> Acked-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.17128376… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/imx.c [Fix context conflicts] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/tty/serial/imx.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 2eca7b065c0a..863dab7e3cf2 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -27,6 +27,7 @@ #include <linux/of.h> #include <linux/of_device.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/dma-mapping.h> #include <asm/irq.h> @@ -2006,7 +2007,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) { struct imx_port *sport = imx_uart_ports[co->index]; struct imx_port_ucrs old_ucr; - unsigned int ucr1; + unsigned int ucr1, usr2; unsigned long flags = 0; int locked = 1; @@ -2038,8 +2039,8 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) * Finally, wait for transmitter to become empty * and restore UCR1/2/3 */ - while (!(imx_uart_readl(sport, USR2) & USR2_TXDC)); - + read_poll_timeout_atomic(imx_uart_readl, usr2, usr2 & USR2_TXDC, + 0, USEC_PER_SEC, false, sport, USR2); imx_uart_ucrs_restore(sport, &old_ucr); if (locked) -- 2.34.1

2 1

[OLK-6.6] PCI: of_property: Return error for int_map allocation failure
by heyujie 17 Jul '24

17 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit e6f7d27df5d208b50cae817a91d128fb434bb12c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YNF CVE: CVE-2024-34030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/20240303105729.78624-1-duoming@zju.edu.cn Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/pci/of_property.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c index c2c7334152bc..03539e505372 100644 --- a/drivers/pci/of_property.c +++ b/drivers/pci/of_property.c @@ -238,6 +238,8 @@ static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs, return 0; int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL); + if (!int_map) + return -ENOMEM; mapp = int_map; list_for_each_entry(child, &pdev->subordinate->devices, bus_list) { -- 2.34.1

1 0

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 17 Jul '24

17 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[OLK-6.6] PCI: of_property: Return error for int_map allocation failure
by heyujie 17 Jul '24

17 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit e6f7d27df5d208b50cae817a91d128fb434bb12c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YNF CVE: CVE-2024-34030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/20240303105729.78624-1-duoming@zju.edu.cn Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/pci/of_property.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c index c2c7334152bc..03539e505372 100644 --- a/drivers/pci/of_property.c +++ b/drivers/pci/of_property.c @@ -238,6 +238,8 @@ static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs, return 0; int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL); + if (!int_map) + return -ENOMEM; mapp = int_map; list_for_each_entry(child, &pdev->subordinate->devices, bus_list) { -- 2.34.1

1 0

[PATCH OLK-6.6 V1] iommu: Return right value in iommu_sva_bind_device()
by Cheng Yu 17 Jul '24

17 Jul '24

From: Lu Baolu <baolu.lu(a)linux.intel.com> mainline inclusion from mainline-v6.10-rc3 commit 89e8a2366e3bce584b6c01549d5019c5cda1205e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSKO CVE: CVE-2024-40945 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all. Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices") Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Reviewed-by: Vasant Hegde <vasant.hegde(a)amd.com> Link: https://lore.kernel.org/r/20240528042528.71396-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- include/linux/iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0c8c..293219ee6fb9 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1674,7 +1674,7 @@ struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, static inline struct iommu_sva * iommu_sva_bind_device(struct device *dev, struct mm_struct *mm) { - return NULL; + return ERR_PTR(-ENODEV); } static inline void iommu_sva_unbind_device(struct iommu_sva *handle) -- 2.25.1

2 1

[PATCH OLK-6.6] ALSA: Fix deadlocks with kctl removals at disconnection
by heyujie 17 Jul '24

17 Jul '24

From: Takashi Iwai <tiwai(a)suse.de> mainline inclusion from mainline-v6.10-rc1 commit 87988a534d8e12f2e6fc01fe63e6c1925dc5307c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHB CVE: CVE-2024-38600 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816 Cc: <stable(a)vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20240510101424.6279-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- sound/core/init.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sound/core/init.c b/sound/core/init.c index f8dfc8d7010e..d97b8af897ee 100644 --- a/sound/core/init.c +++ b/sound/core/init.c @@ -523,6 +523,14 @@ void snd_card_disconnect(struct snd_card *card) } spin_unlock(&card->files_lock); +#ifdef CONFIG_PM + /* wake up sleepers here before other callbacks for avoiding potential + * deadlocks with other locks (e.g. in kctls); + * then this notifies the shutdown and sleepers would abort immediately + */ + wake_up_all(&card->power_sleep); +#endif + /* notify all connected devices about disconnection */ /* at this point, they cannot respond to any calls except release() */ @@ -550,7 +558,6 @@ void snd_card_disconnect(struct snd_card *card) mutex_unlock(&snd_card_mutex); #ifdef CONFIG_PM - wake_up(&card->power_sleep); snd_power_sync_ref(card); #endif } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] iommu: Return right value in iommu_sva_bind_device()
by Cheng Yu 17 Jul '24

17 Jul '24

From: Lu Baolu <baolu.lu(a)linux.intel.com> mainline inclusion from mainline-v6.10-rc3 commit 89e8a2366e3bce584b6c01549d5019c5cda1205e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSKO CVE: CVE-2024-40945 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all. Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices") Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Reviewed-by: Vasant Hegde <vasant.hegde(a)amd.com> Link: https://lore.kernel.org/r/20240528042528.71396-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- include/linux/iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 47294a3a398e..0e7eb6ee9780 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1146,7 +1146,7 @@ iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev) static inline struct iommu_sva * iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata) { - return NULL; + return ERR_PTR(-ENODEV); } static inline void iommu_sva_unbind_device(struct iommu_sva *handle) -- 2.25.1

2 1

[PATCH OLK-6.6] serial: imx: Introduce timeout when waiting on transmitter empty
by felix 17 Jul '24

17 Jul '24

From: Esben Haabendal <esben(a)geanix.com> stable inclusion from stable-v6.6.36 commit 982ae3376c4c91590d38dc8a676c10f7df048a44 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0R6 CVE: CVE-2024-40967 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 ] By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. Signed-off-by: Esben Haabendal <esben(a)geanix.com> Acked-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.17128376… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/tty/serial/imx.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index c77831e91ec2..a1476e47c6aa 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -26,6 +26,7 @@ #include <linux/slab.h> #include <linux/of.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/dma-mapping.h> #include <asm/irq.h> @@ -2009,7 +2010,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) struct imx_port *sport = imx_uart_ports[co->index]; struct imx_port_ucrs old_ucr; unsigned long flags; - unsigned int ucr1; + unsigned int ucr1, usr2; int locked = 1; if (sport->port.sysrq) @@ -2040,8 +2041,8 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count) * Finally, wait for transmitter to become empty * and restore UCR1/2/3 */ - while (!(imx_uart_readl(sport, USR2) & USR2_TXDC)); - + read_poll_timeout_atomic(imx_uart_readl, usr2, usr2 & USR2_TXDC, + 0, USEC_PER_SEC, false, sport, USR2); imx_uart_ucrs_restore(sport, &old_ucr); if (locked) -- 2.34.1

2 1

[PATCH OLK-5.10 V1] iommu: Return right value in iommu_sva_bind_device()
by Cheng Yu 17 Jul '24

17 Jul '24

From: Lu Baolu <baolu.lu(a)linux.intel.com> mainline inclusion from mainline-v6.10-rc3 commit 89e8a2366e3bce584b6c01549d5019c5cda1205e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSKO CVE: CVE-2024-40945 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all. Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices") Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Reviewed-by: Vasant Hegde <vasant.hegde(a)amd.com> Link: https://lore.kernel.org/r/20240528042528.71396-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- include/linux/iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index b0218b1f5ef0..355f4e437d67 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1153,7 +1153,7 @@ iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev) static inline struct iommu_sva * iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata) { - return NULL; + return ERR_PTR(-ENODEV); } static inline void iommu_sva_unbind_device(struct iommu_sva *handle) -- 2.25.1

2 1

[PATCH OLK-6.6] net/mlx5: Always stop health timer during driver removal
by Zhengchao Shao 17 Jul '24

17 Jul '24

From: Shay Drory <shayd(a)nvidia.com> stable inclusion from stable-v6.6.35 commit 6ccada6ffb42e0ac75e3db06d41baf5a7f483f8a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW9 CVE: CVE-2024-40906 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c8b3f38d2dae0397944814d691a419c451f9906f ] Currently, if teardown_hca fails to execute during driver removal, mlx5 does not stop the health timer. Afterwards, mlx5 continue with driver teardown. This may lead to a UAF bug, which results in page fault Oops[1], since the health timer invokes after resources were freed. Hence, stop the health monitor even if teardown_hca fails. [1] mlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: cleanup mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup BUG: unable to handle page fault for address: ffffa26487064230 PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 RIP: 0010:ioread32be+0x34/0x60 RSP: 0018:ffffa26480003e58 EFLAGS: 00010292 RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0 RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230 RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8 R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0 R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0 FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x175/0x180 ? asm_exc_page_fault+0x26/0x30 ? __pfx_poll_health+0x10/0x10 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] ? ioread32be+0x34/0x60 mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] poll_health+0x42/0x230 [mlx5_core] ? __next_timer_interrupt+0xbc/0x110 ? __pfx_poll_health+0x10/0x10 [mlx5_core] call_timer_fn+0x21/0x130 ? __pfx_poll_health+0x10/0x10 [mlx5_core] __run_timers+0x222/0x2c0 run_timer_softirq+0x1d/0x40 __do_softirq+0xc9/0x2c8 __irq_exit_rcu+0xa6/0xc0 sysvec_apic_timer_interrupt+0x72/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:cpuidle_enter_state+0xcc/0x440 ? cpuidle_enter_state+0xbd/0x440 cpuidle_enter+0x2d/0x40 do_idle+0x20d/0x270 cpu_startup_entry+0x2a/0x30 rest_init+0xd0/0xd0 arch_call_rest_init+0xe/0x30 start_kernel+0x709/0xa90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x96/0xa0 secondary_startup_64_no_verify+0x18f/0x19b ---[ end trace 0000000000000000 ]--- Fixes: 9b98d395b85d ("net/mlx5: Start health poll at earlier stage of driver load") Signed-off-by: Shay Drory <shayd(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 9710ddac1f1a..2237b3d01e0e 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1287,6 +1287,9 @@ static int mlx5_function_teardown(struct mlx5_core_dev *dev, bool boot) if (!err) mlx5_function_disable(dev, boot); + else + mlx5_stop_health_poll(dev, boot); + return err; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
by Dong Chenchen 17 Jul '24

17 Jul '24

From: Yue Haibing <yuehaibing(a)huawei.com> mainline inclusion from mainline-v6.10-rc2 commit b3dc6e8003b500861fa307e9a3400c52e78e4d3a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6GK7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043) The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20240529095633.613103-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: drivers/net/ipvlan/ipvlan_core.c [commit ff672b9ffeb3 replace dev->stats with DEV_STATS_INC(), which not merged lead to conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/ipvlan/ipvlan_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c index fe9936f42c21..d5ae4fd9f1c0 100644 --- a/drivers/net/ipvlan/ipvlan_core.c +++ b/drivers/net/ipvlan/ipvlan_core.c @@ -440,7 +440,7 @@ static noinline_for_stack int ipvlan_process_v4_outbound(struct sk_buff *skb) memset(IPCB(skb), 0, sizeof(*IPCB(skb))); - err = ip_local_out(net, skb->sk, skb); + err = ip_local_out(net, NULL, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; else @@ -495,7 +495,7 @@ static int ipvlan_process_v6_outbound(struct sk_buff *skb) memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); - err = ip6_local_out(dev_net(dev), skb->sk, skb); + err = ip6_local_out(dev_net(dev), NULL, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; else -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 17 Jul '24

17 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 17 Jul '24

17 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[openeuler:OLK-6.6] BUILD SUCCESS WITH WARNING de51c3bc2687c57e76a35b4b7afdce90367a12b1
by kernel test robot 17 Jul '24

17 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: de51c3bc2687c57e76a35b4b7afdce90367a12b1 !9945 ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Warning reports: https://lore.kernel.org/oe-kbuild-all/202407162323.jh9MzUxd-lkp@intel.com Warning: (recently discovered and may have been fixed) WARNING: modpost: vmlinux: section mismatch in reference: arm_smmu_device_probe+0x174 (section: .text) -> arm_smmu_v3_plat_info (section: .init.data) Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- arm64-randconfig-003-20240716 | `-- WARNING:modpost:vmlinux:section-mismatch-in-reference:arm_smmu_device_probe-(section:.text)-arm_smmu_v3_plat_info-(section:.init.data) |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-002-20240716 | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and `-- x86_64-allyesconfig `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device elapsed time: 725m configs tested: 38 configs skipped: 124 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240716 gcc-14.1.0 arm64 randconfig-002-20240716 clang-19 arm64 randconfig-003-20240716 gcc-14.1.0 arm64 randconfig-004-20240716 gcc-14.1.0 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240716 gcc-14.1.0 loongarch randconfig-002-20240716 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240716 gcc-13 x86_64 buildonly-randconfig-002-20240716 clang-18 x86_64 buildonly-randconfig-003-20240716 clang-18 x86_64 buildonly-randconfig-004-20240716 clang-18 x86_64 buildonly-randconfig-005-20240716 clang-18 x86_64 buildonly-randconfig-006-20240716 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240716 gcc-13 x86_64 randconfig-002-20240716 gcc-8 x86_64 randconfig-003-20240716 gcc-8 x86_64 randconfig-004-20240716 clang-18 x86_64 randconfig-005-20240716 gcc-12 x86_64 randconfig-006-20240716 clang-18 x86_64 randconfig-011-20240716 clang-18 x86_64 randconfig-012-20240716 gcc-9 x86_64 randconfig-013-20240716 gcc-13 x86_64 randconfig-014-20240716 gcc-13 x86_64 randconfig-015-20240716 gcc-7 x86_64 randconfig-016-20240716 clang-18 x86_64 randconfig-071-20240716 clang-18 x86_64 randconfig-072-20240716 clang-18 x86_64 randconfig-073-20240716 clang-18 x86_64 randconfig-074-20240716 clang-18 x86_64 randconfig-075-20240716 clang-18 x86_64 randconfig-076-20240716 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS a96cb8ebc4b83ac6e9e60cef51c5bc823202a47e
by kernel test robot 17 Jul '24

17 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: a96cb8ebc4b83ac6e9e60cef51c5bc823202a47e !9925 ocfs2: fix races between hole punching and AIO+DIO elapsed time: 721m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240716 gcc-14.1.0 arm64 randconfig-002-20240716 gcc-14.1.0 arm64 randconfig-003-20240716 gcc-14.1.0 arm64 randconfig-004-20240716 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240716 gcc-13 x86_64 buildonly-randconfig-002-20240716 clang-18 x86_64 buildonly-randconfig-003-20240716 clang-18 x86_64 buildonly-randconfig-004-20240716 clang-18 x86_64 buildonly-randconfig-005-20240716 clang-18 x86_64 buildonly-randconfig-006-20240716 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240716 gcc-13 x86_64 randconfig-002-20240716 gcc-8 x86_64 randconfig-003-20240716 gcc-8 x86_64 randconfig-004-20240716 clang-18 x86_64 randconfig-005-20240716 gcc-12 x86_64 randconfig-006-20240716 clang-18 x86_64 randconfig-011-20240716 clang-18 x86_64 randconfig-012-20240716 gcc-9 x86_64 randconfig-013-20240716 gcc-13 x86_64 randconfig-014-20240716 gcc-13 x86_64 randconfig-015-20240716 gcc-7 x86_64 randconfig-016-20240716 clang-18 x86_64 randconfig-071-20240716 clang-18 x86_64 randconfig-072-20240716 clang-18 x86_64 randconfig-073-20240716 clang-18 x86_64 randconfig-074-20240716 clang-18 x86_64 randconfig-075-20240716 clang-18 x86_64 randconfig-076-20240716 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 10697/10703] WARNING: modpost: vmlinux: section mismatch in reference: arm_smmu_device_probe+0x174 (section: .text) -> arm_smmu_v3_plat_info (section: .init.data)
by kernel test robot 16 Jul '24

16 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: de51c3bc2687c57e76a35b4b7afdce90367a12b1 commit: 85e566f79665ac8782551afa1134dec7f80f4c97 [10697/10703] iommu/arm-smmu-v3: Change the style to identify the the hisi_platform config: arm64-randconfig-003-20240716 (https://download.01.org/0day-ci/archive/20240716/202407162323.jh9MzUxd-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240716/202407162323.jh9MzUxd-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/202407162323.jh9MzUxd-lkp@intel.com/ All warnings (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: missing MODULE_DESCRIPTION() in vmlinux.o >> WARNING: modpost: vmlinux: section mismatch in reference: arm_smmu_device_probe+0x174 (section: .text) -> arm_smmu_v3_plat_info (section: .init.data) WARNING: modpost: vmlinux: section mismatch in reference: arm_smmu_device_probe+0x178 (section: .text) -> arm_smmu_v3_plat_info (section: .init.data) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
by Dong Chenchen 16 Jul '24

16 Jul '24

From: Yue Haibing <yuehaibing(a)huawei.com> mainline inclusion from mainline-v6.10-rc2 commit b3dc6e8003b500861fa307e9a3400c52e78e4d3a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6GK7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043) The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20240529095633.613103-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: drivers/net/ipvlan/ipvlan_core.c [commit ff672b9ffeb3 replace dev->stats with DEV_STATS_INC(), which not merged lead to conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/ipvlan/ipvlan_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c index fe9936f42c21..d5ae4fd9f1c0 100644 --- a/drivers/net/ipvlan/ipvlan_core.c +++ b/drivers/net/ipvlan/ipvlan_core.c @@ -440,7 +440,7 @@ static noinline_for_stack int ipvlan_process_v4_outbound(struct sk_buff *skb) memset(IPCB(skb), 0, sizeof(*IPCB(skb))); - err = ip_local_out(net, skb->sk, skb); + err = ip_local_out(net, NULL, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; else @@ -495,7 +495,7 @@ static int ipvlan_process_v6_outbound(struct sk_buff *skb) memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); - err = ip6_local_out(dev_net(dev), skb->sk, skb); + err = ip6_local_out(dev_net(dev), NULL, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; else -- 2.25.1

2 1

[PATCH OLK-6.6] nilfs2: fix use-after-free of timer for log writer thread
by Guo Mengqi 16 Jul '24

16 Jul '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v6.6.33 commit f9186bba4ea282b07293c1c892441df3a5441cb0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5D CVE: CVE-2024-38583 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 upstream. Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. Link: https://lkml.kernel.org/r/20240520132621.4054-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20240520132621.4054-2-konishi.ryusuke@gmail.com Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: "Bai, Shuangpeng" <sjb7183(a)psu.edu> Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- fs/nilfs2/segment.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 80d90ccc6621..2d74fb229799 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2161,8 +2161,10 @@ static void nilfs_segctor_start_timer(struct nilfs_sc_info *sci) { spin_lock(&sci->sc_state_lock); if (!(sci->sc_state & NILFS_SEGCTOR_COMMIT)) { - sci->sc_timer.expires = jiffies + sci->sc_interval; - add_timer(&sci->sc_timer); + if (sci->sc_task) { + sci->sc_timer.expires = jiffies + sci->sc_interval; + add_timer(&sci->sc_timer); + } sci->sc_state |= NILFS_SEGCTOR_COMMIT; } spin_unlock(&sci->sc_state_lock); @@ -2380,10 +2382,21 @@ int nilfs_construct_dsync_segment(struct super_block *sb, struct inode *inode, */ static void nilfs_segctor_accept(struct nilfs_sc_info *sci) { + bool thread_is_alive; + spin_lock(&sci->sc_state_lock); sci->sc_seq_accepted = sci->sc_seq_request; + thread_is_alive = (bool)sci->sc_task; spin_unlock(&sci->sc_state_lock); - del_timer_sync(&sci->sc_timer); + + /* + * This function does not race with the log writer thread's + * termination. Therefore, deleting sc_timer, which should not be + * done after the log writer thread exits, can be done safely outside + * the area protected by sc_state_lock. + */ + if (thread_is_alive) + del_timer_sync(&sci->sc_timer); } /** @@ -2409,7 +2422,7 @@ static void nilfs_segctor_notify(struct nilfs_sc_info *sci, int mode, int err) sci->sc_flush_request &= ~FLUSH_DAT_BIT; /* re-enable timer if checkpoint creation was not done */ - if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && + if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && sci->sc_task && time_before(jiffies, sci->sc_timer.expires)) add_timer(&sci->sc_timer); } @@ -2599,6 +2612,7 @@ static int nilfs_segctor_thread(void *arg) int timeout = 0; sci->sc_timer_task = current; + timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); /* start sync. */ sci->sc_task = current; @@ -2665,6 +2679,7 @@ static int nilfs_segctor_thread(void *arg) end_thread: /* end sync. */ sci->sc_task = NULL; + timer_shutdown_sync(&sci->sc_timer); wake_up(&sci->sc_wait_task); /* for nilfs_segctor_kill_thread() */ spin_unlock(&sci->sc_state_lock); return 0; @@ -2728,7 +2743,6 @@ static struct nilfs_sc_info *nilfs_segctor_new(struct super_block *sb, INIT_LIST_HEAD(&sci->sc_gc_inodes); INIT_LIST_HEAD(&sci->sc_iput_queue); INIT_WORK(&sci->sc_iput_work, nilfs_iput_work_func); - timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); sci->sc_interval = HZ * NILFS_SC_DEFAULT_TIMEOUT; sci->sc_mjcp_freq = HZ * NILFS_SC_DEFAULT_SR_FREQ; @@ -2814,7 +2828,6 @@ static void nilfs_segctor_destroy(struct nilfs_sc_info *sci) down_write(&nilfs->ns_segctor_sem); - timer_shutdown_sync(&sci->sc_timer); kfree(sci); } -- 2.17.1

2 1

[PATCH OLK-5.10] net: mvpp2: clear BM pool before initialization
by Wang Hai 16 Jul '24

16 Jul '24

From: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> stable inclusion from stable-v5.10.210 commit 83f99138bf3b396f761600ab488054396fb5768f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9DC CVE: CVE-2024-35837 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9f538b415db862e74b8c5d3abbccfc1b2b6caa38 ] Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> Reviewed-by: Maxime Chevallier <maxime.chevallier(a)bootlin.com> Link: https://lore.kernel.org/r/20240119035914.2595665-1-jpatel2@marvell.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 27 ++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 217872a18282..41fd34cd551d 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -581,12 +581,38 @@ static int mvpp2_bm_pools_init(struct device *dev, struct mvpp2 *priv) return err; } +/* Cleanup pool before actual initialization in the OS */ +static void mvpp2_bm_pool_cleanup(struct mvpp2 *priv, int pool_id) +{ + unsigned int thread = mvpp2_cpu_to_thread(priv, get_cpu()); + u32 val; + int i; + + /* Drain the BM from all possible residues left by firmware */ + for (i = 0; i < MVPP2_BM_POOL_SIZE_MAX; i++) + mvpp2_thread_read(priv, thread, MVPP2_BM_PHY_ALLOC_REG(pool_id)); + + put_cpu(); + + /* Stop the BM pool */ + val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(pool_id)); + val |= MVPP2_BM_STOP_MASK; + mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(pool_id), val); +} + static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) { enum dma_data_direction dma_dir = DMA_FROM_DEVICE; int i, err, poolnum = MVPP2_BM_POOLS_NUM; struct mvpp2_port *port; + if (priv->percpu_pools) + poolnum = mvpp2_get_nrxqs(priv) * 2; + + /* Clean up the pool state in case it contains stale state */ + for (i = 0; i < poolnum; i++) + mvpp2_bm_pool_cleanup(priv, i); + if (priv->percpu_pools) { for (i = 0; i < priv->port_count; i++) { port = priv->port_list[i]; @@ -596,7 +622,6 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) } } - poolnum = mvpp2_get_nrxqs(priv) * 2; for (i = 0; i < poolnum; i++) { /* the pool in use */ int pn = i / (poolnum / 2); -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] net: mvpp2: clear BM pool before initialization
by Wang Hai 16 Jul '24

16 Jul '24

From: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> stable inclusion from stable-v5.10.210 commit 83f99138bf3b396f761600ab488054396fb5768f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9DC CVE: CVE-2024-35837 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9f538b415db862e74b8c5d3abbccfc1b2b6caa38 ] Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> Reviewed-by: Maxime Chevallier <maxime.chevallier(a)bootlin.com> Link: https://lore.kernel.org/r/20240119035914.2595665-1-jpatel2@marvell.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 27 ++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 765ec3bc11ad..4bebab7a9bff 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -581,12 +581,38 @@ static int mvpp2_bm_pools_init(struct device *dev, struct mvpp2 *priv) return err; } +/* Cleanup pool before actual initialization in the OS */ +static void mvpp2_bm_pool_cleanup(struct mvpp2 *priv, int pool_id) +{ + unsigned int thread = mvpp2_cpu_to_thread(priv, get_cpu()); + u32 val; + int i; + + /* Drain the BM from all possible residues left by firmware */ + for (i = 0; i < MVPP2_BM_POOL_SIZE_MAX; i++) + mvpp2_thread_read(priv, thread, MVPP2_BM_PHY_ALLOC_REG(pool_id)); + + put_cpu(); + + /* Stop the BM pool */ + val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(pool_id)); + val |= MVPP2_BM_STOP_MASK; + mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(pool_id), val); +} + static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) { enum dma_data_direction dma_dir = DMA_FROM_DEVICE; int i, err, poolnum = MVPP2_BM_POOLS_NUM; struct mvpp2_port *port; + if (priv->percpu_pools) + poolnum = mvpp2_get_nrxqs(priv) * 2; + + /* Clean up the pool state in case it contains stale state */ + for (i = 0; i < poolnum; i++) + mvpp2_bm_pool_cleanup(priv, i); + if (priv->percpu_pools) { for (i = 0; i < priv->port_count; i++) { port = priv->port_list[i]; @@ -596,7 +622,6 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) } } - poolnum = mvpp2_get_nrxqs(priv) * 2; for (i = 0; i < poolnum; i++) { /* the pool in use */ int pn = i / (poolnum / 2); -- 2.17.1

2 1

[PATCH OLK-5.10] udp: do not accept non-tunnel GSO skbs landing in a tunnel
by Wang Hai 16 Jul '24

16 Jul '24

From: Antoine Tenart <atenart(a)kernel.org> stable inclusion from stable-v5.10.215 commit 3391b157780bbedf8ef9f202cbf10ee90bf6b0f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QG8X CVE: CVE-2024-35884 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3d010c8031e39f5fa1e8b13ada77e0321091011f ] When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560 Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets") Signed-off-by: Antoine Tenart <atenart(a)kernel.org> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/ipv4/udp_offload.c [commit c8dc8d3a4897 was merged, which lead to context conflicts] Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- include/linux/udp.h | 28 ++++++++++++++++++++++++++++ net/ipv4/udp.c | 7 +++++++ net/ipv4/udp_offload.c | 6 ++++-- net/ipv6/udp.c | 2 +- 4 files changed, 40 insertions(+), 3 deletions(-) diff --git a/include/linux/udp.h b/include/linux/udp.h index ae58ff3b6b5b..a220880019d6 100644 --- a/include/linux/udp.h +++ b/include/linux/udp.h @@ -131,6 +131,24 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk, } } +DECLARE_STATIC_KEY_FALSE(udp_encap_needed_key); +#if IS_ENABLED(CONFIG_IPV6) +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +#endif + +static inline bool udp_encap_needed(void) +{ + if (static_branch_unlikely(&udp_encap_needed_key)) + return true; + +#if IS_ENABLED(CONFIG_IPV6) + if (static_branch_unlikely(&udpv6_encap_needed_key)) + return true; +#endif + + return false; +} + static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) { if (!skb_is_gso(skb)) @@ -142,6 +160,16 @@ static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST && !udp_sk(sk)->accept_udp_fraglist) return true; + /* GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits might still + * land in a tunnel as the socket check in udp_gro_receive cannot be + * foolproof. + */ + if (udp_encap_needed() && + READ_ONCE(udp_sk(sk)->encap_rcv) && + !(skb_shinfo(skb)->gso_type & + (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM))) + return true; + return false; } diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index ef41810b48e5..0ea08b04a2a7 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -602,6 +602,13 @@ static inline bool __udp_is_mcast_sock(struct net *net, struct sock *sk, } DEFINE_STATIC_KEY_FALSE(udp_encap_needed_key); +EXPORT_SYMBOL(udp_encap_needed_key); + +#if IS_ENABLED(CONFIG_IPV6) +DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +EXPORT_SYMBOL(udpv6_encap_needed_key); +#endif + void udp_encap_enable(void) { static_branch_inc(&udp_encap_needed_key); diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 0cdd356866ec..ed50a5f33302 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -512,8 +512,10 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb, unsigned int off = skb_gro_offset(skb); int flush = 1; - /* we can do L4 aggregation only if the packet can't land in a tunnel - * otherwise we could corrupt the inner stream + /* We can do L4 aggregation only if the packet can't land in a tunnel + * otherwise we could corrupt the inner stream. Detecting such packets + * cannot be foolproof and the aggregation might still happen in some + * cases. Such packets should be caught in udp_unexpected_gso later. */ NAPI_GRO_CB(skb)->is_flist = 0; if (!sk || !udp_sk(sk)->gro_receive) { diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index e5ced1f2d812..35cca1ec5ca7 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -473,7 +473,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, goto try_again; } -DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); void udpv6_encap_enable(void) { static_branch_inc(&udpv6_encap_needed_key); -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] udp: do not accept non-tunnel GSO skbs landing in a tunnel
by Wang Hai 16 Jul '24

16 Jul '24

From: Antoine Tenart <atenart(a)kernel.org> stable inclusion from stable-v5.10.215 commit 3391b157780bbedf8ef9f202cbf10ee90bf6b0f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QG8X CVE: CVE-2024-35884 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3d010c8031e39f5fa1e8b13ada77e0321091011f ] When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560 Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets") Signed-off-by: Antoine Tenart <atenart(a)kernel.org> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/ipv4/udp_offload.c [commit 205c0514a5f6 was merged, which lead to context conflicts] Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- include/linux/udp.h | 28 ++++++++++++++++++++++++++++ net/ipv4/udp.c | 7 +++++++ net/ipv4/udp_offload.c | 6 ++++-- net/ipv6/udp.c | 2 +- 4 files changed, 40 insertions(+), 3 deletions(-) diff --git a/include/linux/udp.h b/include/linux/udp.h index ae58ff3b6b5b..a220880019d6 100644 --- a/include/linux/udp.h +++ b/include/linux/udp.h @@ -131,6 +131,24 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk, } } +DECLARE_STATIC_KEY_FALSE(udp_encap_needed_key); +#if IS_ENABLED(CONFIG_IPV6) +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +#endif + +static inline bool udp_encap_needed(void) +{ + if (static_branch_unlikely(&udp_encap_needed_key)) + return true; + +#if IS_ENABLED(CONFIG_IPV6) + if (static_branch_unlikely(&udpv6_encap_needed_key)) + return true; +#endif + + return false; +} + static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) { if (!skb_is_gso(skb)) @@ -142,6 +160,16 @@ static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST && !udp_sk(sk)->accept_udp_fraglist) return true; + /* GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits might still + * land in a tunnel as the socket check in udp_gro_receive cannot be + * foolproof. + */ + if (udp_encap_needed() && + READ_ONCE(udp_sk(sk)->encap_rcv) && + !(skb_shinfo(skb)->gso_type & + (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM))) + return true; + return false; } diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index beccdd959d10..d1f642f4a37f 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -592,6 +592,13 @@ static inline bool __udp_is_mcast_sock(struct net *net, struct sock *sk, } DEFINE_STATIC_KEY_FALSE(udp_encap_needed_key); +EXPORT_SYMBOL(udp_encap_needed_key); + +#if IS_ENABLED(CONFIG_IPV6) +DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +EXPORT_SYMBOL(udpv6_encap_needed_key); +#endif + void udp_encap_enable(void) { static_branch_inc(&udp_encap_needed_key); diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 0cdd356866ec..ed50a5f33302 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -512,8 +512,10 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb, unsigned int off = skb_gro_offset(skb); int flush = 1; - /* we can do L4 aggregation only if the packet can't land in a tunnel - * otherwise we could corrupt the inner stream + /* We can do L4 aggregation only if the packet can't land in a tunnel + * otherwise we could corrupt the inner stream. Detecting such packets + * cannot be foolproof and the aggregation might still happen in some + * cases. Such packets should be caught in udp_unexpected_gso later. */ NAPI_GRO_CB(skb)->is_flist = 0; if (!sk || !udp_sk(sk)->gro_receive) { diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index 08a2ceb6b999..83995db29358 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -451,7 +451,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, goto try_again; } -DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); void udpv6_encap_enable(void) { static_branch_inc(&udpv6_encap_needed_key); -- 2.17.1

2 1

[PATCH OLK-6.6] io_uring/rsrc: don't lock while !TASK_RUNNING
by Long Li 16 Jul '24

16 Jul '24

From: Pavel Begunkov <asml.silence(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit 54559642b96116b45e4b5ca7fd9f7835b8561272 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV39 CVE: CVE-2024-40922 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a report of io_rsrc_ref_quiesce() locking a mutex while not TASK_RUNNING, which is due to forgetting restoring the state back after io_run_task_work_sig() and attempts to break out of the waiting loop. do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff815d2494>] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: <TASK> __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 [inline] __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Reported-by: Li Shi <sl1589472800(a)gmail.com> Fixes: 4ea15b56f0810 ("io_uring/rsrc: use wq for quiescing") Cc: stable(a)vger.kernel.org Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/77966bc104e25b0534995d5dbb152332bc8f31c0.17181969… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- io_uring/rsrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c index 95230921b16d..2e88b6658e4e 100644 --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -250,6 +250,7 @@ __cold static int io_rsrc_ref_quiesce(struct io_rsrc_data *data, ret = io_run_task_work_sig(ctx); if (ret < 0) { + __set_current_state(TASK_RUNNING); mutex_lock(&ctx->uring_lock); if (list_empty(&ctx->rsrc_ref_list)) ret = 0; -- 2.39.2

2 1

[PATCH OLK-6.6] media: v4l: async: Fix notifier list entry init
by Kaixiong Yu 16 Jul '24

16 Jul '24

From: Alexander Stein <alexander.stein(a)ew.tq-group.com> stable inclusion from stable-v6.6.34 commit a80d1da923f671c1e6a14e8417cd2f117b27a442 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8ADV CVE: CVE-2024-39464 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6d8acd02c4c6a8f917eefac1de2e035521ca119d upstream. struct v4l2_async_notifier has several list_head members, but only waiting_list and done_list are initialized. notifier_entry was kept 'zeroed' leading to an uninitialized list_head. This results in a NULL-pointer dereference if csi2_async_register() fails, e.g. node for remote endpoint is disabled, and returns -ENOTCONN. The following calls to v4l2_async_nf_unregister() results in a NULL pointer dereference. Add the missing list head initializer. Fixes: b8ec754ae4c5 ("media: v4l: async: Set v4l2_device and subdev in async notifier init") Cc: <stable(a)vger.kernel.org> # for 6.6 and later Signed-off-by: Alexander Stein <alexander.stein(a)ew.tq-group.com> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/media/v4l2-core/v4l2-async.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 8cfd593d293d..8402f369c7e3 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -563,6 +563,7 @@ void v4l2_async_nf_init(struct v4l2_async_notifier *notifier, { INIT_LIST_HEAD(&notifier->waiting_list); INIT_LIST_HEAD(&notifier->done_list); + INIT_LIST_HEAD(&notifier->notifier_entry); notifier->v4l2_dev = v4l2_dev; } EXPORT_SYMBOL(v4l2_async_nf_init); @@ -572,6 +573,7 @@ void v4l2_async_subdev_nf_init(struct v4l2_async_notifier *notifier, { INIT_LIST_HEAD(&notifier->waiting_list); INIT_LIST_HEAD(&notifier->done_list); + INIT_LIST_HEAD(&notifier->notifier_entry); notifier->sd = sd; } EXPORT_SYMBOL_GPL(v4l2_async_subdev_nf_init); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] vmci: prevent speculation leaks by sanitizing event in event_deliver()
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc1 commit 8003f00d895310d409b2bf9ef907c56b42a4e0f4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0E8 CVE: CVE-2024-39499 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Cc: stable <stable(a)kernel.org> Signed-off-by: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/stable/20231127193533.46174-1-hagarhem%40amazon.com Link: https://lore.kernel.org/r/20240430085916.4753-1-hagarhem@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_event.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_vmci/vmci_event.c b/drivers/misc/vmw_vmci/vmci_event.c index 84258a48029d..da24cb341a7f 100644 --- a/drivers/misc/vmw_vmci/vmci_event.c +++ b/drivers/misc/vmw_vmci/vmci_event.c @@ -17,6 +17,7 @@ #include <linux/vmw_vmci_api.h> #include <linux/list.h> #include <linux/module.h> +#include <linux/nospec.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/rculist.h> @@ -94,9 +95,12 @@ static void event_deliver(struct vmci_event_msg *event_msg) { struct vmci_subscription *cur; struct list_head *subscriber_list; + u32 sanitized_event, max_vmci_event; rcu_read_lock(); - subscriber_list = &subscriber_array[event_msg->event_data.event]; + max_vmci_event = ARRAY_SIZE(subscriber_array); + sanitized_event = array_index_nospec(event_msg->event_data.event, max_vmci_event); + subscriber_list = &subscriber_array[sanitized_event]; list_for_each_entry_rcu(cur, subscriber_list, node) { cur->callback(cur->id, &event_msg->event_data, cur->callback_data); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] vmci: prevent speculation leaks by sanitizing event in event_deliver()
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc1 commit 8003f00d895310d409b2bf9ef907c56b42a4e0f4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0E8 CVE: CVE-2024-39499 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Cc: stable <stable(a)kernel.org> Signed-off-by: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/stable/20231127193533.46174-1-hagarhem%40amazon.com Link: https://lore.kernel.org/r/20240430085916.4753-1-hagarhem@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_event.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_vmci/vmci_event.c b/drivers/misc/vmw_vmci/vmci_event.c index e3436abf39f4..5b7ef47f4c11 100644 --- a/drivers/misc/vmw_vmci/vmci_event.c +++ b/drivers/misc/vmw_vmci/vmci_event.c @@ -9,6 +9,7 @@ #include <linux/vmw_vmci_api.h> #include <linux/list.h> #include <linux/module.h> +#include <linux/nospec.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/rculist.h> @@ -86,9 +87,12 @@ static void event_deliver(struct vmci_event_msg *event_msg) { struct vmci_subscription *cur; struct list_head *subscriber_list; + u32 sanitized_event, max_vmci_event; rcu_read_lock(); - subscriber_list = &subscriber_array[event_msg->event_data.event]; + max_vmci_event = ARRAY_SIZE(subscriber_array); + sanitized_event = array_index_nospec(event_msg->event_data.event, max_vmci_event); + subscriber_list = &subscriber_array[sanitized_event]; list_for_each_entry_rcu(cur, subscriber_list, node) { cur->callback(cur->id, &event_msg->event_data, cur->callback_data); -- 2.25.1

2 1

[PATCH OLK-5.10] vmci: prevent speculation leaks by sanitizing event in event_deliver()
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc1 commit 8003f00d895310d409b2bf9ef907c56b42a4e0f4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0E8 CVE: CVE-2024-39499 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Cc: stable <stable(a)kernel.org> Signed-off-by: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/stable/20231127193533.46174-1-hagarhem%40amazon.com Link: https://lore.kernel.org/r/20240430085916.4753-1-hagarhem@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_event.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_vmci/vmci_event.c b/drivers/misc/vmw_vmci/vmci_event.c index e3436abf39f4..5b7ef47f4c11 100644 --- a/drivers/misc/vmw_vmci/vmci_event.c +++ b/drivers/misc/vmw_vmci/vmci_event.c @@ -9,6 +9,7 @@ #include <linux/vmw_vmci_api.h> #include <linux/list.h> #include <linux/module.h> +#include <linux/nospec.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/rculist.h> @@ -86,9 +87,12 @@ static void event_deliver(struct vmci_event_msg *event_msg) { struct vmci_subscription *cur; struct list_head *subscriber_list; + u32 sanitized_event, max_vmci_event; rcu_read_lock(); - subscriber_list = &subscriber_array[event_msg->event_data.event]; + max_vmci_event = ARRAY_SIZE(subscriber_array); + sanitized_event = array_index_nospec(event_msg->event_data.event, max_vmci_event); + subscriber_list = &subscriber_array[sanitized_event]; list_for_each_entry_rcu(cur, subscriber_list, node) { cur->callback(cur->id, &event_msg->event_data, cur->callback_data); -- 2.25.1

2 1

[PATCH OLK-6.6] tipc: force a dst refcount before doing decryption
by Liu Jian 16 Jul '24

16 Jul '24

From: Xin Long <lucien.xin(a)gmail.com> stable inclusion from stable-v6.6.36 commit b57a4a2dc8746cea58a922ebe31b6aa629d69d93 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD07A CVE: CVE-2024-40983 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 2ebe8f840c7450ecbfca9d18ac92e9ce9155e269 ] As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0 Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Shuang Li <shuali(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Link: https://lore.kernel.org/r/fbe3195fad6997a4eec62d9bf076b2ad03ac336b.17184760… Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tipc/node.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/tipc/node.c b/net/tipc/node.c index 3105abe97bb9..69053c039825 100644 --- a/net/tipc/node.c +++ b/net/tipc/node.c @@ -2107,6 +2107,7 @@ void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b) } else { n = tipc_node_find_by_id(net, ehdr->id); } + skb_dst_force(skb); tipc_crypto_rcv(net, (n) ? n->crypto_rx : NULL, &skb, b); if (!skb) return; -- 2.34.1

2 1

[PATCH OLK-6.6] vmci: prevent speculation leaks by sanitizing event in event_deliver()
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc1 commit 8003f00d895310d409b2bf9ef907c56b42a4e0f4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0E8 CVE: CVE-2024-39499 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Cc: stable <stable(a)kernel.org> Signed-off-by: Hagar Gamal Halim Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/stable/20231127193533.46174-1-hagarhem%40amazon.com Link: https://lore.kernel.org/r/20240430085916.4753-1-hagarhem@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_event.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_vmci/vmci_event.c b/drivers/misc/vmw_vmci/vmci_event.c index 5d7ac07623c2..9a41ab65378d 100644 --- a/drivers/misc/vmw_vmci/vmci_event.c +++ b/drivers/misc/vmw_vmci/vmci_event.c @@ -9,6 +9,7 @@ #include <linux/vmw_vmci_api.h> #include <linux/list.h> #include <linux/module.h> +#include <linux/nospec.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/rculist.h> @@ -86,9 +87,12 @@ static void event_deliver(struct vmci_event_msg *event_msg) { struct vmci_subscription *cur; struct list_head *subscriber_list; + u32 sanitized_event, max_vmci_event; rcu_read_lock(); - subscriber_list = &subscriber_array[event_msg->event_data.event]; + max_vmci_event = ARRAY_SIZE(subscriber_array); + sanitized_event = array_index_nospec(event_msg->event_data.event, max_vmci_event); + subscriber_list = &subscriber_array[sanitized_event]; list_for_each_entry_rcu(cur, subscriber_list, node) { cur->callback(cur->id, &event_msg->event_data, cur->callback_data); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tipc: force a dst refcount before doing decryption
by Liu Jian 16 Jul '24

16 Jul '24

From: Xin Long <lucien.xin(a)gmail.com> stable inclusion from stable-v5.10.221 commit 3eb1b39627892c4e26cb0162b75725aa5fcc60c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD07A CVE: CVE-2024-40983 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 2ebe8f840c7450ecbfca9d18ac92e9ce9155e269 ] As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0 Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Shuang Li <shuali(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Link: https://lore.kernel.org/r/fbe3195fad6997a4eec62d9bf076b2ad03ac336b.17184760… Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tipc/node.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/tipc/node.c b/net/tipc/node.c index 60059827563a..2abd5c67b1b9 100644 --- a/net/tipc/node.c +++ b/net/tipc/node.c @@ -2066,6 +2066,7 @@ void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b) } else { n = tipc_node_find_by_id(net, ehdr->id); } + skb_dst_force(skb); tipc_crypto_rcv(net, (n) ? n->crypto_rx : NULL, &skb, b); if (!skb) return; -- 2.34.1

2 1

[PATCH OLK-5.10] tipc: force a dst refcount before doing decryption
by Liu Jian 16 Jul '24

16 Jul '24

From: Xin Long <lucien.xin(a)gmail.com> stable inclusion from stable-v5.10.221 commit 3eb1b39627892c4e26cb0162b75725aa5fcc60c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD07A CVE: CVE-2024-40983 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 2ebe8f840c7450ecbfca9d18ac92e9ce9155e269 ] As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0 Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Shuang Li <shuali(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Link: https://lore.kernel.org/r/fbe3195fad6997a4eec62d9bf076b2ad03ac336b.17184760… Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tipc/node.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/tipc/node.c b/net/tipc/node.c index 9e3cfeb82a23..5f6866407be5 100644 --- a/net/tipc/node.c +++ b/net/tipc/node.c @@ -2076,6 +2076,7 @@ void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b) } else { n = tipc_node_find_by_id(net, ehdr->id); } + skb_dst_force(skb); tipc_crypto_rcv(net, (n) ? n->crypto_rx : NULL, &skb, b); if (!skb) return; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-40968
by Liao Chen 16 Jul '24

16 Jul '24

MIPS: Octeon: Add PCIe link status check Songyang Li (1): MIPS: Octeon: Add PCIe link status check arch/mips/pci/pcie-octeon.c | 6 ++++++ 1 file changed, 6 insertions(+) mode change 100644 => 100755 arch/mips/pci/pcie-octeon.c -- 2.34.1

2 2

[PATCH OLK-5.10 0/5] nfs: Ensure that the NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values: Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes: Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-6.6] misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()
by Kaixiong Yu 16 Jul '24

16 Jul '24

From: Yongzhi Liu <hyperlyzcs(a)gmail.com> stable inclusion from stable-v6.6.35 commit 86c9713602f786f441630c4ee02891987f8618b9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SDT CVE: CVE-2024-36973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 086c6cbcc563c81d55257f9b27e14faf1d0963d3 upstream. When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path. Fix this by skipping the redundant cleanup functions. Fixes: 393fc2f5948f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.") Signed-off-by: Yongzhi Liu <hyperlyzcs(a)gmail.com> Link: https://lore.kernel.org/r/20240523121434.21855-3-hyperlyzcs@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c index 32af2b14ff34..de75d89ef53e 100644 --- a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c +++ b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c @@ -111,6 +111,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_aux_dev_add_1: auxiliary_device_uninit(&aux_bus->aux_device_wrapper[1]->aux_dev); + goto err_aux_dev_add_0; err_aux_dev_init_1: ida_free(&gp_client_ida, aux_bus->aux_device_wrapper[1]->aux_dev.id); @@ -120,6 +121,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_aux_dev_add_0: auxiliary_device_uninit(&aux_bus->aux_device_wrapper[0]->aux_dev); + goto err_ret; err_aux_dev_init_0: ida_free(&gp_client_ida, aux_bus->aux_device_wrapper[0]->aux_dev.id); @@ -127,6 +129,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_ida_alloc_0: kfree(aux_bus->aux_device_wrapper[0]); +err_ret: return retval; } -- 2.25.1

2 1

[PATCH OLK-6.6 0/5] btrfs: fix CVE-2024-39496
by Long Li 16 Jul '24

16 Jul '24

This patch set fix CVE-2024-39496. Christoph Hellwig (4): btrfs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info btrfs: zoned: factor out per-zone logic from btrfs_load_block_group_zone_info btrfs: zoned: factor out single bg handling from btrfs_load_block_group_zone_info btrfs: zoned: factor out DUP bg handling from btrfs_load_block_group_zone_info Filipe Manana (1): btrfs: zoned: fix use-after-free due to race with dev replace fs/btrfs/zoned.c | 330 ++++++++++++++++++++++++----------------------- 1 file changed, 170 insertions(+), 160 deletions(-) -- 2.39.2

2 6

[PATCH openEuler-22.03-LTS-SP1] lib/generic-radix-tree.c: Don't overflow in peek()
by Zhao Wenhui 16 Jul '24

16 Jul '24

From: Kent Overstreet <kent.overstreet(a)gmail.com> mainline inclusion from mainline-v6.7-rc1 commit 9492261ff2460252cf2d8de89cdf854c7e2b28a0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4NX CVE: CVE-2021-47432 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops. Conflicts: include/linux/generic-radix-tree.h [head file differents.] Signed-off-by: Kent Overstreet <kent.overstreet(a)gmail.com> Signed-off-by: Zhao Wenhui <zhaowenhui8(a)huawei.com> --- include/linux/generic-radix-tree.h | 7 +++++++ lib/generic-radix-tree.c | 17 ++++++++++++++--- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/include/linux/generic-radix-tree.h b/include/linux/generic-radix-tree.h index bfd00320c7f3..0e7abc635e5f 100644 --- a/include/linux/generic-radix-tree.h +++ b/include/linux/generic-radix-tree.h @@ -39,6 +39,7 @@ #include <asm/page.h> #include <linux/bug.h> #include <linux/kernel.h> +#include <linux/limits.h> #include <linux/log2.h> struct genradix_root; @@ -183,6 +184,12 @@ void *__genradix_iter_peek(struct genradix_iter *, struct __genradix *, size_t); static inline void __genradix_iter_advance(struct genradix_iter *iter, size_t obj_size) { + if (iter->offset + obj_size < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return; + } + iter->offset += obj_size; if (!is_power_of_2(obj_size) && diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c index f25eb111c051..7dfa88282b00 100644 --- a/lib/generic-radix-tree.c +++ b/lib/generic-radix-tree.c @@ -166,6 +166,10 @@ void *__genradix_iter_peek(struct genradix_iter *iter, struct genradix_root *r; struct genradix_node *n; unsigned level, i; + + if (iter->offset == SIZE_MAX) + return NULL; + restart: r = READ_ONCE(radix->root); if (!r) @@ -184,10 +188,17 @@ void *__genradix_iter_peek(struct genradix_iter *iter, (GENRADIX_ARY - 1); while (!n->children[i]) { + size_t objs_per_ptr = genradix_depth_size(level); + + if (iter->offset + objs_per_ptr < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return NULL; + } + i++; - iter->offset = round_down(iter->offset + - genradix_depth_size(level), - genradix_depth_size(level)); + iter->offset = round_down(iter->offset + objs_per_ptr, + objs_per_ptr); iter->pos = (iter->offset >> PAGE_SHIFT) * objs_per_page; if (i == GENRADIX_ARY) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10] lib/generic-radix-tree.c: Don't overflow in peek()
by Zhao Wenhui 16 Jul '24

16 Jul '24

From: Kent Overstreet <kent.overstreet(a)gmail.com> mainline inclusion from mainline-v6.7-rc1 commit 9492261ff2460252cf2d8de89cdf854c7e2b28a0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4NX CVE: CVE-2021-47432 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops. Conflicts: include/linux/generic-radix-tree.h [head file differents.] Signed-off-by: Kent Overstreet <kent.overstreet(a)gmail.com> Signed-off-by: Zhao Wenhui <zhaowenhui8(a)huawei.com> --- include/linux/generic-radix-tree.h | 7 +++++++ lib/generic-radix-tree.c | 17 ++++++++++++++--- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/include/linux/generic-radix-tree.h b/include/linux/generic-radix-tree.h index bfd00320c7f3..0e7abc635e5f 100644 --- a/include/linux/generic-radix-tree.h +++ b/include/linux/generic-radix-tree.h @@ -39,6 +39,7 @@ #include <asm/page.h> #include <linux/bug.h> #include <linux/kernel.h> +#include <linux/limits.h> #include <linux/log2.h> struct genradix_root; @@ -183,6 +184,12 @@ void *__genradix_iter_peek(struct genradix_iter *, struct __genradix *, size_t); static inline void __genradix_iter_advance(struct genradix_iter *iter, size_t obj_size) { + if (iter->offset + obj_size < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return; + } + iter->offset += obj_size; if (!is_power_of_2(obj_size) && diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c index f25eb111c051..7dfa88282b00 100644 --- a/lib/generic-radix-tree.c +++ b/lib/generic-radix-tree.c @@ -166,6 +166,10 @@ void *__genradix_iter_peek(struct genradix_iter *iter, struct genradix_root *r; struct genradix_node *n; unsigned level, i; + + if (iter->offset == SIZE_MAX) + return NULL; + restart: r = READ_ONCE(radix->root); if (!r) @@ -184,10 +188,17 @@ void *__genradix_iter_peek(struct genradix_iter *iter, (GENRADIX_ARY - 1); while (!n->children[i]) { + size_t objs_per_ptr = genradix_depth_size(level); + + if (iter->offset + objs_per_ptr < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return NULL; + } + i++; - iter->offset = round_down(iter->offset + - genradix_depth_size(level), - genradix_depth_size(level)); + iter->offset = round_down(iter->offset + objs_per_ptr, + objs_per_ptr); iter->pos = (iter->offset >> PAGE_SHIFT) * objs_per_page; if (i == GENRADIX_ARY) -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 V1] media: v4l: async: Properly re-initialise notifier entry in unregister
by Cheng Yu 16 Jul '24

16 Jul '24

From: Sakari Ailus <sakari.ailus(a)linux.intel.com> mainline inclusion from mainline-v6.10-rc1 commit 9537a8425a7a0222999d5839a0b394b1e8834b4a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05K CVE: CVE-2024-39485 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list. Fixes: b8ec754ae4c5 ("media: v4l: async: Set v4l2_device and subdev in async notifier init") Cc: <stable(a)vger.kernel.org> # for 6.6 and later Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/media/v4l2-core/v4l2-async.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 8cfd593d293d..e6b9ba2c8e6e 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -639,7 +639,7 @@ __v4l2_async_nf_unregister(struct v4l2_async_notifier *notifier) v4l2_async_nf_unbind_all_subdevs(notifier); - list_del(&notifier->notifier_entry); + list_del_init(&notifier->notifier_entry); } void v4l2_async_nf_unregister(struct v4l2_async_notifier *notifier) -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/5] nfs: Ensure that the NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] nfs: Ensure that the NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH openEuler-22.03-LTS-SP1 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH openEuler-1.0-LTS] ipv6: prevent possible NULL dereference in rt6_probe()
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.317 commit f0cda984e4e634b221dbf9642b8ecc5b4806b41e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS4Q CVE: CVE-2024-40960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b86762dbe19a62e785c189f313cda5b989931f37 ] syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 52e1635631b3 ("[IPV6]: ROUTE: Add router_probe_interval sysctl.") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Jason Xing <kerneljasonxing(a)gmail.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240615151454.166404-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 34788a62c9c2..e7ff0f40867b 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -546,6 +546,8 @@ static void rt6_probe(struct fib6_info *rt) rcu_read_lock_bh(); last_probe = READ_ONCE(rt->last_probe); idev = __in6_dev_get(dev); + if (!idev) + goto out; neigh = __ipv6_neigh_lookup_noref(dev, nh_gw); if (neigh) { if (neigh->nud_state & NUD_VALID) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipv6: prevent possible NULL dereference in rt6_probe()
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.221 commit 1ed9849fdf9a1a617129346b11d2094ca26828dc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS4Q CVE: CVE-2024-40960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b86762dbe19a62e785c189f313cda5b989931f37 ] syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 52e1635631b3 ("[IPV6]: ROUTE: Add router_probe_interval sysctl.") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Jason Xing <kerneljasonxing(a)gmail.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240615151454.166404-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 59bd6f57357f..8a4bc71b018d 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -627,6 +627,8 @@ static void rt6_probe(struct fib6_nh *fib6_nh) rcu_read_lock_bh(); last_probe = READ_ONCE(fib6_nh->last_probe); idev = __in6_dev_get(dev); + if (!idev) + goto out; neigh = __ipv6_neigh_lookup_noref(dev, nh_gw); if (neigh) { if (neigh->nud_state & NUD_VALID) -- 2.34.1

2 1

[PATCH OLK-5.10] ipv6: prevent possible NULL dereference in rt6_probe()
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.221 commit 1ed9849fdf9a1a617129346b11d2094ca26828dc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS4Q CVE: CVE-2024-40960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b86762dbe19a62e785c189f313cda5b989931f37 ] syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 52e1635631b3 ("[IPV6]: ROUTE: Add router_probe_interval sysctl.") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Jason Xing <kerneljasonxing(a)gmail.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240615151454.166404-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 96b3ddafb8d1..2c1961d037dc 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -627,6 +627,8 @@ static void rt6_probe(struct fib6_nh *fib6_nh) rcu_read_lock_bh(); last_probe = READ_ONCE(fib6_nh->last_probe); idev = __in6_dev_get(dev); + if (!idev) + goto out; neigh = __ipv6_neigh_lookup_noref(dev, nh_gw); if (neigh) { if (neigh->nud_state & NUD_VALID) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-6.6] ipv6: prevent possible NULL dereference in rt6_probe()
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.36 commit 73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS4Q CVE: CVE-2024-40960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b86762dbe19a62e785c189f313cda5b989931f37 ] syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 52e1635631b3 ("[IPV6]: ROUTE: Add router_probe_interval sysctl.") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Jason Xing <kerneljasonxing(a)gmail.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240615151454.166404-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 236a45557ba1..eea970f0a5e8 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -637,6 +637,8 @@ static void rt6_probe(struct fib6_nh *fib6_nh) rcu_read_lock(); last_probe = READ_ONCE(fib6_nh->last_probe); idev = __in6_dev_get(dev); + if (!idev) + goto out; neigh = __ipv6_neigh_lookup_noref(dev, nh_gw); if (neigh) { if (READ_ONCE(neigh->nud_state) & NUD_VALID) -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] bpf: Fix null-pointer-deref in resolve_prog_type()
by Tengda Wu 16 Jul '24

16 Jul '24

Hi, This patchset is going to fix null-pointer-deref in resolve_prog_type() for BPF_PROG_TYPE_EXT. `prog->aux->dst_prog` in resolve_prog_type() is assigned by `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided. Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will lead to null-pointer-deref. In last version we fix it by forcing `attach_prog_fd` non-empty at load time, which leads to libbpf_probe_prog_types() api broken. Currently, we fix it by just adding null check for EXT prog in resolve_prog_type() as the old way did. For the sake of safety, we compared the full test logs of selftest before and after applying these changes, and the results show that the two test logs were consistent. Best regards, Tengda Tengda Wu (2): bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() include/linux/bpf_verifier.h | 2 +- tools/testing/selftests/bpf/verifier/calls.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
by Liu Jian 16 Jul '24

16 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v4.19.317 commit 87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW2 CVE: CVE-2024-39506 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ] In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c index a1bda1683ebf..d90500573f5b 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c @@ -289,13 +289,12 @@ lio_vf_rep_copy_packet(struct octeon_device *oct, pg_info->page_offset; memcpy(skb->data, va, MIN_SKB_SIZE); skb_put(skb, MIN_SKB_SIZE); + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + pg_info->page, + pg_info->page_offset + MIN_SKB_SIZE, + len - MIN_SKB_SIZE, + LIO_RXBUFFER_SZ); } - - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, - pg_info->page, - pg_info->page_offset + MIN_SKB_SIZE, - len - MIN_SKB_SIZE, - LIO_RXBUFFER_SZ); } else { struct octeon_skb_page_info *pg_info = ((struct octeon_skb_page_info *)(skb->cb)); -- 2.34.1

2 1

[PATCH OLK-6.6] 9p: add missing locking around taking dentry fid list
by Xia Fukun 16 Jul '24

16 Jul '24

From: Dominique Martinet <asmadeus(a)codewreck.org> mainline inclusion from mainline-v6.10-rc6 commit c898afdc15645efb555acb6d85b484eb40a45409 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AFV CVE: CVE-2024-39463 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible. Fixes: 154372e67d40 ("fs/9p: fix create-unlink-getattr idiom") Cc: stable(a)vger.kernel.org Reported-by: Meysam Firouzi Reported-by: Amirmohammad Eftekhar Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Message-ID: <20240521122947.1080227-1-asmadeus(a)codewreck.org> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- fs/9p/vfs_dentry.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/9p/vfs_dentry.c b/fs/9p/vfs_dentry.c index f16f73581634..01338d4c2d9e 100644 --- a/fs/9p/vfs_dentry.c +++ b/fs/9p/vfs_dentry.c @@ -48,12 +48,17 @@ static int v9fs_cached_dentry_delete(const struct dentry *dentry) static void v9fs_dentry_release(struct dentry *dentry) { struct hlist_node *p, *n; + struct hlist_head head; p9_debug(P9_DEBUG_VFS, " dentry: %pd (%p)\n", dentry, dentry); - hlist_for_each_safe(p, n, (struct hlist_head *)&dentry->d_fsdata) + + spin_lock(&dentry->d_lock); + hlist_move_list((struct hlist_head *)&dentry->d_fsdata, &head); + spin_unlock(&dentry->d_lock); + + hlist_for_each_safe(p, n, &head) p9_fid_put(hlist_entry(p, struct p9_fid, dlist)); - dentry->d_fsdata = NULL; } static int v9fs_lookup_revalidate(struct dentry *dentry, unsigned int flags) -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1] liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
by Liu Jian 16 Jul '24

16 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.221 commit cbf18d8128a753cb632bef39470d19befd9c7347 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW2 CVE: CVE-2024-39506 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ] In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c index 600de587d7a9..e70b9ccca380 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c @@ -272,13 +272,12 @@ lio_vf_rep_copy_packet(struct octeon_device *oct, pg_info->page_offset; memcpy(skb->data, va, MIN_SKB_SIZE); skb_put(skb, MIN_SKB_SIZE); + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + pg_info->page, + pg_info->page_offset + MIN_SKB_SIZE, + len - MIN_SKB_SIZE, + LIO_RXBUFFER_SZ); } - - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, - pg_info->page, - pg_info->page_offset + MIN_SKB_SIZE, - len - MIN_SKB_SIZE, - LIO_RXBUFFER_SZ); } else { struct octeon_skb_page_info *pg_info = ((struct octeon_skb_page_info *)(skb->cb)); -- 2.34.1

2 1

[PATCH OLK-5.10] liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
by Liu Jian 16 Jul '24

16 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.221 commit cbf18d8128a753cb632bef39470d19befd9c7347 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW2 CVE: CVE-2024-39506 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ] In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c index 600de587d7a9..e70b9ccca380 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c @@ -272,13 +272,12 @@ lio_vf_rep_copy_packet(struct octeon_device *oct, pg_info->page_offset; memcpy(skb->data, va, MIN_SKB_SIZE); skb_put(skb, MIN_SKB_SIZE); + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + pg_info->page, + pg_info->page_offset + MIN_SKB_SIZE, + len - MIN_SKB_SIZE, + LIO_RXBUFFER_SZ); } - - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, - pg_info->page, - pg_info->page_offset + MIN_SKB_SIZE, - len - MIN_SKB_SIZE, - LIO_RXBUFFER_SZ); } else { struct octeon_skb_page_info *pg_info = ((struct octeon_skb_page_info *)(skb->cb)); -- 2.34.1

2 1

[PATCH OLK-6.6] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24

From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index fb941a8c99f0..e17f9c5c9c90 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -309,6 +309,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -328,7 +329,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24

From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index e5662bdcbbde..d27a8d28aada 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -308,6 +308,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -327,7 +328,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1

2 1

[PATCH OLK-5.10] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24

From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index e96436e11a36..34becd87b9c4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -308,6 +308,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -327,7 +328,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1

2 1

[PATCH OLK-6.6] ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
by Wang Zhaolong 16 Jul '24

16 Jul '24

From: Joseph Qi <joseph.qi(a)linux.alibaba.com> stable inclusion from stable-v6.6.36 commit 0550ad87711f815b3d73e487ec58ca7d8f56edbc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSVC CVE: CVE-2024-40952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 58f7e1e2c9e72c7974054c64c3abeac81c11f822 upstream. bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the following NULL pointer dereference in ocfs2_journal_dirty() since b_assoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits. [ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [ 134.366265] ? __pfx_bit_wait_io+0x10/0x10 [ 134.366659] ? schedule+0x27/0xb0 [ 134.366981] ? exc_page_fault+0x6a/0x140 [ 134.367356] ? asm_exc_page_fault+0x26/0x30 [ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2] [ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2] [ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2] [ 134.372994] ? inode_update_timestamps+0x4a/0x120 [ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2] [ 134.376971] ? security_file_permission+0x29/0x50 [ 134.377644] vfs_clone_file_range+0xfe/0x320 [ 134.378268] ioctl_file_clone+0x45/0xa0 [ 134.378853] do_vfs_ioctl+0x457/0x990 [ 134.379422] __x64_sys_ioctl+0x6e/0xd0 [ 134.379987] do_syscall_64+0x5d/0x170 [ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] </TASK> Fix it by only aborting transaction and journal in ocfs2_journal_dirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case. Link: https://lkml.kernel.org/r/20240530110630.3933832-1-joseph.qi@linux.alibaba.… Fixes: 8887b94d9322 ("ocfs2: stop using bdev->bd_super for journal error logging") Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reviewed-by: Heming Zhao <heming.zhao(a)suse.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/ocfs2/journal.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c index ce215565d061..d4fa52cbb33f 100644 --- a/fs/ocfs2/journal.c +++ b/fs/ocfs2/journal.c @@ -778,13 +778,15 @@ void ocfs2_journal_dirty(handle_t *handle, struct buffer_head *bh) if (!is_handle_aborted(handle)) { journal_t *journal = handle->h_transaction->t_journal; - mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed. " - "Aborting transaction and journal.\n"); + mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed: " + "handle type %u started at line %u, credits %u/%u " + "errcode %d. Aborting transaction and journal.\n", + handle->h_type, handle->h_line_no, + handle->h_requested_credits, + jbd2_handle_buffer_credits(handle), status); handle->h_err = status; jbd2_journal_abort_handle(handle); jbd2_journal_abort(journal, status); - ocfs2_abort(bh->b_assoc_map->host->i_sb, - "Journal already aborted.\n"); } } } -- 2.34.3

2 1

[PATCH OLK-6.6] liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
by Liu Jian 16 Jul '24

16 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.35 commit fd2b613bc4c508e55c1221c6595bb889812a4fea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW2 CVE: CVE-2024-39506 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ] In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c index 600de587d7a9..e70b9ccca380 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c @@ -272,13 +272,12 @@ lio_vf_rep_copy_packet(struct octeon_device *oct, pg_info->page_offset; memcpy(skb->data, va, MIN_SKB_SIZE); skb_put(skb, MIN_SKB_SIZE); + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + pg_info->page, + pg_info->page_offset + MIN_SKB_SIZE, + len - MIN_SKB_SIZE, + LIO_RXBUFFER_SZ); } - - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, - pg_info->page, - pg_info->page_offset + MIN_SKB_SIZE, - len - MIN_SKB_SIZE, - LIO_RXBUFFER_SZ); } else { struct octeon_skb_page_info *pg_info = ((struct octeon_skb_page_info *)(skb->cb)); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24

From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index 19697c1362d8..362400eaa688 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -302,6 +302,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -321,7 +322,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1

2 1

[PATCH OLK-6.6] cachefiles: flush all requests after setting CACHEFILES_DEAD
by Long Li 16 Jul '24

16 Jul '24

From: Baokun Li <libaokun1(a)huawei.com> mainline inclusion from mainline-v6.9-rc3 commit 85e833cd7243bda7285492b0653c3abb1e2e757b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZXJ CVE: CVE-2024-40935 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ondemand mode, when the daemon is processing an open request, if the kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write() will always return -EIO, so the daemon can't pass the copen to the kernel. Then the kernel process that is waiting for the copen triggers a hung_task. Since the DEAD state is irreversible, it can only be exited by closing /dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to avoid the above hungtask. We may still be able to read some of the cached data before closing the fd of /dev/cachefiles. Note that this relies on the patch that adds reference counting to the req, otherwise it may UAF. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240522114308.2402121-12-libaokun@huaweicloud.com Acked-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/cachefiles/daemon.c | 2 +- fs/cachefiles/internal.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 5f4df9588620..9072abfc154c 100644 --- a/fs/cachefiles/daemon.c +++ b/fs/cachefiles/daemon.c @@ -132,7 +132,7 @@ static int cachefiles_daemon_open(struct inode *inode, struct file *file) return 0; } -static void cachefiles_flush_reqs(struct cachefiles_cache *cache) +void cachefiles_flush_reqs(struct cachefiles_cache *cache) { struct xarray *xa = &cache->reqs; struct cachefiles_req *req; diff --git a/fs/cachefiles/internal.h b/fs/cachefiles/internal.h index 2ad58c465208..e0a15150ed89 100644 --- a/fs/cachefiles/internal.h +++ b/fs/cachefiles/internal.h @@ -173,6 +173,7 @@ extern int cachefiles_has_space(struct cachefiles_cache *cache, * daemon.c */ extern const struct file_operations cachefiles_daemon_fops; +extern void cachefiles_flush_reqs(struct cachefiles_cache *cache); extern void cachefiles_get_unbind_pincount(struct cachefiles_cache *cache); extern void cachefiles_put_unbind_pincount(struct cachefiles_cache *cache); @@ -367,6 +368,8 @@ do { \ pr_err("I/O Error: " FMT"\n", ##__VA_ARGS__); \ fscache_io_error((___cache)->cache); \ set_bit(CACHEFILES_DEAD, &(___cache)->flags); \ + if (cachefiles_in_ondemand_mode(___cache)) \ + cachefiles_flush_reqs(___cache); \ } while (0) #define cachefiles_io_error_obj(object, FMT, ...) \ -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24

Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3

2 6

[PATCH OLK-6.6] xfs: fix mount hung while sb recover fail
by Long Li 16 Jul '24

16 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAC63K CVE: NA -------------------------------- When I mount a corrupt xfs image, mount process hang all the time, the stack as follows: [root@testvm ~]# cat /proc/425/stack [<0>] xfs_wait_buftarg+0x5a/0x360 [<0>] xfs_mountfs+0x591/0xc90 [<0>] xfs_fc_fill_super+0x792/0xc80 [<0>] get_tree_bdev+0x1ec/0x3a0 [<0>] xfs_fc_get_tree+0x19/0x30 [<0>] vfs_get_tree+0x2f/0x110 [<0>] path_mount+0x8ab/0x1150 [<0>] do_mount+0x91/0xc0 [<0>] __se_sys_mount+0x14a/0x220 [<0>] __x64_sys_mount+0x29/0x40 [<0>] do_syscall_64+0x6c/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x62/0xc7 During buffer recovery, if the superblock buffer is modified, we also need to update the content of the mount point (mp). In this situation, if we encounter an error, we will go to out_release and release the xfs_buf. However, this is not enough because the xfs_buf's log item has been initialized and is held by the buffer log item in xlog_recover_do_reg_buffer(). Fixing this issue is straightforward: we need to set the error and add the xfs_buf to the buffer_list in such situations. This allows it to be handled by the normal buffer write process. The filesystem will be shut down before submission in xlog_do_recovery_pass() because the log recovery encountered an error. As a result, the xfs_buf will be released correctly. Fixes: 6fb62b3ffacb ("xfs: fix the problem of mount failure caused by not refreshing mp->m_sb") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index 2383cc2d0354..f78476180bb7 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -980,7 +980,7 @@ xlog_recover_buf_commit_pass2( bp->b_ops->verify_write(bp); error = bp->b_error; if (error) - goto out_release; + goto out_writebuf; if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { error = xfs_initialize_perag(mp, @@ -988,13 +988,14 @@ xlog_recover_buf_commit_pass2( be64_to_cpu(sb->sb_dblocks), &mp->m_maxagi); if (error) - goto out_release; + goto out_writebuf; } xfs_sb_from_disk(&mp->m_sb, sb); } } +out_writebuf: /* * Perform delayed write on the buffer. Asynchronous writes will be * slower when taking into account all the buffers to be flushed. -- 2.31.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-5.10] xfs: fix mount hung while sb recover fail
by Long Li 16 Jul '24

16 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAC63K CVE: NA -------------------------------- When I mount a corrupt xfs image, mount process hang all the time, the stack as follows: [root@testvm ~]# cat /proc/425/stack [<0>] xfs_wait_buftarg+0x5a/0x360 [<0>] xfs_mountfs+0x591/0xc90 [<0>] xfs_fc_fill_super+0x792/0xc80 [<0>] get_tree_bdev+0x1ec/0x3a0 [<0>] xfs_fc_get_tree+0x19/0x30 [<0>] vfs_get_tree+0x2f/0x110 [<0>] path_mount+0x8ab/0x1150 [<0>] do_mount+0x91/0xc0 [<0>] __se_sys_mount+0x14a/0x220 [<0>] __x64_sys_mount+0x29/0x40 [<0>] do_syscall_64+0x6c/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x62/0xc7 During buffer recovery, if the superblock buffer is modified, we also need to update the content of the mount point (mp). In this situation, if we encounter an error, we will go to out_release and release the xfs_buf. However, this is not enough because the xfs_buf's log item has been initialized and is held by the buffer log item in xlog_recover_do_reg_buffer(). Fixing this issue is straightforward: we need to set the error and add the xfs_buf to the buffer_list in such situations. This allows it to be handled by the normal buffer write process. The filesystem will be shut down before submission in xlog_do_recovery_pass() because the log recovery encountered an error. As a result, the xfs_buf will be released correctly. Fixes: 2f77072a09fe ("xfs: fix the problem of mount failure caused by not refreshing mp->m_sb") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index d214e0f9cc09..eb75a953b09e 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -980,20 +980,21 @@ xlog_recover_buf_commit_pass2( bp->b_ops->verify_write(bp); error = bp->b_error; if (error) - goto out_release; + goto out_writebuf; if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { error = xfs_initialize_perag(mp, be32_to_cpu(sb->sb_agcount), &mp->m_maxagi); if (error) - goto out_release; + goto out_writebuf; } xfs_sb_from_disk(&mp->m_sb, sb); } } +out_writebuf: /* * Perform delayed write on the buffer. Asynchronous writes will be * slower when taking into account all the buffers to be flushed. -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] xfs: fix mount hung while sb recover fail
by Long Li 16 Jul '24

16 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAC63K CVE: NA -------------------------------- When I mount a corrupt xfs image, mount process hang all the time, the stack as follows: [root@testvm ~]# cat /proc/425/stack [<0>] xfs_wait_buftarg+0x5a/0x360 [<0>] xfs_mountfs+0x591/0xc90 [<0>] xfs_fc_fill_super+0x792/0xc80 [<0>] get_tree_bdev+0x1ec/0x3a0 [<0>] xfs_fc_get_tree+0x19/0x30 [<0>] vfs_get_tree+0x2f/0x110 [<0>] path_mount+0x8ab/0x1150 [<0>] do_mount+0x91/0xc0 [<0>] __se_sys_mount+0x14a/0x220 [<0>] __x64_sys_mount+0x29/0x40 [<0>] do_syscall_64+0x6c/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x62/0xc7 During buffer recovery, if the superblock buffer is modified, we also need to update the content of the mount point (mp). In this situation, if we encounter an error, we will go to out_release and release the xfs_buf. However, this is not enough because the xfs_buf's log item has been initialized and is held by the buffer log item in xlog_recover_do_reg_buffer(). Fixing this issue is straightforward: we need to set the error and add the xfs_buf to the buffer_list in such situations. This allows it to be handled by the normal buffer write process. The filesystem will be shut down before submission in xlog_do_recovery_pass() because the log recovery encountered an error. As a result, the xfs_buf will be released correctly. Fixes: 6d75903f5153 ("xfs: fix the problem of mount failure caused by not refreshing mp->m_sb") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index d214e0f9cc09..eb75a953b09e 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -980,20 +980,21 @@ xlog_recover_buf_commit_pass2( bp->b_ops->verify_write(bp); error = bp->b_error; if (error) - goto out_release; + goto out_writebuf; if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { error = xfs_initialize_perag(mp, be32_to_cpu(sb->sb_agcount), &mp->m_maxagi); if (error) - goto out_release; + goto out_writebuf; } xfs_sb_from_disk(&mp->m_sb, sb); } } +out_writebuf: /* * Perform delayed write on the buffer. Asynchronous writes will be * slower when taking into account all the buffers to be flushed. -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c [yyl: The directory is renamed from amdgpu to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c index f046348362e3..a01976fac9bd 100644 --- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c +++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c @@ -163,6 +163,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, u32 i, j; for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; if (table[i].ulSupportedSCLK != 0) { vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; -- 2.25.1

2 1

[PATCH OLK-6.6] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c index 5cb4725c773f..c8586cb7d0fe 100644 --- a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c @@ -164,6 +164,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-6.6] seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Jianguo Wu <wujianguo(a)chinatelecom.cn> stable inclusion from stable-v6.6.36 commit d62df86c172033679d744f07d89e93e367dd11f6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYG CVE: CVE-2024-40957 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 9a3bc8d16e0aacd65c31aaf23a2bced3288a7779 ] input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for PREROUTING hook, in PREROUTING hook, we should passing a valid indev, and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer dereference, as below: [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090 [74830.655633] #PF: supervisor read access in kernel mode [74830.657888] #PF: error_code(0x0000) - not-present page [74830.659500] PGD 0 P4D 0 [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI ... [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter] ... [74830.689725] Call Trace: [74830.690402] <IRQ> [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables] [74830.694275] ? __die_body.cold+0x8/0xd [74830.695205] ? page_fault_oops+0xac/0x140 [74830.696244] ? exc_page_fault+0x62/0x150 [74830.697225] ? asm_exc_page_fault+0x22/0x30 [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter] [74830.699540] ipt_do_table+0x286/0x710 [ip_tables] [74830.700758] ? ip6_route_input+0x19d/0x240 [74830.701752] nf_hook_slow+0x3f/0xb0 [74830.702678] input_action_end_dx4+0x19b/0x1e0 [74830.703735] ? input_action_end_t+0xe0/0xe0 [74830.704734] seg6_local_input_core+0x2d/0x60 [74830.705782] lwtunnel_input+0x5b/0xb0 [74830.706690] __netif_receive_skb_one_core+0x63/0xa0 [74830.707825] process_backlog+0x99/0x140 [74830.709538] __napi_poll+0x2c/0x160 [74830.710673] net_rx_action+0x296/0x350 [74830.711860] __do_softirq+0xcb/0x2ac [74830.713049] do_softirq+0x63/0x90 input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback(): static bool rpfilter_is_loopback(const struct sk_buff *skb, const struct net_device *in) { // in is NULL return skb->pkt_type == PACKET_LOOPBACK || in->flags & IFF_LOOPBACK; } Fixes: 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane") Signed-off-by: Jianguo Wu <wujianguo(a)chinatelecom.cn> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/seg6_local.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c index 24e2b4b494cb..c434940131b1 100644 --- a/net/ipv6/seg6_local.c +++ b/net/ipv6/seg6_local.c @@ -941,8 +941,8 @@ static int input_action_end_dx6(struct sk_buff *skb, if (static_branch_unlikely(&nf_hooks_lwtunnel_enabled)) return NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING, - dev_net(skb->dev), NULL, skb, NULL, - skb_dst(skb)->dev, input_action_end_dx6_finish); + dev_net(skb->dev), NULL, skb, skb->dev, + NULL, input_action_end_dx6_finish); return input_action_end_dx6_finish(dev_net(skb->dev), NULL, skb); drop: @@ -991,8 +991,8 @@ static int input_action_end_dx4(struct sk_buff *skb, if (static_branch_unlikely(&nf_hooks_lwtunnel_enabled)) return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING, - dev_net(skb->dev), NULL, skb, NULL, - skb_dst(skb)->dev, input_action_end_dx4_finish); + dev_net(skb->dev), NULL, skb, skb->dev, + NULL, input_action_end_dx4_finish); return input_action_end_dx4_finish(dev_net(skb->dev), NULL, skb); drop: -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c [yyl: The directory is renamed from powerplay to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c index 6eb6f05c1136..9e3bb5a622c3 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c +++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c @@ -162,6 +162,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, u32 i, j; for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; if (table[i].ulSupportedSCLK != 0) { vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; -- 2.25.1

2 1

[PATCH OLK-5.10] drm/amdgpu: fix UBSAN warning in kv_dpm.c
by Yang Yingliang 16 Jul '24

16 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.10-rc5 commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQY7 CVE: CVE-2024-40987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Adds bounds check for sumo_vid_mapping_entry. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392 Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c [yyl: The directory is renamed from powerplay to legacy-dpm in mainline] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c index 6eb6f05c1136..9e3bb5a622c3 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c +++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c @@ -162,6 +162,8 @@ static void sumo_construct_vid_mapping_table(struct amdgpu_device *adev, u32 i, j; for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; if (table[i].ulSupportedSCLK != 0) { vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; -- 2.25.1

2 1

[PATCH OLK-5.10] xfs: fix mount hung while sb recover fail
by Long Li 16 Jul '24

16 Jul '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAC63K CVE: NA -------------------------------- When I mount a corrupt xfs image, mount process hang all the time, the stack as follows: [root@testvm ~]# cat /proc/425/stack [<0>] xfs_wait_buftarg+0x5a/0x360 [<0>] xfs_mountfs+0x591/0xc90 [<0>] xfs_fc_fill_super+0x792/0xc80 [<0>] get_tree_bdev+0x1ec/0x3a0 [<0>] xfs_fc_get_tree+0x19/0x30 [<0>] vfs_get_tree+0x2f/0x110 [<0>] path_mount+0x8ab/0x1150 [<0>] do_mount+0x91/0xc0 [<0>] __se_sys_mount+0x14a/0x220 [<0>] __x64_sys_mount+0x29/0x40 [<0>] do_syscall_64+0x6c/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x62/0xc7 During buffer recovery, if the superblock buffer is modified, we also need to update the content of the mount point (mp). In this situation, if we encounter an error, we will go to out_release and release the xfs_buf. However, this is not enough because the xfs_buf's log item has been initialized and is held by the buffer log item in xlog_recover_do_reg_buffer(). Fixing this issue is straightforward: we need to set the error and add the xfs_buf to the buffer_list in such situations. This allows it to be handled by the normal buffer write process. The filesystem will be shut down before submission in xlog_do_recovery_pass() because the log recovery encountered an error. As a result, the xfs_buf will be released correctly. Fixes: 2f77072a09fe ("xfs: fix the problem of mount failure caused by not refreshing mp->m_sb") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index d214e0f9cc09..eb75a953b09e 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -980,20 +980,21 @@ xlog_recover_buf_commit_pass2( bp->b_ops->verify_write(bp); error = bp->b_error; if (error) - goto out_release; + goto out_writebuf; if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { error = xfs_initialize_perag(mp, be32_to_cpu(sb->sb_agcount), &mp->m_maxagi); if (error) - goto out_release; + goto out_writebuf; } xfs_sb_from_disk(&mp->m_sb, sb); } } +out_writebuf: /* * Perform delayed write on the buffer. Asynchronous writes will be * slower when taking into account all the buffers to be flushed. -- 2.31.1

2 1

[PATCH OLK-6.6] tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
by Cui GaoSheng 16 Jul '24

16 Jul '24

From: Daniel Starke <daniel.starke(a)siemens.com> stable inclusion from stable-v6.6.33 commit 774d83b008eccb1c48c14dc5486e7aa255731350 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TAHR CVE: CVE-2024-36016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream. Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Reported-by: j51569436(a)gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708 Tested-by: j51569436(a)gmail.com Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke(a)siemens.com> Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/tty/n_gsm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 0ee7531c9201..f8858865c5bb 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2912,7 +2912,10 @@ static void gsm0_receive(struct gsm_mux *gsm, unsigned char c) break; case GSM_DATA: /* Data */ gsm->buf[gsm->count++] = c; - if (gsm->count == gsm->len) { + if (gsm->count >= MAX_MRU) { + gsm->bad_size++; + gsm->state = GSM_SEARCH; + } else if (gsm->count >= gsm->len) { /* Calculate final FCS for UI frames over all data */ if ((gsm->control & ~PF) != UIH) { gsm->fcs = gsm_fcs_add_block(gsm->fcs, gsm->buf, @@ -3025,7 +3028,7 @@ static void gsm1_receive(struct gsm_mux *gsm, unsigned char c) gsm->state = GSM_DATA; break; case GSM_DATA: /* Data */ - if (gsm->count > gsm->mru) { /* Allow one for the FCS */ + if (gsm->count > gsm->mru || gsm->count > MAX_MRU) { /* Allow one for the FCS */ gsm->state = GSM_OVERRUN; gsm->bad_size++; } else -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH OLK-5.10 0/5] Fix CVE-2024-36939
by Wang Zhaolong 16 Jul '24

16 Jul '24

Josef Bacik (3): sunrpc: add a struct rpc_stats arg to rpc_create_args nfs: expose /proc/net/sunrpc/nfs in net namespaces nfs: make the rpc_stat per net namespace Kuniyuki Iwashima (1): nfs: Handle error of rpc_proc_register() in nfs_net_init(). Wang Zhaolong (1): sunrpc: fix KABI broken in struct rpc_create_args fs/nfs/client.c | 5 ++++- fs/nfs/inode.c | 13 +++++++++---- fs/nfs/internal.h | 2 -- fs/nfs/netns.h | 2 ++ include/linux/sunrpc/clnt.h | 2 +- net/sunrpc/clnt.c | 5 ++++- 6 files changed, 20 insertions(+), 9 deletions(-) -- 2.34.3

2 6

[PATCH OLK-6.6] ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup
by Cui GaoSheng 16 Jul '24

16 Jul '24

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> stable inclusion from stable-v6.6.33 commit 6e359be4975006ff72818e79dad8fe48293f2eb2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D1H CVE: CVE-2024-38388 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 172811e3a557d8681a5e2d0f871dc04a2d17eb13 ] Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls") Link: https://lore.kernel.org/r/20240508095627.44476-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- sound/pci/hda/hda_cs_dsp_ctl.c | 47 ++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 16 deletions(-) diff --git a/sound/pci/hda/hda_cs_dsp_ctl.c b/sound/pci/hda/hda_cs_dsp_ctl.c index 463ca06036bf..9db45d7c17e5 100644 --- a/sound/pci/hda/hda_cs_dsp_ctl.c +++ b/sound/pci/hda/hda_cs_dsp_ctl.c @@ -8,6 +8,7 @@ #include <linux/module.h> #include <sound/soc.h> +#include <linux/cleanup.h> #include <linux/firmware/cirrus/cs_dsp.h> #include <linux/firmware/cirrus/wmfw.h> #include "hda_cs_dsp_ctl.h" @@ -97,11 +98,23 @@ static unsigned int wmfw_convert_flags(unsigned int in) return out; } -static void hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl, const char *name) +static void hda_cs_dsp_free_kcontrol(struct snd_kcontrol *kctl) { + struct hda_cs_dsp_coeff_ctl *ctl = (struct hda_cs_dsp_coeff_ctl *)snd_kcontrol_chip(kctl); struct cs_dsp_coeff_ctl *cs_ctl = ctl->cs_ctl; + + /* NULL priv to prevent a double-free in hda_cs_dsp_control_remove() */ + cs_ctl->priv = NULL; + kfree(ctl); +} + +static void hda_cs_dsp_add_kcontrol(struct cs_dsp_coeff_ctl *cs_ctl, + const struct hda_cs_dsp_ctl_info *info, + const char *name) +{ struct snd_kcontrol_new kcontrol = {0}; struct snd_kcontrol *kctl; + struct hda_cs_dsp_coeff_ctl *ctl __free(kfree) = NULL; int ret = 0; if (cs_ctl->len > ADSP_MAX_STD_CTRL_SIZE) { @@ -110,6 +123,13 @@ static void hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl, const char return; } + ctl = kzalloc(sizeof(*ctl), GFP_KERNEL); + if (!ctl) + return; + + ctl->cs_ctl = cs_ctl; + ctl->card = info->card; + kcontrol.name = name; kcontrol.info = hda_cs_dsp_coeff_info; kcontrol.iface = SNDRV_CTL_ELEM_IFACE_MIXER; @@ -117,20 +137,22 @@ static void hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl, const char kcontrol.get = hda_cs_dsp_coeff_get; kcontrol.put = hda_cs_dsp_coeff_put; - /* Save ctl inside private_data, ctl is owned by cs_dsp, - * and will be freed when cs_dsp removes the control */ kctl = snd_ctl_new1(&kcontrol, (void *)ctl); if (!kctl) return; - ret = snd_ctl_add(ctl->card, kctl); + kctl->private_free = hda_cs_dsp_free_kcontrol; + ctl->kctl = kctl; + + /* snd_ctl_add() calls our private_free on error, which will kfree(ctl) */ + cs_ctl->priv = no_free_ptr(ctl); + ret = snd_ctl_add(info->card, kctl); if (ret) { dev_err(cs_ctl->dsp->dev, "Failed to add KControl %s = %d\n", kcontrol.name, ret); return; } dev_dbg(cs_ctl->dsp->dev, "Added KControl: %s\n", kcontrol.name); - ctl->kctl = kctl; } static void hda_cs_dsp_control_add(struct cs_dsp_coeff_ctl *cs_ctl, @@ -138,7 +160,6 @@ static void hda_cs_dsp_control_add(struct cs_dsp_coeff_ctl *cs_ctl, { struct cs_dsp *cs_dsp = cs_ctl->dsp; char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN]; - struct hda_cs_dsp_coeff_ctl *ctl; const char *region_name; int ret; @@ -163,15 +184,7 @@ static void hda_cs_dsp_control_add(struct cs_dsp_coeff_ctl *cs_ctl, " %.*s", cs_ctl->subname_len - skip, cs_ctl->subname + skip); } - ctl = kzalloc(sizeof(*ctl), GFP_KERNEL); - if (!ctl) - return; - - ctl->cs_ctl = cs_ctl; - ctl->card = info->card; - cs_ctl->priv = ctl; - - hda_cs_dsp_add_kcontrol(ctl, name); + hda_cs_dsp_add_kcontrol(cs_ctl, info, name); } void hda_cs_dsp_add_controls(struct cs_dsp *dsp, const struct hda_cs_dsp_ctl_info *info) @@ -203,7 +216,9 @@ void hda_cs_dsp_control_remove(struct cs_dsp_coeff_ctl *cs_ctl) { struct hda_cs_dsp_coeff_ctl *ctl = cs_ctl->priv; - kfree(ctl); + /* ctl and kctl may already have been removed by ALSA private_free */ + if (ctl && ctl->kctl) + snd_ctl_remove(ctl->card, ctl->kctl); } EXPORT_SYMBOL_NS_GPL(hda_cs_dsp_control_remove, SND_HDA_CS_DSP_CONTROLS); -- 2.34.1

2 1

[PATCH OLK-6.6] openrisc: traps: Don't send signals to kernel mode threads
by Cui GaoSheng 16 Jul '24

16 Jul '24

From: Stafford Horne <shorne(a)gmail.com> stable inclusion from stable-v6.6.33 commit c0ed9a711e3392d73e857faa031d8d349c0d70db category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH4 CVE: CVE-2024-38614 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f ] OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code. Fixes: 27267655c531 ("openrisc: Support floating point user api") Signed-off-by: Stafford Horne <shorne(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- arch/openrisc/kernel/traps.c | 48 ++++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c index 9370888c9a7e..90554a5558fb 100644 --- a/arch/openrisc/kernel/traps.c +++ b/arch/openrisc/kernel/traps.c @@ -180,29 +180,39 @@ asmlinkage void unhandled_exception(struct pt_regs *regs, int ea, int vector) asmlinkage void do_fpe_trap(struct pt_regs *regs, unsigned long address) { - int code = FPE_FLTUNK; - unsigned long fpcsr = regs->fpcsr; - - if (fpcsr & SPR_FPCSR_IVF) - code = FPE_FLTINV; - else if (fpcsr & SPR_FPCSR_OVF) - code = FPE_FLTOVF; - else if (fpcsr & SPR_FPCSR_UNF) - code = FPE_FLTUND; - else if (fpcsr & SPR_FPCSR_DZF) - code = FPE_FLTDIV; - else if (fpcsr & SPR_FPCSR_IXF) - code = FPE_FLTRES; - - /* Clear all flags */ - regs->fpcsr &= ~SPR_FPCSR_ALLF; - - force_sig_fault(SIGFPE, code, (void __user *)regs->pc); + if (user_mode(regs)) { + int code = FPE_FLTUNK; + unsigned long fpcsr = regs->fpcsr; + + if (fpcsr & SPR_FPCSR_IVF) + code = FPE_FLTINV; + else if (fpcsr & SPR_FPCSR_OVF) + code = FPE_FLTOVF; + else if (fpcsr & SPR_FPCSR_UNF) + code = FPE_FLTUND; + else if (fpcsr & SPR_FPCSR_DZF) + code = FPE_FLTDIV; + else if (fpcsr & SPR_FPCSR_IXF) + code = FPE_FLTRES; + + /* Clear all flags */ + regs->fpcsr &= ~SPR_FPCSR_ALLF; + + force_sig_fault(SIGFPE, code, (void __user *)regs->pc); + } else { + pr_emerg("KERNEL: Illegal fpe exception 0x%.8lx\n", regs->pc); + die("Die:", regs, SIGFPE); + } } asmlinkage void do_trap(struct pt_regs *regs, unsigned long address) { - force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->pc); + if (user_mode(regs)) { + force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->pc); + } else { + pr_emerg("KERNEL: Illegal trap exception 0x%.8lx\n", regs->pc); + die("Die:", regs, SIGILL); + } } asmlinkage void do_unaligned_access(struct pt_regs *regs, unsigned long address) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] netpoll: Fix race condition in netpoll_owner_active
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.10-rc1 commit c2e6a872bde9912f1a7579639c5ca3adf1003916 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1O CVE: CVE-2024-41005 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240429100437.3487432-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/core/netpoll.c [The conflict occurs because the commit 5251ef829932("net: make sure napi_list is safe for RCU traversal") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/core/netpoll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index b23c32ed6773..f1a830550e0c 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -315,7 +315,7 @@ static int netpoll_owner_active(struct net_device *dev) struct napi_struct *napi; list_for_each_entry(napi, &dev->napi_list, dev_list) { - if (napi->poll_owner == smp_processor_id()) + if (READ_ONCE(napi->poll_owner) == smp_processor_id()) return 1; } return 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] Bluetooth: btusb: Add date->evt_skb is NULL check
by Yuan Can 16 Jul '24

16 Jul '24

From: youwan Wang <wangyouwan(a)126.com> mainline inclusion from mainline-v6.7-rc1 commit 624820f7c8826dd010e8b1963303c145f99816e9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFI9 CVE: CVE-2023-52833 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 624820f7c8826dd010e8b1963303c145f99816e9 ] fix crash because of null pointers [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0 Signed-off-by: youwan Wang <wangyouwan(a)126.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/bluetooth/btusb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 6efd981979bd..7e6c96b1dea5 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3083,6 +3083,9 @@ static int btusb_mtk_hci_wmt_sync(struct hci_dev *hdev, goto err_free_wc; } + if (data->evt_skb == NULL) + goto err_free_wc; + /* Parse and handle the return WMT event */ wmt_evt = (struct btmtk_hci_wmt_evt *)data->evt_skb->data; if (wmt_evt->whdr.op != hdr->op) { -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
by Yifan Qiao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.35 commit ab702c3483db9046bab9f40306f1a28b22dbbdc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2Y CVE: CVE-2024-39508 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8a565304927fbd28c9f028c492b5c1714002cbab ] Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) <snip> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) <snip> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags. Also, move `create_index` to avoid holes in the structure. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240507170002.2269003-1-leitao@debian.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Stable-dep-of: 91215f70ea85 ("io_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: io_uring/io-wq.c [The function names are different than cve commit. But their basic functions are same and they are using the io_worker in the same way.] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- io_uring/io-wq.c | 47 ++++++++++++++++++++++++----------------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c index 6031fb319d87..cc31ebf3a1d5 100644 --- a/io_uring/io-wq.c +++ b/io_uring/io-wq.c @@ -21,10 +21,10 @@ #define WORKER_IDLE_TIMEOUT (5 * HZ) enum { - IO_WORKER_F_UP = 1, /* up and active */ - IO_WORKER_F_RUNNING = 2, /* account as running */ - IO_WORKER_F_FREE = 4, /* worker on free list */ - IO_WORKER_F_BOUND = 8, /* is doing bounded work */ + IO_WORKER_F_UP = 0, /* up and active */ + IO_WORKER_F_RUNNING = 1, /* account as running */ + IO_WORKER_F_FREE = 2, /* worker on free list */ + IO_WORKER_F_BOUND = 3, /* is doing bounded work */ }; enum { @@ -40,7 +40,8 @@ enum { */ struct io_worker { refcount_t ref; - unsigned flags; + int create_index; + unsigned long flags; struct hlist_nulls_node nulls_node; struct list_head all_list; struct task_struct *task; @@ -53,7 +54,6 @@ struct io_worker { unsigned long create_state; struct callback_head create_work; - int create_index; union { struct rcu_head rcu; @@ -167,7 +167,7 @@ static inline struct io_wqe_acct *io_work_get_acct(struct io_wqe *wqe, static inline struct io_wqe_acct *io_wqe_get_acct(struct io_worker *worker) { - return io_get_acct(worker->wqe, worker->flags & IO_WORKER_F_BOUND); + return io_get_acct(worker->wqe, test_bit(IO_WORKER_F_BOUND, &worker->flags)); } static void io_worker_ref_put(struct io_wq *wq) @@ -220,7 +220,7 @@ static void io_worker_exit(struct io_worker *worker) wait_for_completion(&worker->ref_done); raw_spin_lock(&wqe->lock); - if (worker->flags & IO_WORKER_F_FREE) + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) hlist_nulls_del_rcu(&worker->nulls_node); list_del_rcu(&worker->all_list); preempt_disable(); @@ -389,7 +389,7 @@ static void io_wqe_dec_running(struct io_worker *worker) struct io_wqe_acct *acct = io_wqe_get_acct(worker); struct io_wqe *wqe = worker->wqe; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; if (atomic_dec_and_test(&acct->nr_running) && io_acct_run_queue(acct)) { @@ -409,8 +409,8 @@ static void __io_worker_busy(struct io_wqe *wqe, struct io_worker *worker, struct io_wq_work *work) __must_hold(wqe->lock) { - if (worker->flags & IO_WORKER_F_FREE) { - worker->flags &= ~IO_WORKER_F_FREE; + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) { + clear_bit(IO_WORKER_F_FREE, &worker->flags); hlist_nulls_del_init_rcu(&worker->nulls_node); } } @@ -425,8 +425,8 @@ static void __io_worker_busy(struct io_wqe *wqe, struct io_worker *worker, static void __io_worker_idle(struct io_wqe *wqe, struct io_worker *worker) __must_hold(wqe->lock) { - if (!(worker->flags & IO_WORKER_F_FREE)) { - worker->flags |= IO_WORKER_F_FREE; + if (!test_bit(IO_WORKER_F_FREE, &worker->flags)) { + set_bit(IO_WORKER_F_FREE, &worker->flags); hlist_nulls_add_head_rcu(&worker->nulls_node, &wqe->free_list); } } @@ -615,7 +615,8 @@ static int io_wqe_worker(void *data) bool last_timeout = false; char buf[TASK_COMM_LEN]; - worker->flags |= (IO_WORKER_F_UP | IO_WORKER_F_RUNNING); + set_mask_bits(&worker->flags, 0, + BIT(IO_WORKER_F_UP) | BIT(IO_WORKER_F_RUNNING)); snprintf(buf, sizeof(buf), "iou-wrk-%d", wq->task->pid); set_task_comm(current, buf); @@ -671,11 +672,11 @@ void io_wq_worker_running(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (worker->flags & IO_WORKER_F_RUNNING) + if (test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags |= IO_WORKER_F_RUNNING; + set_bit(IO_WORKER_F_RUNNING, &worker->flags); io_wqe_inc_running(worker); } @@ -689,12 +690,12 @@ void io_wq_worker_sleeping(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (!(worker->flags & IO_WORKER_F_RUNNING)) + if (!test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags &= ~IO_WORKER_F_RUNNING; + clear_bit(IO_WORKER_F_RUNNING, &worker->flags); raw_spin_lock(&worker->wqe->lock); io_wqe_dec_running(worker); @@ -712,7 +713,7 @@ static void io_init_new_worker(struct io_wqe *wqe, struct io_worker *worker, raw_spin_lock(&wqe->lock); hlist_nulls_add_head_rcu(&worker->nulls_node, &wqe->free_list); list_add_tail_rcu(&worker->all_list, &wqe->all_list); - worker->flags |= IO_WORKER_F_FREE; + set_bit(IO_WORKER_F_FREE, &worker->flags); raw_spin_unlock(&wqe->lock); wake_up_new_task(tsk); } @@ -816,7 +817,7 @@ static bool create_io_worker(struct io_wq *wq, struct io_wqe *wqe, int index) init_completion(&worker->ref_done); if (index == IO_WQ_ACCT_BOUND) - worker->flags |= IO_WORKER_F_BOUND; + set_bit(IO_WORKER_F_BOUND, &worker->flags); tsk = create_io_thread(io_wqe_worker, worker, wqe->node); if (!IS_ERR(tsk)) { @@ -904,7 +905,7 @@ static bool io_wq_work_match_item(struct io_wq_work *work, void *data) static void io_wqe_enqueue(struct io_wqe *wqe, struct io_wq_work *work) { struct io_wqe_acct *acct = io_work_get_acct(wqe, work); - unsigned work_flags = work->flags; + unsigned long work_flags = work->flags; bool do_create; /* -- 2.39.2

2 1

[PATCH OLK-5.10] io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
by Yifan Qiao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.35 commit ab702c3483db9046bab9f40306f1a28b22dbbdc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2Y CVE: CVE-2024-39508 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8a565304927fbd28c9f028c492b5c1714002cbab ] Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) <snip> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) <snip> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags. Also, move `create_index` to avoid holes in the structure. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240507170002.2269003-1-leitao@debian.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Stable-dep-of: 91215f70ea85 ("io_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: io_uring/io-wq.c [The function names are different than cve commit. But their basic functions are same and they are using the io_worker in the same way.] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- io_uring/io-wq.c | 47 ++++++++++++++++++++++++----------------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c index fe8594a0396c..066f9ab708c6 100644 --- a/io_uring/io-wq.c +++ b/io_uring/io-wq.c @@ -21,10 +21,10 @@ #define WORKER_IDLE_TIMEOUT (5 * HZ) enum { - IO_WORKER_F_UP = 1, /* up and active */ - IO_WORKER_F_RUNNING = 2, /* account as running */ - IO_WORKER_F_FREE = 4, /* worker on free list */ - IO_WORKER_F_BOUND = 8, /* is doing bounded work */ + IO_WORKER_F_UP = 0, /* up and active */ + IO_WORKER_F_RUNNING = 1, /* account as running */ + IO_WORKER_F_FREE = 2, /* worker on free list */ + IO_WORKER_F_BOUND = 3, /* is doing bounded work */ }; enum { @@ -40,7 +40,8 @@ enum { */ struct io_worker { refcount_t ref; - unsigned flags; + int create_index; + unsigned long flags; struct hlist_nulls_node nulls_node; struct list_head all_list; struct task_struct *task; @@ -53,7 +54,6 @@ struct io_worker { unsigned long create_state; struct callback_head create_work; - int create_index; union { struct rcu_head rcu; @@ -167,7 +167,7 @@ static inline struct io_wqe_acct *io_work_get_acct(struct io_wqe *wqe, static inline struct io_wqe_acct *io_wqe_get_acct(struct io_worker *worker) { - return io_get_acct(worker->wqe, worker->flags & IO_WORKER_F_BOUND); + return io_get_acct(worker->wqe, test_bit(IO_WORKER_F_BOUND, &worker->flags)); } static void io_worker_ref_put(struct io_wq *wq) @@ -230,7 +230,7 @@ static void io_worker_exit(struct io_worker *worker) wait_for_completion(&worker->ref_done); raw_spin_lock(&wqe->lock); - if (worker->flags & IO_WORKER_F_FREE) + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) hlist_nulls_del_rcu(&worker->nulls_node); list_del_rcu(&worker->all_list); preempt_disable(); @@ -399,7 +399,7 @@ static void io_wqe_dec_running(struct io_worker *worker) struct io_wqe_acct *acct = io_wqe_get_acct(worker); struct io_wqe *wqe = worker->wqe; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; if (atomic_dec_and_test(&acct->nr_running) && io_acct_run_queue(acct)) { @@ -419,8 +419,8 @@ static void __io_worker_busy(struct io_wqe *wqe, struct io_worker *worker, struct io_wq_work *work) __must_hold(wqe->lock) { - if (worker->flags & IO_WORKER_F_FREE) { - worker->flags &= ~IO_WORKER_F_FREE; + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) { + clear_bit(IO_WORKER_F_FREE, &worker->flags); hlist_nulls_del_init_rcu(&worker->nulls_node); } } @@ -435,8 +435,8 @@ static void __io_worker_busy(struct io_wqe *wqe, struct io_worker *worker, static void __io_worker_idle(struct io_wqe *wqe, struct io_worker *worker) __must_hold(wqe->lock) { - if (!(worker->flags & IO_WORKER_F_FREE)) { - worker->flags |= IO_WORKER_F_FREE; + if (!test_bit(IO_WORKER_F_FREE, &worker->flags)) { + set_bit(IO_WORKER_F_FREE, &worker->flags); hlist_nulls_add_head_rcu(&worker->nulls_node, &wqe->free_list); } } @@ -625,7 +625,8 @@ static int io_wqe_worker(void *data) bool last_timeout = false; char buf[TASK_COMM_LEN]; - worker->flags |= (IO_WORKER_F_UP | IO_WORKER_F_RUNNING); + set_mask_bits(&worker->flags, 0, + BIT(IO_WORKER_F_UP) | BIT(IO_WORKER_F_RUNNING)); snprintf(buf, sizeof(buf), "iou-wrk-%d", wq->task->pid); set_task_comm(current, buf); @@ -681,11 +682,11 @@ void io_wq_worker_running(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (worker->flags & IO_WORKER_F_RUNNING) + if (test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags |= IO_WORKER_F_RUNNING; + set_bit(IO_WORKER_F_RUNNING, &worker->flags); io_wqe_inc_running(worker); } @@ -699,12 +700,12 @@ void io_wq_worker_sleeping(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (!(worker->flags & IO_WORKER_F_RUNNING)) + if (!test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags &= ~IO_WORKER_F_RUNNING; + clear_bit(IO_WORKER_F_RUNNING, &worker->flags); raw_spin_lock(&worker->wqe->lock); io_wqe_dec_running(worker); @@ -722,7 +723,7 @@ static void io_init_new_worker(struct io_wqe *wqe, struct io_worker *worker, raw_spin_lock(&wqe->lock); hlist_nulls_add_head_rcu(&worker->nulls_node, &wqe->free_list); list_add_tail_rcu(&worker->all_list, &wqe->all_list); - worker->flags |= IO_WORKER_F_FREE; + set_bit(IO_WORKER_F_FREE, &worker->flags); raw_spin_unlock(&wqe->lock); wake_up_new_task(tsk); } @@ -826,7 +827,7 @@ static bool create_io_worker(struct io_wq *wq, struct io_wqe *wqe, int index) init_completion(&worker->ref_done); if (index == IO_WQ_ACCT_BOUND) - worker->flags |= IO_WORKER_F_BOUND; + set_bit(IO_WORKER_F_BOUND, &worker->flags); tsk = create_io_thread(io_wqe_worker, worker, wqe->node); if (!IS_ERR(tsk)) { @@ -914,7 +915,7 @@ static bool io_wq_work_match_item(struct io_wq_work *work, void *data) static void io_wqe_enqueue(struct io_wqe *wqe, struct io_wq_work *work) { struct io_wqe_acct *acct = io_work_get_acct(wqe, work); - unsigned work_flags = work->flags; + unsigned long work_flags = work->flags; bool do_create; /* -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] netpoll: Fix race condition in netpoll_owner_active
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v5.10.221 commit 43c0ca793a18578a0f5b305dd77fcf7ed99f1265 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1O CVE: CVE-2024-41005 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c2e6a872bde9912f1a7579639c5ca3adf1003916 ] KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240429100437.3487432-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/core/netpoll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 960948290001..fd7375625dad 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -299,7 +299,7 @@ static int netpoll_owner_active(struct net_device *dev) struct napi_struct *napi; list_for_each_entry_rcu(napi, &dev->napi_list, dev_list) { - if (napi->poll_owner == smp_processor_id()) + if (READ_ONCE(napi->poll_owner) == smp_processor_id()) return 1; } return 0; -- 2.34.1

2 1

[PATCH OLK-5.10] netpoll: Fix race condition in netpoll_owner_active
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v5.10.221 commit 43c0ca793a18578a0f5b305dd77fcf7ed99f1265 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1O CVE: CVE-2024-41005 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c2e6a872bde9912f1a7579639c5ca3adf1003916 ] KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240429100437.3487432-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/core/netpoll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 2ad22511b9c6..f76afab9fd8b 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -316,7 +316,7 @@ static int netpoll_owner_active(struct net_device *dev) struct napi_struct *napi; list_for_each_entry_rcu(napi, &dev->napi_list, dev_list) { - if (napi->poll_owner == smp_processor_id()) + if (READ_ONCE(napi->poll_owner) == smp_processor_id()) return 1; } return 0; -- 2.34.1

2 1

[PATCH OLK-6.6] io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
by Yifan Qiao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.35 commit ab702c3483db9046bab9f40306f1a28b22dbbdc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2Y CVE: CVE-2024-39508 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8a565304927fbd28c9f028c492b5c1714002cbab ] Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) <snip> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) <snip> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags. Also, move `create_index` to avoid holes in the structure. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240507170002.2269003-1-leitao@debian.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Stable-dep-of: 91215f70ea85 ("io_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- io_uring/io-wq.c | 47 ++++++++++++++++++++++++----------------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c index 522196dfb0ff..606fc5b64c65 100644 --- a/io_uring/io-wq.c +++ b/io_uring/io-wq.c @@ -25,10 +25,10 @@ #define WORKER_IDLE_TIMEOUT (5 * HZ) enum { - IO_WORKER_F_UP = 1, /* up and active */ - IO_WORKER_F_RUNNING = 2, /* account as running */ - IO_WORKER_F_FREE = 4, /* worker on free list */ - IO_WORKER_F_BOUND = 8, /* is doing bounded work */ + IO_WORKER_F_UP = 0, /* up and active */ + IO_WORKER_F_RUNNING = 1, /* account as running */ + IO_WORKER_F_FREE = 2, /* worker on free list */ + IO_WORKER_F_BOUND = 3, /* is doing bounded work */ }; enum { @@ -44,7 +44,8 @@ enum { */ struct io_worker { refcount_t ref; - unsigned flags; + int create_index; + unsigned long flags; struct hlist_nulls_node nulls_node; struct list_head all_list; struct task_struct *task; @@ -58,7 +59,6 @@ struct io_worker { unsigned long create_state; struct callback_head create_work; - int create_index; union { struct rcu_head rcu; @@ -165,7 +165,7 @@ static inline struct io_wq_acct *io_work_get_acct(struct io_wq *wq, static inline struct io_wq_acct *io_wq_get_acct(struct io_worker *worker) { - return io_get_acct(worker->wq, worker->flags & IO_WORKER_F_BOUND); + return io_get_acct(worker->wq, test_bit(IO_WORKER_F_BOUND, &worker->flags)); } static void io_worker_ref_put(struct io_wq *wq) @@ -225,7 +225,7 @@ static void io_worker_exit(struct io_worker *worker) wait_for_completion(&worker->ref_done); raw_spin_lock(&wq->lock); - if (worker->flags & IO_WORKER_F_FREE) + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) hlist_nulls_del_rcu(&worker->nulls_node); list_del_rcu(&worker->all_list); raw_spin_unlock(&wq->lock); @@ -410,7 +410,7 @@ static void io_wq_dec_running(struct io_worker *worker) struct io_wq_acct *acct = io_wq_get_acct(worker); struct io_wq *wq = worker->wq; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; if (!atomic_dec_and_test(&acct->nr_running)) @@ -430,8 +430,8 @@ static void io_wq_dec_running(struct io_worker *worker) */ static void __io_worker_busy(struct io_wq *wq, struct io_worker *worker) { - if (worker->flags & IO_WORKER_F_FREE) { - worker->flags &= ~IO_WORKER_F_FREE; + if (test_bit(IO_WORKER_F_FREE, &worker->flags)) { + clear_bit(IO_WORKER_F_FREE, &worker->flags); raw_spin_lock(&wq->lock); hlist_nulls_del_init_rcu(&worker->nulls_node); raw_spin_unlock(&wq->lock); @@ -444,8 +444,8 @@ static void __io_worker_busy(struct io_wq *wq, struct io_worker *worker) static void __io_worker_idle(struct io_wq *wq, struct io_worker *worker) __must_hold(wq->lock) { - if (!(worker->flags & IO_WORKER_F_FREE)) { - worker->flags |= IO_WORKER_F_FREE; + if (!test_bit(IO_WORKER_F_FREE, &worker->flags)) { + set_bit(IO_WORKER_F_FREE, &worker->flags); hlist_nulls_add_head_rcu(&worker->nulls_node, &wq->free_list); } } @@ -631,7 +631,8 @@ static int io_wq_worker(void *data) bool exit_mask = false, last_timeout = false; char buf[TASK_COMM_LEN]; - worker->flags |= (IO_WORKER_F_UP | IO_WORKER_F_RUNNING); + set_mask_bits(&worker->flags, 0, + BIT(IO_WORKER_F_UP) | BIT(IO_WORKER_F_RUNNING)); snprintf(buf, sizeof(buf), "iou-wrk-%d", wq->task->pid); set_task_comm(current, buf); @@ -695,11 +696,11 @@ void io_wq_worker_running(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (worker->flags & IO_WORKER_F_RUNNING) + if (test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags |= IO_WORKER_F_RUNNING; + set_bit(IO_WORKER_F_RUNNING, &worker->flags); io_wq_inc_running(worker); } @@ -713,12 +714,12 @@ void io_wq_worker_sleeping(struct task_struct *tsk) if (!worker) return; - if (!(worker->flags & IO_WORKER_F_UP)) + if (!test_bit(IO_WORKER_F_UP, &worker->flags)) return; - if (!(worker->flags & IO_WORKER_F_RUNNING)) + if (!test_bit(IO_WORKER_F_RUNNING, &worker->flags)) return; - worker->flags &= ~IO_WORKER_F_RUNNING; + clear_bit(IO_WORKER_F_RUNNING, &worker->flags); io_wq_dec_running(worker); } @@ -732,7 +733,7 @@ static void io_init_new_worker(struct io_wq *wq, struct io_worker *worker, raw_spin_lock(&wq->lock); hlist_nulls_add_head_rcu(&worker->nulls_node, &wq->free_list); list_add_tail_rcu(&worker->all_list, &wq->all_list); - worker->flags |= IO_WORKER_F_FREE; + set_bit(IO_WORKER_F_FREE, &worker->flags); raw_spin_unlock(&wq->lock); wake_up_new_task(tsk); } @@ -838,7 +839,7 @@ static bool create_io_worker(struct io_wq *wq, int index) init_completion(&worker->ref_done); if (index == IO_WQ_ACCT_BOUND) - worker->flags |= IO_WORKER_F_BOUND; + set_bit(IO_WORKER_F_BOUND, &worker->flags); tsk = create_io_thread(io_wq_worker, worker, NUMA_NO_NODE); if (!IS_ERR(tsk)) { @@ -924,8 +925,8 @@ static bool io_wq_work_match_item(struct io_wq_work *work, void *data) void io_wq_enqueue(struct io_wq *wq, struct io_wq_work *work) { struct io_wq_acct *acct = io_work_get_acct(wq, work); + unsigned long work_flags = work->flags; struct io_cb_cancel_data match; - unsigned work_flags = work->flags; bool do_create; /* -- 2.39.2

2 1

[PATCH OLK-6.6] netpoll: Fix race condition in netpoll_owner_active
by Zhengchao Shao 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.36 commit 3f1a155950a1685ffd0fd7175b3f671da8771f3d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1O CVE: CVE-2024-41005 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c2e6a872bde9912f1a7579639c5ca3adf1003916 ] KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240429100437.3487432-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/core/netpoll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 543007f159f9..55bcacf67df3 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -316,7 +316,7 @@ static int netpoll_owner_active(struct net_device *dev) struct napi_struct *napi; list_for_each_entry_rcu(napi, &dev->napi_list, dev_list) { - if (napi->poll_owner == smp_processor_id()) + if (READ_ONCE(napi->poll_owner) == smp_processor_id()) return 1; } return 0; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] usb: host: ohci-tmio: check return value after calling platform_get_resource()
by Zheng Zucheng 16 Jul '24

16 Jul '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion from stable-v5.10.82 commit 2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEW CVE: CVE-2021-47206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Conflicts: drivers/usb/host/ohci-tmio.c [Some contexts different. No functional impact.] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index a631dbb369d7..b75f4ce642a2 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -196,7 +196,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev) if (usb_disabled()) return -ENODEV; - if (!cell) +: if (!cell || !regs || !config || !sram) return -EINVAL; hcd = usb_create_hcd(&ohci_tmio_hc_driver, &dev->dev, dev_name(&dev->dev)); -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6] btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes
by Wang Zhaolong 16 Jul '24

16 Jul '24

From: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> stable inclusion from stable-v6.6.36 commit 082b3d4e788953a3ff42ecdb70c4210149076285 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR20 CVE: CVE-2024-40962 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cebae292e0c32a228e8f2219c270a7237be24a6a ] Shin'ichiro reported that when he's running fstests' test-case btrfs/167 on emulated zoned devices, he's seeing the following NULL pointer dereference in 'btrfs_zone_finish_endio()': Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G W 6.10.0-rc2-kts+ #4 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210 FS: 0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die_addr+0x46/0x70 ? exc_general_protection+0x14f/0x250 ? asm_exc_general_protection+0x26/0x30 ? do_raw_read_unlock+0x44/0x70 ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs] ? __pfx_lock_release+0x10/0x10 ? do_raw_write_lock+0x90/0x260 ? __pfx_do_raw_write_lock+0x10/0x10 ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs] ? _raw_write_unlock+0x23/0x40 ? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs] ? lock_acquire+0x435/0x500 btrfs_work_helper+0x1b1/0xa70 [btrfs] ? __schedule+0x10a8/0x60b0 ? __pfx___might_resched+0x10/0x10 process_one_work+0x862/0x1410 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5e6/0x1010 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c3/0x3a0 ? trace_irq_enable.constprop.0+0xce/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Enabling CONFIG_BTRFS_ASSERT revealed the following assertion to trigger: assertion failed: !list_empty(&ordered->list), in fs/btrfs/zoned.c:1815 This indicates, that we're missing the checksums list on the ordered_extent. As btrfs/167 is doing a NOCOW write this is to be expected. Further analysis with drgn confirmed the assumption: >>> inode = prog.crashed_thread().stack_trace()[11]['ordered'].inode >>> btrfs_inode = drgn.container_of(inode, "struct btrfs_inode", \ "vfs_inode") >>> print(btrfs_inode.flags) (u32)1 As zoned emulation mode simulates conventional zones on regular devices, we cannot use zone-append for writing. But we're only attaching dummy checksums if we're doing a zone-append write. So for NOCOW zoned data writes on conventional zones, also attach a dummy checksum. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: cbfce4c7fbde ("btrfs: optimize the logical to physical mapping for zoned writes") CC: Naohiro Aota <Naohiro.Aota(a)wdc.com> # 6.6+ Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Reviewed-by: Naohiro Aota <naohiro.aota(a)wdc.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/btrfs/bio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c index 12b12443efaa..e47eb248309f 100644 --- a/fs/btrfs/bio.c +++ b/fs/btrfs/bio.c @@ -705,7 +705,9 @@ static bool btrfs_submit_chunk(struct btrfs_bio *bbio, int mirror_num) ret = btrfs_bio_csum(bbio); if (ret) goto fail_put_bio; - } else if (use_append) { + } else if (use_append || + (btrfs_is_zoned(fs_info) && inode && + inode->flags & BTRFS_INODE_NODATASUM)) { ret = btrfs_alloc_dummy_sum(bbio); if (ret) goto fail_put_bio; -- 2.34.3

2 1

[PATCH OLK-5.10] nilfs2: fix potential kernel bug due to lack of writeback flag waiting
by dinglongwei 16 Jul '24

16 Jul '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v6.1.95 commit 271dcd977ccda8c7a26e360425ae7b4db7d2ecc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AE5 CVE: CVE-2024-37078 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a4ca369ca221bb7e06c725792ac107f0e48e82e7 upstream. Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state. Link: https://lkml.kernel.org/r/20240530141556.4411-1-konishi.ryusuke@gmail.com Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- fs/nilfs2/segment.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 2eeae67ad298..02407c524382 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -1697,6 +1697,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) if (bh->b_page != bd_page) { if (bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); @@ -1710,6 +1711,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) if (bh == segbuf->sb_super_root) { if (bh->b_page != bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); @@ -1726,6 +1728,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) } if (bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); -- 2.17.1

2 1

[PATCH OLK-6.6 0/2] bpf: Fix null-pointer-deref in resolve_prog_type()
by Tengda Wu 16 Jul '24

16 Jul '24

Hi, This patchset is going to fix null-pointer-deref in resolve_prog_type() for BPF_PROG_TYPE_EXT. `prog->aux->dst_prog` in resolve_prog_type() is assigned by `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided. Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will lead to null-pointer-deref. In last version we fix it by forcing `attach_prog_fd` non-empty at load time, which leads to libbpf_probe_prog_types() api broken. Currently, we fix it by just adding null check for EXT prog in resolve_prog_type() as the old way did. For the sake of safety, we compared the full test logs of selftest before and after applying these changes, and the results show that the two test logs were consistent. Best regards, Tengda Tengda Wu (2): bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() include/linux/bpf_verifier.h | 2 +- tools/testing/selftests/bpf/verifier/calls.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock Ritesh Harjani (1): ext4: remove duplicate definition of ext4_xattr_ibody_inline_set() fs/ext4/xattr.h | 6 +- fs/ext4/inline.c | 11 ++- fs/ext4/xattr.c | 175 +++++++++++++++++++---------------------------- 3 files changed, 79 insertions(+), 113 deletions(-) -- 2.39.2

2 4

[PATCH openEuler-22.03-LTS-SP1 0/2] Fix CVE-2023-52781
by Wang Wensheng 16 Jul '24

16 Jul '24

Alan Stern (1): USB: core: Change configuration warnings to notices Niklas Neronin (1): usb: config: fix iteration issue in 'usb_get_bos_descriptor()' drivers/usb/core/config.c | 85 ++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 42 deletions(-) -- 2.17.1

2 3

[PATCH OLK-6.6 0/2] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 155 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 82 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS] usb: host: ohci-tmio: check return value after calling platform_get_resource()
by Zheng Zucheng 16 Jul '24

16 Jul '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion form stable-v5.10.82 commit 2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEW CVE: CVE-2021-47206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Conflicts: drivers/usb/host/ohci-tmio.c [Some contexts different. No functional impact.] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index a631dbb369d7..b75f4ce642a2 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -196,7 +196,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev) if (usb_disabled()) return -ENODEV; - if (!cell) +: if (!cell || !regs || !config || !sram) return -EINVAL; hcd = usb_create_hcd(&ohci_tmio_hc_driver, &dev->dev, dev_name(&dev->dev)); -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] bpf: Fix null-pointer-deref in resolve_prog_type()
by Tengda Wu 16 Jul '24

16 Jul '24

Hi, This patchset is going to fix null-pointer-deref in resolve_prog_type() for BPF_PROG_TYPE_EXT. `prog->aux->dst_prog` in resolve_prog_type() is assigned by `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided. Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will lead to null-pointer-deref. In last version we fix it by forcing `attach_prog_fd` non-empty at load time, which leads to libbpf_probe_prog_types() api broken. Currently, we fix it by just adding null check for EXT prog in resolve_prog_type() as the old way did. For the sake of safety, we compared the full test logs of selftest before and after applying these changes, and the results show that the two test logs were consistent. Best regards, Tengda Tengda Wu (2): bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() include/linux/bpf_verifier.h | 2 +- tools/testing/selftests/bpf/verifier/calls.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-5.10] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
by felix 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.10-rc5 commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT6J CVE: CVE-2024-40953 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240510092353.2261824-1-leitao@debian.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Conflicts: virt/kvm/kvm_main.c [Fix context because of 46808a4cb89708c2e5b264eb9d1035762581921b not merged] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 53c83483653f..2b28fcb35641 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2503,12 +2503,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; int yielded = 0; int try = 3; int pass; int i; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -2538,7 +2539,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
by felix 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.10-rc5 commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT6J CVE: CVE-2024-40953 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240510092353.2261824-1-leitao@debian.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Conflicts: virt/kvm/kvm_main.c [Fix context because of 46808a4cb89708c2e5b264eb9d1035762581921b not merged] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 53c83483653f..2b28fcb35641 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2503,12 +2503,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; int yielded = 0; int try = 3; int pass; int i; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -2538,7 +2539,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] usb: host: ohci-tmio: check return value after calling platform_get_resource()
by Zheng Zucheng 16 Jul '24

16 Jul '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion form stable-v5.10.82 commit 2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEW CVE: CVE-2021-47206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index a631dbb369d7..b75f4ce642a2 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -196,7 +196,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev) if (usb_disabled()) return -ENODEV; - if (!cell) +: if (!cell || !regs || !config || !sram) return -EINVAL; hcd = usb_create_hcd(&ohci_tmio_hc_driver, &dev->dev, dev_name(&dev->dev)); -- 2.34.1

2 1

openEuler Kernel SIG双周例会
by openEuler conference 16 Jul '24

16 Jul '24

您好！ Kernel 邀请您参加 2024-07-19 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 议题征集中（新增议题可直接回复本邮件申请，或填报至会议纪要看板）会议链接：https://meeting.huaweicloud.com:36443/#/j/961167952 会议纪要：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 2024-07-19 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/961167952. Add topics at https://etherpad.openeuler.org/p/Kernel-meetings. More information: https://www.openeuler.org/en/

1 0

[PATCH openEuler-1.0-LTS] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
by felix 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.10-rc5 commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT6J CVE: CVE-2024-40953 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240510092353.2261824-1-leitao@debian.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Conflicts: virt/kvm/kvm_main.c [Fix context because of 46808a4cb89708c2e5b264eb9d1035762581921b not merged] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 53c83483653f..2b28fcb35641 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2503,12 +2503,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; int yielded = 0; int try = 3; int pass; int i; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -2538,7 +2539,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS WITH WARNING 55dbcf2f32ff417a82aec66a24e6a9ac00bf759c
by kernel test robot 16 Jul '24

16 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 55dbcf2f32ff417a82aec66a24e6a9ac00bf759c !9830 mmc: davinci: Don't strip remove function when driver is builtin Warning: (recently discovered and may have been fixed) kernel/livepatch/core.c:75:16: warning: no previous prototype for function 'klp_check_patch_kprobed' [-Wmissing-prototypes] Unverified Warning (likely false positive, please contact us if interested): drivers/block/loop.c:1338 loop_set_status() warn: inconsistent returns '&loop_ctl_mutex'. Warning ids grouped by kconfigs: recent_errors |-- x86_64-randconfig-073-20240521 | `-- kernel-livepatch-core.c:warning:no-previous-prototype-for-function-klp_check_patch_kprobed `-- x86_64-randconfig-161-20240430 `-- drivers-block-loop.c-loop_set_status()-warn:inconsistent-returns-loop_ctl_mutex-. elapsed time: 723m configs tested: 26 configs skipped: 139 tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240716 gcc-14.1.0 arm64 randconfig-002-20240716 gcc-14.1.0 arm64 randconfig-003-20240716 gcc-14.1.0 arm64 randconfig-004-20240716 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240716 gcc-13 x86_64 buildonly-randconfig-002-20240716 clang-18 x86_64 buildonly-randconfig-003-20240716 clang-18 x86_64 buildonly-randconfig-004-20240716 clang-18 x86_64 buildonly-randconfig-005-20240716 clang-18 x86_64 buildonly-randconfig-006-20240716 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240716 gcc-13 x86_64 randconfig-002-20240716 gcc-8 x86_64 randconfig-003-20240716 gcc-8 x86_64 randconfig-004-20240716 clang-18 x86_64 randconfig-005-20240716 gcc-12 x86_64 randconfig-006-20240716 clang-18 x86_64 randconfig-011-20240716 clang-18 x86_64 randconfig-012-20240716 gcc-9 x86_64 randconfig-015-20240716 gcc-7 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock Ritesh Harjani (1): ext4: remove duplicate definition of ext4_xattr_ibody_inline_set() send-patches.sh | 96 ++++++++++++++++++++++++++ fs/ext4/xattr.h | 6 +- fs/ext4/inline.c | 11 ++- fs/ext4/xattr.c | 175 +++++++++++++++++++---------------------------- 4 files changed, 175 insertions(+), 113 deletions(-) create mode 100644 send-patches.sh -- 2.39.2

2 4

[PATCH OLK-6.6] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
by felix 16 Jul '24

16 Jul '24

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.36 commit a937ef951bba72f48d2402451419d725d70dba20 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT6J CVE: CVE-2024-40953 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb upstream. Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Link: https://lore.kernel.org/r/20240510092353.2261824-1-leitao@debian.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 5877ba2f0056..62f19b4b9605 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3788,12 +3788,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; unsigned long i; int yielded = 0; int try = 3; int pass; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -3824,7 +3825,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.34.1

2 1

[PATCH OLK-6.6 0/3] CVE-2024-39503
by Liu Jian 16 Jul '24

16 Jul '24

CVE-2024-39503 Alexander Maltsev (1): netfilter: ipset: Add list flush to cancel_gc Jozsef Kadlecsik (2): netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type netfilter: ipset: Fix suspicious rcu_dereference_protected() net/netfilter/ipset/ip_set_core.c | 92 +++++++++++++++------------ net/netfilter/ipset/ip_set_list_set.c | 33 +++++----- 2 files changed, 69 insertions(+), 56 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6 0/2] bpf: Fix null-pointer-deref in resolve_prog_type()
by Tengda Wu 16 Jul '24

16 Jul '24

From: Tengda Wu <wutengda(a)huaweicloud.com> Hi, This patchset is going to fix null-pointer-deref in resolve_prog_type() for BPF_PROG_TYPE_EXT. `prog->aux->dst_prog` in resolve_prog_type() is assigned by `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided. Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will lead to null-pointer-deref. In last version we fix it by forcing `attach_prog_fd` non-empty at load time, which leads to libbpf_probe_prog_types() api broken. Currently, we fix it by just adding null check for EXT prog in resolve_prog_type() as the old way did. For the sake of safety, we compared the full test logs of selftest before and after applying these changes, and the results show that the two test logs were consistent. Best regards, Tengda Change list: v4: - Fix by add null check in resolve_prog_type() which can avoid libbpf_probe_prog_types api breaking. v3: - Add a small selftest for the BPF CI, and split 1-patch into 3-patch series as recommended by Daniel. https://lore.kernel.org/all/d16b4f29-8966-464f-b530-35e39fda3f46@huaweiclou… v2: - Fix libbpf_probe_prog_types test failure reported by CI by adapting libbpf code. (thanks for jirka's reminder) v1: https://lore.kernel.org/all/20240620060701.1465291-1-wutengda@huaweicloud.c… Tengda Wu (2): bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() include/linux/bpf_verifier.h | 2 +- tools/testing/selftests/bpf/verifier/calls.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.34.1

1 0

[PATCH openEuler-22.03-LTS-SP1 v2] netfilter: nft_set_pipapo: do not free live element
by Wei Li 16 Jul '24

16 Jul '24

From: Florian Westphal <fw(a)strlen.de> mainline inclusion from mainline-v6.9-rc5 commit 3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9JFG2 CVE: CVE-2024-26924 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano) Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com> Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Conflicts: net/netfilter/nft_set_pipapo.c [lw: fix context conflict due to lack of commit f8bf7706151a ("netfilter: nf_tables: integrate pipapo into commit protocol")] Signed-off-by: Wei Li <liwei391(a)huawei.com> --- net/netfilter/nft_set_pipapo.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c index 9ca18f4c4eaf7..9b9505f31733f 100644 --- a/net/netfilter/nft_set_pipapo.c +++ b/net/netfilter/nft_set_pipapo.c @@ -1932,6 +1932,8 @@ static void nft_pipapo_remove(const struct net *net, const struct nft_set *set, rules_fx = rules_f0; nft_pipapo_for_each_field(f, i, m) { + bool last = i == m->field_count - 1; + if (!pipapo_match_field(f, start, rules_fx, match_start, match_end)) break; @@ -1944,17 +1946,19 @@ static void nft_pipapo_remove(const struct net *net, const struct nft_set *set, match_start += NFT_PIPAPO_GROUPS_PADDED_SIZE(f); match_end += NFT_PIPAPO_GROUPS_PADDED_SIZE(f); - } - if (i == m->field_count) { - priv->dirty = true; - pipapo_drop(m, rulemap); - pipapo_commit(set); - return; + if (last && f->mt[rulemap[i].to].e == e) { + priv->dirty = true; + pipapo_drop(m, rulemap); + pipapo_commit(set); + return; + } } first_rule += rules_f0; } + + WARN_ON_ONCE(1); /* elem_priv not found */ } /** -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 154 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 81 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6 0/2] CVE-2024-40955
by Yifan Qiao 16 Jul '24

16 Jul '24

Baokun Li (2): ext4: avoid overflow when setting values via sysfs ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 26 ++++++++++++++++++++------ 2 files changed, 24 insertions(+), 6 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10 0/2] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 154 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 81 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6 0/2] CVE-2024-40955
by Yifan Qiao 16 Jul '24

16 Jul '24

Baokun Li (2): ext4: avoid overflow when setting values via sysfs ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 26 ++++++++++++++++++++------ 2 files changed, 24 insertions(+), 6 deletions(-) -- 2.39.2

2 3

[openeuler:OLK-5.10] BUILD SUCCESS 9bb937dc2a0a27c10c505388c7a3665f5e5f23d2
by kernel test robot 16 Jul '24

16 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 9bb937dc2a0a27c10c505388c7a3665f5e5f23d2 !9871 cifs: Fix deadlock in cifs_writepages during reconnect elapsed time: 725m configs tested: 35 configs skipped: 139 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240716 gcc-14.1.0 arm64 randconfig-002-20240716 clang-19 arm64 randconfig-003-20240716 gcc-14.1.0 arm64 randconfig-004-20240716 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240716 gcc-13 x86_64 buildonly-randconfig-002-20240716 clang-18 x86_64 buildonly-randconfig-003-20240716 clang-18 x86_64 buildonly-randconfig-004-20240716 clang-18 x86_64 buildonly-randconfig-005-20240716 clang-18 x86_64 buildonly-randconfig-006-20240716 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240716 gcc-13 x86_64 randconfig-002-20240716 gcc-8 x86_64 randconfig-003-20240716 gcc-8 x86_64 randconfig-004-20240716 clang-18 x86_64 randconfig-005-20240716 gcc-12 x86_64 randconfig-006-20240716 clang-18 x86_64 randconfig-011-20240716 clang-18 x86_64 randconfig-012-20240716 gcc-9 x86_64 randconfig-013-20240716 gcc-13 x86_64 randconfig-014-20240716 gcc-13 x86_64 randconfig-015-20240716 gcc-7 x86_64 randconfig-016-20240716 clang-18 x86_64 randconfig-071-20240716 clang-18 x86_64 randconfig-072-20240716 clang-18 x86_64 randconfig-073-20240716 clang-18 x86_64 randconfig-074-20240716 clang-18 x86_64 randconfig-075-20240716 clang-18 x86_64 randconfig-076-20240716 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] Bluetooth: qca: fix info leak when fetching board id
by felix 16 Jul '24

16 Jul '24

From: Johan Hovold <johan+linaro(a)kernel.org> stable inclusion from stable-v6.6.31 commit ba307abed5e09759845c735ba036f8c12f55b209 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TN2K CVE: CVE-2024-36033 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0adcf6be1445ed50bfd4a451a7a782568f270197 upstream. Add the missing sanity check when fetching the board id to avoid leaking slab data when later requesting the firmware. Fixes: a7f8dedb4be2 ("Bluetooth: qca: add support for QCA2066") Cc: stable(a)vger.kernel.org # 6.7 Cc: Tim Jiang <quic_tjiang(a)quicinc.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/bluetooth/btqca.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 35fb26cbf229..47ea1e909476 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -259,6 +259,11 @@ static int qca_read_fw_board_id(struct hci_dev *hdev, u16 *bid) goto out; } + if (skb->len < 3) { + err = -EILSEQ; + goto out; + } + *bid = (edl->data[1] << 8) + edl->data[2]; bt_dev_dbg(hdev, "%s: bid = %x", __func__, *bid); -- 2.34.1

2 1

[PATCH OLK-6.6] Bluetooth: qca: fix info leak when fetching board id
by felix 16 Jul '24

16 Jul '24

From: Johan Hovold <johan+linaro(a)kernel.org> stable inclusion from stable-v6.6.31 commit ba307abed5e09759845c735ba036f8c12f55b209 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TN2K CVE: CVE-2024-36033 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0adcf6be1445ed50bfd4a451a7a782568f270197 upstream. Add the missing sanity check when fetching the board id to avoid leaking slab data when later requesting the firmware. Fixes: a7f8dedb4be2 ("Bluetooth: qca: add support for QCA2066") Cc: stable(a)vger.kernel.org # 6.7 Cc: Tim Jiang <quic_tjiang(a)quicinc.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/bluetooth/btqca.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 35fb26cbf229..47ea1e909476 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -259,6 +259,11 @@ static int qca_read_fw_board_id(struct hci_dev *hdev, u16 *bid) goto out; } + if (skb->len < 3) { + err = -EILSEQ; + goto out; + } + *bid = (edl->data[1] << 8) + edl->data[2]; bt_dev_dbg(hdev, "%s: bid = %x", __func__, *bid); -- 2.34.1

2 2

[PATCH OLK-5.10 0/2] CVE-2024-40972
by Yifan Qiao 16 Jul '24

16 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 154 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 81 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6] iommu/arm-smmu-v3: Change the style to identify the the hisi_platform
by Zhang Zekun 16 Jul '24

16 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IACKUP ---------------------------------------------- The code is isolated by CONFIG_ARCH_HISI which could also be opened in other platforms . Change the style to identify the hisi platform to minimize the code influence scope. Fixes: 0b84ef37d4f8 ("iommu/arm-smmu-v3: Enable iotlb_sync_map according to SMMU_IIDR") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 22 +++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 87f9bed391ec..16217647fd67 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -141,6 +141,7 @@ struct arm_smmu_ctx_desc quiet_cd = { 0 }; static struct arm_smmu_option_prop arm_smmu_options[] = { { ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" }, { ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"}, + { ARM_SMMU_OPT_SYNC_MAP, "hisilicon,broken-prefetch-pgtbl"}, { 0, NULL}, }; @@ -4493,6 +4494,25 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI +static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { + /* HiSilicon Hip09 Platform */ + {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP10 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP11 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + { } +}; + +static void acpi_get_hisi_options(struct arm_smmu_device *smmu) +{ + if (acpi_match_platform_list(arm_smmu_v3_plat_info) < 0) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; +} + static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) { switch (model) { @@ -4504,6 +4524,8 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) break; } + acpi_get_hisi_options(smmu); + dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options); } -- 2.17.1

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 16 Jul '24

16 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 10 ++++++++++ 2 files changed, 24 insertions(+) -- 2.25.1

2 2

[openeuler:OLK-6.6] BUILD SUCCESS 46ad6f1c27febfee76dfe034d20c531348ebb487
by kernel test robot 16 Jul '24

16 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 46ad6f1c27febfee76dfe034d20c531348ebb487 !9899 ionic: fix use after netif_napi_del() Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- arm64-defconfig | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-defconfig | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-randconfig-001-20240715 | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and `-- x86_64-allyesconfig `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device elapsed time: 720m configs tested: 40 configs skipped: 134 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240715 clang-19 arm64 randconfig-002-20240715 clang-19 arm64 randconfig-003-20240715 clang-19 arm64 randconfig-004-20240715 clang-19 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch defconfig gcc-14.1.0 loongarch randconfig-001-20240715 gcc-14.1.0 loongarch randconfig-002-20240715 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240715 clang-18 x86_64 buildonly-randconfig-002-20240715 gcc-13 x86_64 buildonly-randconfig-003-20240715 clang-18 x86_64 buildonly-randconfig-004-20240715 gcc-13 x86_64 buildonly-randconfig-005-20240715 gcc-13 x86_64 buildonly-randconfig-006-20240715 gcc-8 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240715 gcc-9 x86_64 randconfig-002-20240715 gcc-7 x86_64 randconfig-003-20240715 clang-18 x86_64 randconfig-004-20240715 clang-18 x86_64 randconfig-005-20240715 gcc-11 x86_64 randconfig-006-20240715 clang-18 x86_64 randconfig-011-20240715 gcc-12 x86_64 randconfig-012-20240715 clang-18 x86_64 randconfig-013-20240715 clang-18 x86_64 randconfig-014-20240715 gcc-12 x86_64 randconfig-015-20240715 gcc-10 x86_64 randconfig-016-20240715 gcc-10 x86_64 randconfig-071-20240715 gcc-13 x86_64 randconfig-072-20240715 gcc-13 x86_64 randconfig-073-20240715 gcc-13 x86_64 randconfig-074-20240715 gcc-12 x86_64 randconfig-075-20240715 clang-18 x86_64 randconfig-076-20240715 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/1] kvm: add coda feature
by l00500167 16 Jul '24

16 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 9 +++++++++ 2 files changed, 23 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6] parisc: Try to fix random segmentation faults in package builds
by Tengda Wu 16 Jul '24

16 Jul '24

From: John David Anglin <dave(a)parisc-linux.org> stable inclusion from stable-v6.6.35 commit 5bf196f1936bf93df31112fbdfb78c03537c07b0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD05C CVE: CVE-2024-40918 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 72d95924ee35c8cd16ef52f912483ee938a34d49 upstream. PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ptep_clear_flush_young to keep things synchronized. The default implementation only flushes the TLB entry. Other changes in this version are: 1) Implement parisc specific version of ptep_get. It's identical to default but needed in arch/parisc/include/asm/pgtable.h. 2) Revise parisc implementation of ptep_test_and_clear_young to use ptep_get (READ_ONCE). 3) Drop parisc implementation of ptep_get_and_clear. We can use default. 4) Revise flush_kernel_vmap_range and invalidate_kernel_vmap_range to use full data cache flush. 5) Move flush_cache_vmap and flush_cache_vunmap to cache.c. Handle VM_IOREMAP case in flush_cache_vmap. At this time, I don't know whether it is better to always flush when the PTE present bit is set or when both the accessed and present bits are set. The later saves flushing pages that haven't been accessed, but we need to flush in ptep_clear_flush_young. It also needs a page table lookup to find the PTE pointer. The lpa instruction only needs a page table lookup when the PTE entry isn't in the TLB. We don't atomically handle setting and clearing the _PAGE_ACCESSED bit. If we miss an update, we may miss a flush and the cache may get corrupted. Whether the current code is effectively atomic depends on process control. When CONFIG_FLUSH_PAGE_ACCESSED is set to zero, the page will eventually be flushed when the PTE is cleared or in flush_cache_page_if_present. The _PAGE_ACCESSED bit is not used, so the problem is avoided. The flush method can be selected using the CONFIG_FLUSH_PAGE_ACCESSED define in cache.c. The default is 0. I didn't see a large difference in performance. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Cc: <stable(a)vger.kernel.org> # v6.6+ Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- arch/parisc/include/asm/cacheflush.h | 15 +- arch/parisc/include/asm/pgtable.h | 27 +- arch/parisc/kernel/cache.c | 413 +++++++++++++++++---------- 3 files changed, 275 insertions(+), 180 deletions(-) diff --git a/arch/parisc/include/asm/cacheflush.h b/arch/parisc/include/asm/cacheflush.h index ba4c05bc24d6..8394718870e1 100644 --- a/arch/parisc/include/asm/cacheflush.h +++ b/arch/parisc/include/asm/cacheflush.h @@ -31,18 +31,17 @@ void flush_cache_all_local(void); void flush_cache_all(void); void flush_cache_mm(struct mm_struct *mm); -void flush_kernel_dcache_page_addr(const void *addr); - #define flush_kernel_dcache_range(start,size) \ flush_kernel_dcache_range_asm((start), (start)+(size)); +/* The only way to flush a vmap range is to flush whole cache */ #define ARCH_IMPLEMENTS_FLUSH_KERNEL_VMAP_RANGE 1 void flush_kernel_vmap_range(void *vaddr, int size); void invalidate_kernel_vmap_range(void *vaddr, int size); -#define flush_cache_vmap(start, end) flush_cache_all() +void flush_cache_vmap(unsigned long start, unsigned long end); #define flush_cache_vmap_early(start, end) do { } while (0) -#define flush_cache_vunmap(start, end) flush_cache_all() +void flush_cache_vunmap(unsigned long start, unsigned long end); void flush_dcache_folio(struct folio *folio); #define flush_dcache_folio flush_dcache_folio @@ -77,17 +76,11 @@ void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end); -/* defined in pacache.S exported in cache.c used by flush_anon_page */ -void flush_dcache_page_asm(unsigned long phys_addr, unsigned long vaddr); - #define ARCH_HAS_FLUSH_ANON_PAGE void flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vmaddr); #define ARCH_HAS_FLUSH_ON_KUNMAP -static inline void kunmap_flush_on_unmap(const void *addr) -{ - flush_kernel_dcache_page_addr(addr); -} +void kunmap_flush_on_unmap(const void *addr); #endif /* _PARISC_CACHEFLUSH_H */ diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h index 974accac05cd..babf65751e81 100644 --- a/arch/parisc/include/asm/pgtable.h +++ b/arch/parisc/include/asm/pgtable.h @@ -448,14 +448,17 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte) return pte; } +static inline pte_t ptep_get(pte_t *ptep) +{ + return READ_ONCE(*ptep); +} +#define ptep_get ptep_get + static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) { pte_t pte; - if (!pte_young(*ptep)) - return 0; - - pte = *ptep; + pte = ptep_get(ptep); if (!pte_young(pte)) { return 0; } @@ -463,17 +466,10 @@ static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned return 1; } -struct mm_struct; -static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep) -{ - pte_t old_pte; - - old_pte = *ptep; - set_pte(ptep, __pte(0)); - - return old_pte; -} +int ptep_clear_flush_young(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep); +pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep); +struct mm_struct; static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr, pte_t *ptep) { set_pte(ptep, pte_wrprotect(*ptep)); @@ -511,7 +507,8 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr, #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG -#define __HAVE_ARCH_PTEP_GET_AND_CLEAR +#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH +#define __HAVE_ARCH_PTEP_CLEAR_FLUSH #define __HAVE_ARCH_PTEP_SET_WRPROTECT #define __HAVE_ARCH_PTE_SAME diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c index 393822f16727..f7953b0391cf 100644 --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -20,6 +20,7 @@ #include <linux/sched.h> #include <linux/sched/mm.h> #include <linux/syscalls.h> +#include <linux/vmalloc.h> #include <asm/pdc.h> #include <asm/cache.h> #include <asm/cacheflush.h> @@ -31,20 +32,31 @@ #include <asm/mmu_context.h> #include <asm/cachectl.h> +#define PTR_PAGE_ALIGN_DOWN(addr) PTR_ALIGN_DOWN(addr, PAGE_SIZE) + +/* + * When nonzero, use _PAGE_ACCESSED bit to try to reduce the number + * of page flushes done flush_cache_page_if_present. There are some + * pros and cons in using this option. It may increase the risk of + * random segmentation faults. + */ +#define CONFIG_FLUSH_PAGE_ACCESSED 0 + int split_tlb __ro_after_init; int dcache_stride __ro_after_init; int icache_stride __ro_after_init; EXPORT_SYMBOL(dcache_stride); +/* Internal implementation in arch/parisc/kernel/pacache.S */ void flush_dcache_page_asm(unsigned long phys_addr, unsigned long vaddr); EXPORT_SYMBOL(flush_dcache_page_asm); void purge_dcache_page_asm(unsigned long phys_addr, unsigned long vaddr); void flush_icache_page_asm(unsigned long phys_addr, unsigned long vaddr); - -/* Internal implementation in arch/parisc/kernel/pacache.S */ void flush_data_cache_local(void *); /* flushes local data-cache only */ void flush_instruction_cache_local(void); /* flushes local code-cache only */ +static void flush_kernel_dcache_page_addr(const void *addr); + /* On some machines (i.e., ones with the Merced bus), there can be * only a single PxTLB broadcast at a time; this must be guaranteed * by software. We need a spinlock around all TLB flushes to ensure @@ -317,6 +329,18 @@ __flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, { if (!static_branch_likely(&parisc_has_cache)) return; + + /* + * The TLB is the engine of coherence on parisc. The CPU is + * entitled to speculate any page with a TLB mapping, so here + * we kill the mapping then flush the page along a special flush + * only alias mapping. This guarantees that the page is no-longer + * in the cache for any process and nor may it be speculatively + * read in (until the user or kernel specifically accesses it, + * of course). + */ + flush_tlb_page(vma, vmaddr); + preempt_disable(); flush_dcache_page_asm(physaddr, vmaddr); if (vma->vm_flags & VM_EXEC) @@ -324,46 +348,44 @@ __flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, preempt_enable(); } -static void flush_user_cache_page(struct vm_area_struct *vma, unsigned long vmaddr) +static void flush_kernel_dcache_page_addr(const void *addr) { - unsigned long flags, space, pgd, prot; -#ifdef CONFIG_TLB_PTLOCK - unsigned long pgd_lock; -#endif + unsigned long vaddr = (unsigned long)addr; + unsigned long flags; - vmaddr &= PAGE_MASK; + /* Purge TLB entry to remove translation on all CPUs */ + purge_tlb_start(flags); + pdtlb(SR_KERNEL, addr); + purge_tlb_end(flags); + /* Use tmpalias flush to prevent data cache move-in */ preempt_disable(); + flush_dcache_page_asm(__pa(vaddr), vaddr); + preempt_enable(); +} - /* Set context for flush */ - local_irq_save(flags); - prot = mfctl(8); - space = mfsp(SR_USER); - pgd = mfctl(25); -#ifdef CONFIG_TLB_PTLOCK - pgd_lock = mfctl(28); -#endif - switch_mm_irqs_off(NULL, vma->vm_mm, NULL); - local_irq_restore(flags); - - flush_user_dcache_range_asm(vmaddr, vmaddr + PAGE_SIZE); - if (vma->vm_flags & VM_EXEC) - flush_user_icache_range_asm(vmaddr, vmaddr + PAGE_SIZE); - flush_tlb_page(vma, vmaddr); +static void flush_kernel_icache_page_addr(const void *addr) +{ + unsigned long vaddr = (unsigned long)addr; + unsigned long flags; - /* Restore previous context */ - local_irq_save(flags); -#ifdef CONFIG_TLB_PTLOCK - mtctl(pgd_lock, 28); -#endif - mtctl(pgd, 25); - mtsp(space, SR_USER); - mtctl(prot, 8); - local_irq_restore(flags); + /* Purge TLB entry to remove translation on all CPUs */ + purge_tlb_start(flags); + pdtlb(SR_KERNEL, addr); + purge_tlb_end(flags); + /* Use tmpalias flush to prevent instruction cache move-in */ + preempt_disable(); + flush_icache_page_asm(__pa(vaddr), vaddr); preempt_enable(); } +void kunmap_flush_on_unmap(const void *addr) +{ + flush_kernel_dcache_page_addr(addr); +} +EXPORT_SYMBOL(kunmap_flush_on_unmap); + void flush_icache_pages(struct vm_area_struct *vma, struct page *page, unsigned int nr) { @@ -371,13 +393,16 @@ void flush_icache_pages(struct vm_area_struct *vma, struct page *page, for (;;) { flush_kernel_dcache_page_addr(kaddr); - flush_kernel_icache_page(kaddr); + flush_kernel_icache_page_addr(kaddr); if (--nr == 0) break; kaddr += PAGE_SIZE; } } +/* + * Walk page directory for MM to find PTEP pointer for address ADDR. + */ static inline pte_t *get_ptep(struct mm_struct *mm, unsigned long addr) { pte_t *ptep = NULL; @@ -406,6 +431,41 @@ static inline bool pte_needs_flush(pte_t pte) == (_PAGE_PRESENT | _PAGE_ACCESSED); } +/* + * Return user physical address. Returns 0 if page is not present. + */ +static inline unsigned long get_upa(struct mm_struct *mm, unsigned long addr) +{ + unsigned long flags, space, pgd, prot, pa; +#ifdef CONFIG_TLB_PTLOCK + unsigned long pgd_lock; +#endif + + /* Save context */ + local_irq_save(flags); + prot = mfctl(8); + space = mfsp(SR_USER); + pgd = mfctl(25); +#ifdef CONFIG_TLB_PTLOCK + pgd_lock = mfctl(28); +#endif + + /* Set context for lpa_user */ + switch_mm_irqs_off(NULL, mm, NULL); + pa = lpa_user(addr); + + /* Restore previous context */ +#ifdef CONFIG_TLB_PTLOCK + mtctl(pgd_lock, 28); +#endif + mtctl(pgd, 25); + mtsp(space, SR_USER); + mtctl(prot, 8); + local_irq_restore(flags); + + return pa; +} + void flush_dcache_folio(struct folio *folio) { struct address_space *mapping = folio_flush_mapping(folio); @@ -454,50 +514,23 @@ void flush_dcache_folio(struct folio *folio) if (addr + nr * PAGE_SIZE > vma->vm_end) nr = (vma->vm_end - addr) / PAGE_SIZE; - if (parisc_requires_coherency()) { - for (i = 0; i < nr; i++) { - pte_t *ptep = get_ptep(vma->vm_mm, - addr + i * PAGE_SIZE); - if (!ptep) - continue; - if (pte_needs_flush(*ptep)) - flush_user_cache_page(vma, - addr + i * PAGE_SIZE); - /* Optimise accesses to the same table? */ - pte_unmap(ptep); - } - } else { + if (old_addr == 0 || (old_addr & (SHM_COLOUR - 1)) + != (addr & (SHM_COLOUR - 1))) { + for (i = 0; i < nr; i++) + __flush_cache_page(vma, + addr + i * PAGE_SIZE, + (pfn + i) * PAGE_SIZE); /* - * The TLB is the engine of coherence on parisc: - * The CPU is entitled to speculate any page - * with a TLB mapping, so here we kill the - * mapping then flush the page along a special - * flush only alias mapping. This guarantees that - * the page is no-longer in the cache for any - * process and nor may it be speculatively read - * in (until the user or kernel specifically - * accesses it, of course) + * Software is allowed to have any number + * of private mappings to a page. */ - for (i = 0; i < nr; i++) - flush_tlb_page(vma, addr + i * PAGE_SIZE); - if (old_addr == 0 || (old_addr & (SHM_COLOUR - 1)) - != (addr & (SHM_COLOUR - 1))) { - for (i = 0; i < nr; i++) - __flush_cache_page(vma, - addr + i * PAGE_SIZE, - (pfn + i) * PAGE_SIZE); - /* - * Software is allowed to have any number - * of private mappings to a page. - */ - if (!(vma->vm_flags & VM_SHARED)) - continue; - if (old_addr) - pr_err("INEQUIVALENT ALIASES 0x%lx and 0x%lx in file %pD\n", - old_addr, addr, vma->vm_file); - if (nr == folio_nr_pages(folio)) - old_addr = addr; - } + if (!(vma->vm_flags & VM_SHARED)) + continue; + if (old_addr) + pr_err("INEQUIVALENT ALIASES 0x%lx and 0x%lx in file %pD\n", + old_addr, addr, vma->vm_file); + if (nr == folio_nr_pages(folio)) + old_addr = addr; } WARN_ON(++count == 4096); } @@ -587,35 +620,28 @@ extern void purge_kernel_dcache_page_asm(unsigned long); extern void clear_user_page_asm(void *, unsigned long); extern void copy_user_page_asm(void *, void *, unsigned long); -void flush_kernel_dcache_page_addr(const void *addr) -{ - unsigned long flags; - - flush_kernel_dcache_page_asm(addr); - purge_tlb_start(flags); - pdtlb(SR_KERNEL, addr); - purge_tlb_end(flags); -} -EXPORT_SYMBOL(flush_kernel_dcache_page_addr); - static void flush_cache_page_if_present(struct vm_area_struct *vma, - unsigned long vmaddr, unsigned long pfn) + unsigned long vmaddr) { +#if CONFIG_FLUSH_PAGE_ACCESSED bool needs_flush = false; - pte_t *ptep; + pte_t *ptep, pte; - /* - * The pte check is racy and sometimes the flush will trigger - * a non-access TLB miss. Hopefully, the page has already been - * flushed. - */ ptep = get_ptep(vma->vm_mm, vmaddr); if (ptep) { - needs_flush = pte_needs_flush(*ptep); + pte = ptep_get(ptep); + needs_flush = pte_needs_flush(pte); pte_unmap(ptep); } if (needs_flush) - flush_cache_page(vma, vmaddr, pfn); + __flush_cache_page(vma, vmaddr, PFN_PHYS(pte_pfn(pte))); +#else + struct mm_struct *mm = vma->vm_mm; + unsigned long physaddr = get_upa(mm, vmaddr); + + if (physaddr) + __flush_cache_page(vma, vmaddr, PAGE_ALIGN_DOWN(physaddr)); +#endif } void copy_user_highpage(struct page *to, struct page *from, @@ -625,7 +651,7 @@ void copy_user_highpage(struct page *to, struct page *from, kfrom = kmap_local_page(from); kto = kmap_local_page(to); - flush_cache_page_if_present(vma, vaddr, page_to_pfn(from)); + __flush_cache_page(vma, vaddr, PFN_PHYS(page_to_pfn(from))); copy_page_asm(kto, kfrom); kunmap_local(kto); kunmap_local(kfrom); @@ -634,16 +660,17 @@ void copy_user_highpage(struct page *to, struct page *from, void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len) { - flush_cache_page_if_present(vma, user_vaddr, page_to_pfn(page)); + __flush_cache_page(vma, user_vaddr, PFN_PHYS(page_to_pfn(page))); memcpy(dst, src, len); - flush_kernel_dcache_range_asm((unsigned long)dst, (unsigned long)dst + len); + flush_kernel_dcache_page_addr(PTR_PAGE_ALIGN_DOWN(dst)); } void copy_from_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len) { - flush_cache_page_if_present(vma, user_vaddr, page_to_pfn(page)); + __flush_cache_page(vma, user_vaddr, PFN_PHYS(page_to_pfn(page))); memcpy(dst, src, len); + flush_kernel_dcache_page_addr(PTR_PAGE_ALIGN_DOWN(src)); } /* __flush_tlb_range() @@ -677,32 +704,10 @@ int __flush_tlb_range(unsigned long sid, unsigned long start, static void flush_cache_pages(struct vm_area_struct *vma, unsigned long start, unsigned long end) { - unsigned long addr, pfn; - pte_t *ptep; - - for (addr = start; addr < end; addr += PAGE_SIZE) { - bool needs_flush = false; - /* - * The vma can contain pages that aren't present. Although - * the pte search is expensive, we need the pte to find the - * page pfn and to check whether the page should be flushed. - */ - ptep = get_ptep(vma->vm_mm, addr); - if (ptep) { - needs_flush = pte_needs_flush(*ptep); - pfn = pte_pfn(*ptep); - pte_unmap(ptep); - } - if (needs_flush) { - if (parisc_requires_coherency()) { - flush_user_cache_page(vma, addr); - } else { - if (WARN_ON(!pfn_valid(pfn))) - return; - __flush_cache_page(vma, addr, PFN_PHYS(pfn)); - } - } - } + unsigned long addr; + + for (addr = start; addr < end; addr += PAGE_SIZE) + flush_cache_page_if_present(vma, addr); } static inline unsigned long mm_total_size(struct mm_struct *mm) @@ -753,21 +758,19 @@ void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned if (WARN_ON(IS_ENABLED(CONFIG_SMP) && arch_irqs_disabled())) return; flush_tlb_range(vma, start, end); - flush_cache_all(); + if (vma->vm_flags & VM_EXEC) + flush_cache_all(); + else + flush_data_cache(); return; } - flush_cache_pages(vma, start, end); + flush_cache_pages(vma, start & PAGE_MASK, end); } void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long pfn) { - if (WARN_ON(!pfn_valid(pfn))) - return; - if (parisc_requires_coherency()) - flush_user_cache_page(vma, vmaddr); - else - __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn)); + __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn)); } void flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vmaddr) @@ -775,34 +778,133 @@ void flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned lon if (!PageAnon(page)) return; - if (parisc_requires_coherency()) { - if (vma->vm_flags & VM_SHARED) - flush_data_cache(); - else - flush_user_cache_page(vma, vmaddr); + __flush_cache_page(vma, vmaddr, PFN_PHYS(page_to_pfn(page))); +} + +int ptep_clear_flush_young(struct vm_area_struct *vma, unsigned long addr, + pte_t *ptep) +{ + pte_t pte = ptep_get(ptep); + + if (!pte_young(pte)) + return 0; + set_pte(ptep, pte_mkold(pte)); +#if CONFIG_FLUSH_PAGE_ACCESSED + __flush_cache_page(vma, addr, PFN_PHYS(pte_pfn(pte))); +#endif + return 1; +} + +/* + * After a PTE is cleared, we have no way to flush the cache for + * the physical page. On PA8800 and PA8900 processors, these lines + * can cause random cache corruption. Thus, we must flush the cache + * as well as the TLB when clearing a PTE that's valid. + */ +pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long addr, + pte_t *ptep) +{ + struct mm_struct *mm = (vma)->vm_mm; + pte_t pte = ptep_get_and_clear(mm, addr, ptep); + unsigned long pfn = pte_pfn(pte); + + if (pfn_valid(pfn)) + __flush_cache_page(vma, addr, PFN_PHYS(pfn)); + else if (pte_accessible(mm, pte)) + flush_tlb_page(vma, addr); + + return pte; +} + +/* + * The physical address for pages in the ioremap case can be obtained + * from the vm_struct struct. I wasn't able to successfully handle the + * vmalloc and vmap cases. We have an array of struct page pointers in + * the uninitialized vmalloc case but the flush failed using page_to_pfn. + */ +void flush_cache_vmap(unsigned long start, unsigned long end) +{ + unsigned long addr, physaddr; + struct vm_struct *vm; + + /* Prevent cache move-in */ + flush_tlb_kernel_range(start, end); + + if (end - start >= parisc_cache_flush_threshold) { + flush_cache_all(); return; } - flush_tlb_page(vma, vmaddr); - preempt_disable(); - flush_dcache_page_asm(page_to_phys(page), vmaddr); - preempt_enable(); + if (WARN_ON_ONCE(!is_vmalloc_addr((void *)start))) { + flush_cache_all(); + return; + } + + vm = find_vm_area((void *)start); + if (WARN_ON_ONCE(!vm)) { + flush_cache_all(); + return; + } + + /* The physical addresses of IOREMAP regions are contiguous */ + if (vm->flags & VM_IOREMAP) { + physaddr = vm->phys_addr; + for (addr = start; addr < end; addr += PAGE_SIZE) { + preempt_disable(); + flush_dcache_page_asm(physaddr, start); + flush_icache_page_asm(physaddr, start); + preempt_enable(); + physaddr += PAGE_SIZE; + } + return; + } + + flush_cache_all(); } +EXPORT_SYMBOL(flush_cache_vmap); +/* + * The vm_struct has been retired and the page table is set up. The + * last page in the range is a guard page. Its physical address can't + * be determined using lpa, so there is no way to flush the range + * using flush_dcache_page_asm. + */ +void flush_cache_vunmap(unsigned long start, unsigned long end) +{ + /* Prevent cache move-in */ + flush_tlb_kernel_range(start, end); + flush_data_cache(); +} +EXPORT_SYMBOL(flush_cache_vunmap); + +/* + * On systems with PA8800/PA8900 processors, there is no way to flush + * a vmap range other than using the architected loop to flush the + * entire cache. The page directory is not set up, so we can't use + * fdc, etc. FDCE/FICE don't work to flush a portion of the cache. + * L2 is physically indexed but FDCE/FICE instructions in virtual + * mode output their virtual address on the core bus, not their + * real address. As a result, the L2 cache index formed from the + * virtual address will most likely not be the same as the L2 index + * formed from the real address. + */ void flush_kernel_vmap_range(void *vaddr, int size) { unsigned long start = (unsigned long)vaddr; unsigned long end = start + size; - if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && - (unsigned long)size >= parisc_cache_flush_threshold) { - flush_tlb_kernel_range(start, end); - flush_data_cache(); + flush_tlb_kernel_range(start, end); + + if (!static_branch_likely(&parisc_has_dcache)) + return; + + /* If interrupts are disabled, we can only do local flush */ + if (WARN_ON(IS_ENABLED(CONFIG_SMP) && arch_irqs_disabled())) { + flush_data_cache_local(NULL); return; } - flush_kernel_dcache_range_asm(start, end); - flush_tlb_kernel_range(start, end); + flush_data_cache(); } EXPORT_SYMBOL(flush_kernel_vmap_range); @@ -814,15 +916,18 @@ void invalidate_kernel_vmap_range(void *vaddr, int size) /* Ensure DMA is complete */ asm_syncdma(); - if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && - (unsigned long)size >= parisc_cache_flush_threshold) { - flush_tlb_kernel_range(start, end); - flush_data_cache(); + flush_tlb_kernel_range(start, end); + + if (!static_branch_likely(&parisc_has_dcache)) + return; + + /* If interrupts are disabled, we can only do local flush */ + if (WARN_ON(IS_ENABLED(CONFIG_SMP) && arch_irqs_disabled())) { + flush_data_cache_local(NULL); return; } - purge_kernel_dcache_range_asm(start, end); - flush_tlb_kernel_range(start, end); + flush_data_cache(); } EXPORT_SYMBOL(invalidate_kernel_vmap_range); -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] kvm: add coda feature
by l00500167 15 Jul '24

15 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 9 +++++++++ 2 files changed, 23 insertions(+) -- 2.25.1

2 2

[PATCH OLK-5.10 0/2] CVE-2024-40972
by Yifan Qiao 15 Jul '24

15 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 154 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 81 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-40972
by Yifan Qiao 15 Jul '24

15 Jul '24

Jan Kara (2): ext4: fold quota accounting into ext4_xattr_inode_lookup_create() ext4: do not create EA inode under buffer lock fs/ext4/xattr.c | 154 +++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 81 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6] drm/komeda: check for error-valued pointer
by Zeng Heng 15 Jul '24

15 Jul '24

From: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> stable inclusion from stable-v6.6.35 commit 9460961d82134ceda7377b77a3e3e3531b625dfe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQYC CVE: CVE-2024-39505 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b880018edd3a577e50366338194dee9b899947e0 ] komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing. Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE") Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610102056.40406-1-amjad.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index f3e744172673..f4e76b46ca32 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component *c, u32 avail_scalers; pipe_st = komeda_pipeline_get_state(c->pipeline, state); - if (!pipe_st) + if (IS_ERR_OR_NULL(pipe_st)) return NULL; avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/komeda: check for error-valued pointer
by Zeng Heng 15 Jul '24

15 Jul '24

From: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> stable inclusion from stable-v5.10.221 commit bda7cdaeebf57e46c1a488ae7a15f6f264691f59 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQYC CVE: CVE-2024-39505 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b880018edd3a577e50366338194dee9b899947e0 ] komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing. Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE") Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610102056.40406-1-amjad.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index c3cdf283ecef..6e115782bf89 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component *c, u32 avail_scalers; pipe_st = komeda_pipeline_get_state(c->pipeline, state); - if (!pipe_st) + if (IS_ERR_OR_NULL(pipe_st)) return NULL; avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^ -- 2.25.1

2 1

[PATCH OLK-5.10] drm/komeda: check for error-valued pointer
by Zeng Heng 15 Jul '24

15 Jul '24

From: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> stable inclusion from stable-v5.10.221 commit bda7cdaeebf57e46c1a488ae7a15f6f264691f59 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQYC CVE: CVE-2024-39505 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b880018edd3a577e50366338194dee9b899947e0 ] komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing. Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE") Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur(a)arm.com> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610102056.40406-1-amjad.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index c3cdf283ecef..6e115782bf89 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component *c, u32 avail_scalers; pipe_st = komeda_pipeline_get_state(c->pipeline, state); - if (!pipe_st) + if (IS_ERR_OR_NULL(pipe_st)) return NULL; avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^ -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] kvm: add cvm coda feature
by l00500167 15 Jul '24

15 Jul '24

virtCCA feature l00500167 (1): kvm: add coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 4 +++- 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v5.10.221 commit 38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZP CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/f2fs/super.c [Context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index fba413ced982..565289233b3b 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1714,8 +1714,6 @@ static void default_options(struct f2fs_sb_info *sbi) F2FS_OPTION(sbi).compress_ext_cnt = 0; F2FS_OPTION(sbi).bggc_mode = BGGC_MODE_ON; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH OLK-5.10] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v5.10.221 commit 38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZP CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/f2fs/super.c [Context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 6a214366970c..daa31574acfb 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1713,8 +1713,6 @@ static void default_options(struct f2fs_sb_info *sbi) F2FS_OPTION(sbi).compress_ext_cnt = 0; F2FS_OPTION(sbi).bggc_mode = BGGC_MODE_ON; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH OLK-6.6 0/2] CVE-2024-40955
by Yifan Qiao 15 Jul '24

15 Jul '24

Baokun Li (2): ext4: avoid overflow when setting values via sysfs ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 24 ++++++++++++++++++------ 2 files changed, 22 insertions(+), 6 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS] ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
by Zeng Heng 15 Jul '24

15 Jul '24

From: Raju Rangoju <Raju.Rangoju(a)amd.com> stable inclusion from stable-v4.19.317 commit 435ecc978c3d5d0c4e172ec5b956dc1904061d98 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD09L CVE: CVE-2024-40984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a83e1385b780d41307433ddbc86e3c528db031f0 ] Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. Link: https://github.com/acpica/acpica/pull/954 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849 Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."") Co-developed-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju(a)amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/acpi/acpica/exregion.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c index 97bbfd07fcf7..2d99cbbf82d1 100644 --- a/drivers/acpi/acpica/exregion.c +++ b/drivers/acpi/acpica/exregion.c @@ -43,7 +43,6 @@ acpi_ex_system_memory_space_handler(u32 function, struct acpi_mem_space_context *mem_info = region_context; u32 length; acpi_size map_length; - acpi_size page_boundary_map_length; #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED u32 remainder; #endif @@ -120,26 +119,8 @@ acpi_ex_system_memory_space_handler(u32 function, map_length = (acpi_size) ((mem_info->address + mem_info->length) - address); - /* - * If mapping the entire remaining portion of the region will cross - * a page boundary, just map up to the page boundary, do not cross. - * On some systems, crossing a page boundary while mapping regions - * can cause warnings if the pages have different attributes - * due to resource management. - * - * This has the added benefit of constraining a single mapping to - * one page, which is similar to the original code that used a 4k - * maximum window. - */ - page_boundary_map_length = (acpi_size) - (ACPI_ROUND_UP(address, ACPI_DEFAULT_PAGE_SIZE) - address); - if (page_boundary_map_length == 0) { - page_boundary_map_length = ACPI_DEFAULT_PAGE_SIZE; - } - - if (map_length > page_boundary_map_length) { - map_length = page_boundary_map_length; - } + if (map_length > ACPI_DEFAULT_PAGE_SIZE) + map_length = ACPI_DEFAULT_PAGE_SIZE; /* Create a new mapping starting at the address given */ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
by Zeng Heng 15 Jul '24

15 Jul '24

From: Raju Rangoju <Raju.Rangoju(a)amd.com> stable inclusion from stable-v5.10.221 commit 6eca23100e9030725f69c1babacd58803f29ec8d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD09L CVE: CVE-2024-40984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a83e1385b780d41307433ddbc86e3c528db031f0 ] Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. Link: https://github.com/acpica/acpica/pull/954 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849 Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."") Co-developed-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju(a)amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/acpi/acpica/exregion.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c index 4914dbc44517..5bbbd015de5a 100644 --- a/drivers/acpi/acpica/exregion.c +++ b/drivers/acpi/acpica/exregion.c @@ -44,7 +44,6 @@ acpi_ex_system_memory_space_handler(u32 function, struct acpi_mem_mapping *mm = mem_info->cur_mm; u32 length; acpi_size map_length; - acpi_size page_boundary_map_length; #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED u32 remainder; #endif @@ -138,26 +137,8 @@ acpi_ex_system_memory_space_handler(u32 function, map_length = (acpi_size) ((mem_info->address + mem_info->length) - address); - /* - * If mapping the entire remaining portion of the region will cross - * a page boundary, just map up to the page boundary, do not cross. - * On some systems, crossing a page boundary while mapping regions - * can cause warnings if the pages have different attributes - * due to resource management. - * - * This has the added benefit of constraining a single mapping to - * one page, which is similar to the original code that used a 4k - * maximum window. - */ - page_boundary_map_length = (acpi_size) - (ACPI_ROUND_UP(address, ACPI_DEFAULT_PAGE_SIZE) - address); - if (page_boundary_map_length == 0) { - page_boundary_map_length = ACPI_DEFAULT_PAGE_SIZE; - } - - if (map_length > page_boundary_map_length) { - map_length = page_boundary_map_length; - } + if (map_length > ACPI_DEFAULT_PAGE_SIZE) + map_length = ACPI_DEFAULT_PAGE_SIZE; /* Create a new mapping starting at the address given */ -- 2.25.1

2 1

[PATCH OLK-5.10] ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
by Zeng Heng 15 Jul '24

15 Jul '24

From: Raju Rangoju <Raju.Rangoju(a)amd.com> stable inclusion from stable-v5.10.221 commit 6eca23100e9030725f69c1babacd58803f29ec8d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD09L CVE: CVE-2024-40984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a83e1385b780d41307433ddbc86e3c528db031f0 ] Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. Link: https://github.com/acpica/acpica/pull/954 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849 Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."") Co-developed-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju(a)amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/acpi/acpica/exregion.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c index 4914dbc44517..5bbbd015de5a 100644 --- a/drivers/acpi/acpica/exregion.c +++ b/drivers/acpi/acpica/exregion.c @@ -44,7 +44,6 @@ acpi_ex_system_memory_space_handler(u32 function, struct acpi_mem_mapping *mm = mem_info->cur_mm; u32 length; acpi_size map_length; - acpi_size page_boundary_map_length; #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED u32 remainder; #endif @@ -138,26 +137,8 @@ acpi_ex_system_memory_space_handler(u32 function, map_length = (acpi_size) ((mem_info->address + mem_info->length) - address); - /* - * If mapping the entire remaining portion of the region will cross - * a page boundary, just map up to the page boundary, do not cross. - * On some systems, crossing a page boundary while mapping regions - * can cause warnings if the pages have different attributes - * due to resource management. - * - * This has the added benefit of constraining a single mapping to - * one page, which is similar to the original code that used a 4k - * maximum window. - */ - page_boundary_map_length = (acpi_size) - (ACPI_ROUND_UP(address, ACPI_DEFAULT_PAGE_SIZE) - address); - if (page_boundary_map_length == 0) { - page_boundary_map_length = ACPI_DEFAULT_PAGE_SIZE; - } - - if (map_length > page_boundary_map_length) { - map_length = page_boundary_map_length; - } + if (map_length > ACPI_DEFAULT_PAGE_SIZE) + map_length = ACPI_DEFAULT_PAGE_SIZE; /* Create a new mapping starting at the address given */ -- 2.25.1

2 1

[PATCH OLK-6.6] ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
by Zeng Heng 15 Jul '24

15 Jul '24

From: Raju Rangoju <Raju.Rangoju(a)amd.com> stable inclusion from stable-v6.6.36 commit 434c6b924e1f4c219aab2d9e05fe79c5364e37d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD09L CVE: CVE-2024-40984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a83e1385b780d41307433ddbc86e3c528db031f0 ] Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. Link: https://github.com/acpica/acpica/pull/954 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849 Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."") Co-developed-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Sanath S <Sanath.S(a)amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju(a)amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/acpi/acpica/exregion.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c index 8907b8bf4267..c49b9f8de723 100644 --- a/drivers/acpi/acpica/exregion.c +++ b/drivers/acpi/acpica/exregion.c @@ -44,7 +44,6 @@ acpi_ex_system_memory_space_handler(u32 function, struct acpi_mem_mapping *mm = mem_info->cur_mm; u32 length; acpi_size map_length; - acpi_size page_boundary_map_length; #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED u32 remainder; #endif @@ -138,26 +137,8 @@ acpi_ex_system_memory_space_handler(u32 function, map_length = (acpi_size) ((mem_info->address + mem_info->length) - address); - /* - * If mapping the entire remaining portion of the region will cross - * a page boundary, just map up to the page boundary, do not cross. - * On some systems, crossing a page boundary while mapping regions - * can cause warnings if the pages have different attributes - * due to resource management. - * - * This has the added benefit of constraining a single mapping to - * one page, which is similar to the original code that used a 4k - * maximum window. - */ - page_boundary_map_length = (acpi_size) - (ACPI_ROUND_UP(address, ACPI_DEFAULT_PAGE_SIZE) - address); - if (page_boundary_map_length == 0) { - page_boundary_map_length = ACPI_DEFAULT_PAGE_SIZE; - } - - if (map_length > page_boundary_map_length) { - map_length = page_boundary_map_length; - } + if (map_length > ACPI_DEFAULT_PAGE_SIZE) + map_length = ACPI_DEFAULT_PAGE_SIZE; /* Create a new mapping starting at the address given */ -- 2.25.1

2 1

[PATCH OLK-6.6 1/1] kvm: add coda feature
by l00500167 15 Jul '24

15 Jul '24

virtCCA feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 4 +++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729..0f2acb4ed 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -625,6 +625,9 @@ struct arm_smmu_strtab_l1_desc { struct arm_smmu_ste *l2ptr; dma_addr_t l2ptr_dma; +#ifdef CONFIG_CVM_HOST + bool is_sync; +#endif }; struct arm_smmu_ctx_desc { @@ -750,6 +753,12 @@ struct arm_smmu_device { struct mutex streams_mutex; bool bypass; +#ifdef CONFIG_CVM_HOST + int s_evtq_irq; + int s_gerr_irq; + resource_size_t ioaddr; + uint64_t id; +#endif }; struct arm_smmu_stream { @@ -802,6 +811,11 @@ struct arm_smmu_domain { spinlock_t devices_lock; struct list_head mmu_notifiers; +#ifdef CONFIG_CVM_HOST + bool secure; + struct list_head node; + struct kvm *kvm; +#endif }; static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0..840a3b89f 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -635,7 +635,9 @@ struct iommu_ops { struct iommu_domain *blocked_domain; struct iommu_domain *default_domain; - KABI_RESERVE(1) +#ifdef CONFIG_CVM_HOST + int (*iommu_enable_secure)(struct iommu_domain *domain); +#endif KABI_RESERVE(2) KABI_RESERVE(3) KABI_RESERVE(4) -- 2.25.1

2 1

[PATCH OLK-6.6 1/1] kvm: add coda feature
by l00500167 15 Jul '24

15 Jul '24

virtcca feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 4 +++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729..0f2acb4ed 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -625,6 +625,9 @@ struct arm_smmu_strtab_l1_desc { struct arm_smmu_ste *l2ptr; dma_addr_t l2ptr_dma; +#ifdef CONFIG_CVM_HOST + bool is_sync; +#endif }; struct arm_smmu_ctx_desc { @@ -750,6 +753,12 @@ struct arm_smmu_device { struct mutex streams_mutex; bool bypass; +#ifdef CONFIG_CVM_HOST + int s_evtq_irq; + int s_gerr_irq; + resource_size_t ioaddr; + uint64_t id; +#endif }; struct arm_smmu_stream { @@ -802,6 +811,11 @@ struct arm_smmu_domain { spinlock_t devices_lock; struct list_head mmu_notifiers; +#ifdef CONFIG_CVM_HOST + bool secure; + struct list_head node; + struct kvm *kvm; +#endif }; static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0..840a3b89f 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -635,7 +635,9 @@ struct iommu_ops { struct iommu_domain *blocked_domain; struct iommu_domain *default_domain; - KABI_RESERVE(1) +#ifdef CONFIG_CVM_HOST + int (*iommu_enable_secure)(struct iommu_domain *domain); +#endif KABI_RESERVE(2) KABI_RESERVE(3) KABI_RESERVE(4) -- 2.25.1

2 1

[PATCH OLK-6.6 1/1] kvm: add coda feature
by l00500167 15 Jul '24

15 Jul '24

virtcca coda feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 4 +++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729..0f2acb4ed 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -625,6 +625,9 @@ struct arm_smmu_strtab_l1_desc { struct arm_smmu_ste *l2ptr; dma_addr_t l2ptr_dma; +#ifdef CONFIG_CVM_HOST + bool is_sync; +#endif }; struct arm_smmu_ctx_desc { @@ -750,6 +753,12 @@ struct arm_smmu_device { struct mutex streams_mutex; bool bypass; +#ifdef CONFIG_CVM_HOST + int s_evtq_irq; + int s_gerr_irq; + resource_size_t ioaddr; + uint64_t id; +#endif }; struct arm_smmu_stream { @@ -802,6 +811,11 @@ struct arm_smmu_domain { spinlock_t devices_lock; struct list_head mmu_notifiers; +#ifdef CONFIG_CVM_HOST + bool secure; + struct list_head node; + struct kvm *kvm; +#endif }; static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0..840a3b89f 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -635,7 +635,9 @@ struct iommu_ops { struct iommu_domain *blocked_domain; struct iommu_domain *default_domain; - KABI_RESERVE(1) +#ifdef CONFIG_CVM_HOST + int (*iommu_enable_secure)(struct iommu_domain *domain); +#endif KABI_RESERVE(2) KABI_RESERVE(3) KABI_RESERVE(4) -- 2.25.1

2 1

[PATCH OLK-6.6] kvm: add coda feature
by l00500167 15 Jul '24

15 Jul '24

virtcca feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 3 +++ 2 files changed, 17 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729..0f2acb4ed 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -625,6 +625,9 @@ struct arm_smmu_strtab_l1_desc { struct arm_smmu_ste *l2ptr; dma_addr_t l2ptr_dma; +#ifdef CONFIG_CVM_HOST + bool is_sync; +#endif }; struct arm_smmu_ctx_desc { @@ -750,6 +753,12 @@ struct arm_smmu_device { struct mutex streams_mutex; bool bypass; +#ifdef CONFIG_CVM_HOST + int s_evtq_irq; + int s_gerr_irq; + resource_size_t ioaddr; + uint64_t id; +#endif }; struct arm_smmu_stream { @@ -802,6 +811,11 @@ struct arm_smmu_domain { spinlock_t devices_lock; struct list_head mmu_notifiers; +#ifdef CONFIG_CVM_HOST + bool secure; + struct list_head node; + struct kvm *kvm; +#endif }; static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0..e3186fbd4 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -635,6 +635,9 @@ struct iommu_ops { struct iommu_domain *blocked_domain; struct iommu_domain *default_domain; +#ifdef CONFIG_CVM_HOST + int (*iommu_enable_secure)(struct iommu_domain *domain); +#endif - KABI_RESERVE(1) KABI_RESERVE(2) KABI_RESERVE(3) -- 2.25.1

2 2

[PATCH OLK-6.6] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v6.6.36 commit eddeb8d941d5be11a9da5637dbe81ac37e8449a2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZP CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index b1a239f3eb66..534d8bb1f26c 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -2186,8 +2186,6 @@ static void default_options(struct f2fs_sb_info *sbi, bool remount) F2FS_OPTION(sbi).memory_mode = MEMORY_MODE_NORMAL; F2FS_OPTION(sbi).errors = MOUNT_ERRORS_CONTINUE; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH OLK-5.10] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v5.10.221 commit 38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZP CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/f2f2/super.c [Context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 6a214366970c..daa31574acfb 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1713,8 +1713,6 @@ static void default_options(struct f2fs_sb_info *sbi) F2FS_OPTION(sbi).compress_ext_cnt = 0; F2FS_OPTION(sbi).bggc_mode = BGGC_MODE_ON; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v5.10.221 commit 38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZZP CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/f2f2/super.c [Context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index fba413ced982..565289233b3b 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1714,8 +1714,6 @@ static void default_options(struct f2fs_sb_info *sbi) F2FS_OPTION(sbi).compress_ext_cnt = 0; F2FS_OPTION(sbi).bggc_mode = BGGC_MODE_ON; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] f2fs: remove clear SB_INLINECRYPT flag in default_options
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Yunlei He <heyunlei(a)oppo.com> stable inclusion from stable-v5.10.221 commit 38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 category: bugfix bugzilla: 190178 CVE: CVE-2024-40971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ] In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Signed-off-by: Yunlei He <heyunlei(a)oppo.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/f2f2/super.c [Context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index fba413ced982..565289233b3b 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1714,8 +1714,6 @@ static void default_options(struct f2fs_sb_info *sbi) F2FS_OPTION(sbi).compress_ext_cnt = 0; F2FS_OPTION(sbi).bggc_mode = BGGC_MODE_ON; - sbi->sb->s_flags &= ~SB_INLINECRYPT; - set_opt(sbi, INLINE_XATTR); set_opt(sbi, INLINE_DATA); set_opt(sbi, INLINE_DENTRY); -- 2.39.2

2 1

[PATCH OLK-6.6] ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Baokun Li <libaokun1(a)huawei.com> stable inclusion from stable-v6.6.36 commit 677ff4589f1501578fa903a25bb14831d0607992 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD018 CVE: CVE-2024-40955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 13df4d44a3aaabe61cd01d277b6ee23ead2a5206 upstream. We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops. Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> Link: https://lore.kernel.org/r/20240319113325.3110393-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 13 ++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index f6e02978d0e6..9a65cdcc6417 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -834,6 +834,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) return 0; if (order == MB_NUM_ORDERS(sb)) order--; + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) + order = MB_NUM_ORDERS(sb) - 1; return order; } @@ -1011,6 +1013,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context * goal length. */ order = fls(ac->ac_g_ex.fe_len) - 1; + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) + order = MB_NUM_ORDERS(ac->ac_sb); min_order = order - sbi->s_mb_best_avail_max_trim_order; if (min_order < 0) min_order = 0; diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index 6d332dff79dd..5f3df2931643 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -29,6 +29,7 @@ typedef enum { attr_trigger_test_error, attr_first_error_time, attr_last_error_time, + attr_clusters_in_group, attr_feature, attr_pointer_ui, attr_pointer_ul, @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, ext4_sb_info, s_inode_readahead_blks); +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, + ext4_sb_info, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); @@ -392,6 +394,7 @@ static ssize_t ext4_attr_show(struct kobject *kobj, (unsigned long long) percpu_counter_sum(&sbi->s_sra_exceeded_retry_limit)); case attr_inode_readahead: + case attr_clusters_in_group: case attr_pointer_ui: if (!ptr) return 0; @@ -468,6 +471,14 @@ static ssize_t ext4_attr_store(struct kobject *kobj, else *((unsigned int *) ptr) = t; return len; + case attr_clusters_in_group: + ret = kstrtouint(skip_spaces(buf), 0, &t); + if (ret) + return ret; + if (t > sbi->s_clusters_per_group) + return -EINVAL; + *((unsigned int *) ptr) = t; + return len; case attr_pointer_ul: if (!ptr) return 0; -- 2.39.2

2 1

[PATCH OLK-6.6] ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()
by Yifan Qiao 15 Jul '24

15 Jul '24

From: Baokun Li <libaokun1(a)huawei.com> stable inclusion from stable-v6.6.36 commit 677ff4589f1501578fa903a25bb14831d0607992 category: bugfix bugzilla: 190177 CVE: CVE-2024-40955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 13df4d44a3aaabe61cd01d277b6ee23ead2a5206 upstream. We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops. Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> Link: https://lore.kernel.org/r/20240319113325.3110393-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 13 ++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index f6e02978d0e6..9a65cdcc6417 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -834,6 +834,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) return 0; if (order == MB_NUM_ORDERS(sb)) order--; + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) + order = MB_NUM_ORDERS(sb) - 1; return order; } @@ -1011,6 +1013,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context * goal length. */ order = fls(ac->ac_g_ex.fe_len) - 1; + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) + order = MB_NUM_ORDERS(ac->ac_sb); min_order = order - sbi->s_mb_best_avail_max_trim_order; if (min_order < 0) min_order = 0; diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index 6d332dff79dd..5f3df2931643 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -29,6 +29,7 @@ typedef enum { attr_trigger_test_error, attr_first_error_time, attr_last_error_time, + attr_clusters_in_group, attr_feature, attr_pointer_ui, attr_pointer_ul, @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, ext4_sb_info, s_inode_readahead_blks); +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, + ext4_sb_info, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); @@ -392,6 +394,7 @@ static ssize_t ext4_attr_show(struct kobject *kobj, (unsigned long long) percpu_counter_sum(&sbi->s_sra_exceeded_retry_limit)); case attr_inode_readahead: + case attr_clusters_in_group: case attr_pointer_ui: if (!ptr) return 0; @@ -468,6 +471,14 @@ static ssize_t ext4_attr_store(struct kobject *kobj, else *((unsigned int *) ptr) = t; return len; + case attr_clusters_in_group: + ret = kstrtouint(skip_spaces(buf), 0, &t); + if (ret) + return ret; + if (t > sbi->s_clusters_per_group) + return -EINVAL; + *((unsigned int *) ptr) = t; + return len; case attr_pointer_ul: if (!ptr) return 0; -- 2.39.2

2 1

[PATCH OLK-6.6 0/1] fix CVE-2024-40934
by Hongbo Li 15 Jul '24

15 Jul '24

Fix CVE-2024-40934. José Expósito (1): HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() drivers/hid/hid-logitech-dj.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] media: gspca: cpia1: shift-out-of-bounds in set_flicker
by felix 15 Jul '24

15 Jul '24

From: Rajeshwar R Shinde <coolrrsh(a)gmail.com> stable inclusion from stable-v5.10.202 commit c6b6b8692218da73b33b310d7c1df90f115bdd9a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9DZOS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 099be1822d1f095433f4b08af9cc9d6308ec1953 ] Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int' When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added. Reported-by: syzbot+e27f3dbdab04e43b9f73(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/20230818164522.12806-1-coolrrsh@gmail.com Link: https://syzkaller.appspot.com/bug?extid=e27f3dbdab04e43b9f73 Signed-off-by: Rajeshwar R Shinde <coolrrsh(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: sanglipeng <sanglipeng1(a)jd.com> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/media/usb/gspca/cpia1.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c index d93d384286c1..de945e13c7c6 100644 --- a/drivers/media/usb/gspca/cpia1.c +++ b/drivers/media/usb/gspca/cpia1.c @@ -18,6 +18,7 @@ #include <linux/input.h> #include <linux/sched/signal.h> +#include <linux/bitops.h> #include "gspca.h" @@ -1027,6 +1028,8 @@ static int set_flicker(struct gspca_dev *gspca_dev, int on, int apply) sd->params.exposure.expMode = 2; sd->exposure_status = EXPOSURE_NORMAL; } + if (sd->params.exposure.gain >= BITS_PER_TYPE(currentexp)) + return -EINVAL; currentexp = currentexp << sd->params.exposure.gain; sd->params.exposure.gain = 0; /* round down current exposure to nearest value */ -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] fix CVE-2024-40934
by Hongbo Li 15 Jul '24

15 Jul '24

Fix CVE-2024-40934. José Expósito (1): HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() drivers/hid/hid-logitech-dj.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6] ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
by Xiongfeng Wang 15 Jul '24

15 Jul '24

From: Simon Trimmer <simont(a)opensource.cirrus.com> mainline inclusion from mainline-v6.10-rc5 commit 6386682cdc8b41319c92fbbe421953e33a28840c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS5R CVE: CVE-2024-40964 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The cs35l41_hda_unbind() function clears the hda_component entry matching it's index and then dereferences the codec pointer held in the first element of the hda_component array, this is an issue when the device index was 0. Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid. Fixes: 7cf5ce66dfda ("ALSA: hda: cs35l41: Add device_link between HDA and cs35l41_hda") Signed-off-by: Simon Trimmer <simont(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20240531120820.35367-1-simont@opensource.cirrus.c… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- sound/pci/hda/cs35l41_hda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 3c157b006a5a..b437beae9b51 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1187,7 +1187,7 @@ static void cs35l41_hda_unbind(struct device *dev, struct device *master, void * if (comps[cs35l41->index].dev == dev) { memset(&comps[cs35l41->index], 0, sizeof(*comps)); sleep_flags = lock_system_sleep(); - device_link_remove(&comps->codec->core.dev, cs35l41->dev); + device_link_remove(&cs35l41->codec->core.dev, cs35l41->dev); unlock_system_sleep(sleep_flags); } } -- 2.20.1

2 1

[PATCH openEuler-22.03-LTS-SP1] selinux: avoid dereference of garbage after mount failure
by felix 15 Jul '24

15 Jul '24

From: Christian Göttsche <cgzones(a)googlemail.com> stable inclusion from stable-v6.6.26 commit 477ed6789eb9f3f4d3568bb977f90c863c12724e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QG73 CVE: CVE-2024-35904 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 37801a36b4d68892ce807264f784d818f8d0d39b upstream. In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount. Cc: stable(a)vger.kernel.org Fixes: 0619f0f5e36f ("selinux: wrap selinuxfs state") Signed-off-by: Christian Göttsche <cgzones(a)googlemail.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: security/selinux/selinuxfs.c [selinuxfs_mount still in use because of SECURITY_SELINUX_DISABLE, so we reserve it, only deal with kern_mount failure issue] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- security/selinux/selinuxfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index d893c2280f59..97d169679265 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -2232,13 +2232,17 @@ static int __init init_sel_fs(void) pr_err("selinuxfs: could not mount!\n"); err = PTR_ERR(selinuxfs_mount); selinuxfs_mount = NULL; + selinux_null.mnt = NULL; + return err; } + selinux_null.dentry = d_hash_and_lookup(selinux_null.mnt->mnt_root, &null_name); if (IS_ERR(selinux_null.dentry)) { pr_err("selinuxfs: could not lookup null!\n"); err = PTR_ERR(selinux_null.dentry); selinux_null.dentry = NULL; + return err; } return err; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] nvdimm: Backport some bugfixs
by Zhihao Cheng 15 Jul '24

15 Jul '24

Mathieu Desnoyers (2): nvdimm/pmem: fix leak on dax_add_host() failure dax: alloc_dax() return ERR_PTR(-EOPNOTSUPP) for CONFIG_DAX=n drivers/dax/super.c | 5 +++++ drivers/nvdimm/pmem.c | 3 +-- include/linux/dax.h | 6 +----- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] nvdimm: Backport some bugfixs
by Zhihao Cheng 15 Jul '24

15 Jul '24

Luis Chamberlain (1): nvdimm/pmem: use add_disk() error handling Mathieu Desnoyers (1): dax: alloc_dax() return ERR_PTR(-EOPNOTSUPP) for CONFIG_DAX=n drivers/dax/super.c | 5 +++++ drivers/nvdimm/pmem.c | 8 +++++++- include/linux/dax.h | 6 +----- 3 files changed, 13 insertions(+), 6 deletions(-) -- 2.31.1

2 3

[PATCH OLK-5.10 0/2] nvdimm: Backport some bugfixs
by Zhihao Cheng 15 Jul '24

15 Jul '24

Luis Chamberlain (1): nvdimm/pmem: use add_disk() error handling Mathieu Desnoyers (1): dax: alloc_dax() return ERR_PTR(-EOPNOTSUPP) for CONFIG_DAX=n drivers/dax/super.c | 5 +++++ drivers/nvdimm/pmem.c | 8 +++++++- include/linux/dax.h | 6 +----- 3 files changed, 13 insertions(+), 6 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-22.03-LTS-SP1] ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
by felix 15 Jul '24

15 Jul '24

From: "Geoffrey D. Bennett" <g(a)b4.vu> stable inclusion from stable-v5.15.148 commit e517645ead5ea22c69d2a44694baa23fe1ce7c2b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9ID CVE: CVE-2023-52674 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 04f8f053252b86c7583895c962d66747ecdc61b7 ] Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[]. Signed-off-by: Geoffrey D. Bennett <g(a)b4.vu> Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Link: https://lore.kernel.org/r/3b19fb3da641b587749b85fe1daa1b4e696c0c1b.17030010… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: sound/usb/mixer_scarlett_gen2.c [Some context inconsistencies exist in the scarlett2_mixer_ctl_put function, which does not affect the patch] Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- sound/usb/mixer_scarlett_gen2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer_scarlett_gen2.c b/sound/usb/mixer_scarlett_gen2.c index 1b7c7b754c38..6b7c8b8d7111 100644 --- a/sound/usb/mixer_scarlett_gen2.c +++ b/sound/usb/mixer_scarlett_gen2.c @@ -1509,7 +1509,8 @@ static int scarlett2_mixer_ctl_put(struct snd_kcontrol *kctl, mutex_lock(&private->data_mutex); oval = private->mix[elem->control]; - val = ucontrol->value.integer.value[0]; + val = clamp(ucontrol->value.integer.value[0], + 0L, (long)SCARLETT2_MIXER_MAX_VALUE); num_mixer_in = ports[SCARLETT2_PORT_TYPE_MIX].num[SCARLETT2_PORT_OUT]; mix_num = elem->control / num_mixer_in; -- 2.34.1

2 1

[PATCH OLK-6.6] ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
by Xiongfeng Wang 15 Jul '24

15 Jul '24

From: Simon Trimmer <simont(a)opensource.cirrus.com> mainline inclusion from mainline-v6.10-rc5 commit 6386682cdc8b41319c92fbbe421953e33a28840c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACS5R CVE: CVE-2024-40964 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The cs35l41_hda_unbind() function clears the hda_component entry matching it's index and then dereferences the codec pointer held in the first element of the hda_component array, this is an issue when the device index was 0. Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid. Fixes: 7cf5ce66dfda ("ALSA: hda: cs35l41: Add device_link between HDA and cs35l41_hda") Signed-off-by: Simon Trimmer <simont(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20240531120820.35367-1-simont@opensource.cirrus.c… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- sound/pci/hda/cs35l41_hda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 3c157b006a5a..b437beae9b51 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1187,7 +1187,7 @@ static void cs35l41_hda_unbind(struct device *dev, struct device *master, void * if (comps[cs35l41->index].dev == dev) { memset(&comps[cs35l41->index], 0, sizeof(*comps)); sleep_flags = lock_system_sleep(); - device_link_remove(&comps->codec->core.dev, cs35l41->dev); + device_link_remove(&cs35l41->codec->core.dev, cs35l41->dev); unlock_system_sleep(sleep_flags); } } -- 2.20.1

2 1

[PATCH OLK-6.6 0/6] ext4: improve buffered write with more than one blocks_per_folio
by Zhang Yi 15 Jul '24

15 Jul '24

In ext4_iomap_write_begin(), we speed up mapping check by checking the folio dirty bit. If the folio is dirty, it means this folio has just been written and must have a counterpart allocated block or delalloc extent, so we don't need to map the folio again if we write to the same place, this could speed up a lot for the case of repeated overwrite to the same folio. However, we only check the entire folio has been dirty or not, so it doesn't support if we have more than one blocks per folio yet. This series fix the handles of sub-folio properly in iomap, and extend this improvement by checking partial blocks in one folio. Zhang Yi (6): iomap: correct the range of a partial dirty clear iomap: support invalidating partial folios iomap: advance the ifs allocation if we have more than one blocks per folio iomap: correct the dirty length in page mkwrite iomap: add iomap_is_fully_dirty() ext4: improve sub-polio check in ext4_iomap_write_begin() fs/ext4/inode.c | 2 +- fs/iomap/buffered-io.c | 64 ++++++++++++++++++++++++++++++++++++------ include/linux/iomap.h | 1 + 3 files changed, 57 insertions(+), 10 deletions(-) -- 2.31.1

3 10

[PATCH OLK-6.6] ocfs2: fix races between hole punching and AIO+DIO
by Ye Bin 15 Jul '24

15 Jul '24

From: Su Yue <glass.su(a)suse.com> mainline inclusion from mainline-v6.10-rc1 commit 952b023f06a24b2ad6ba67304c4c84d45bea2f18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0L1 CVE: CVE-2024-40943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4. Link: https://lkml.kernel.org/r/20240408082041.20925-3-glass.su@suse.com Fixes: b25801038da5 ("ocfs2: Support xfs style space reservation ioctls") Signed-off-by: Su Yue <glass.su(a)suse.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- fs/ocfs2/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index c45596c25c66..f861b8c345e8 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1934,6 +1934,8 @@ static int __ocfs2_change_file_space(struct file *file, struct inode *inode, inode_lock(inode); + /* Wait all existing dio workers, newcomers will block on i_rwsem */ + inode_dio_wait(inode); /* * This prevents concurrent writes on other nodes */ -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ocfs2: fix races between hole punching and AIO+DIO
by Ye Bin 15 Jul '24

15 Jul '24

From: Su Yue <glass.su(a)suse.com> mainline inclusion from mainline-v6.10-rc1 commit 952b023f06a24b2ad6ba67304c4c84d45bea2f18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0L1 CVE: CVE-2024-40943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4. Link: https://lkml.kernel.org/r/20240408082041.20925-3-glass.su@suse.com Fixes: b25801038da5 ("ocfs2: Support xfs style space reservation ioctls") Signed-off-by: Su Yue <glass.su(a)suse.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- fs/ocfs2/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 1470b49adb2d..ffa258da6bac 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1940,6 +1940,8 @@ static int __ocfs2_change_file_space(struct file *file, struct inode *inode, inode_lock(inode); + /* Wait all existing dio workers, newcomers will block on i_rwsem */ + inode_dio_wait(inode); /* * This prevents concurrent writes on other nodes */ -- 2.31.1

2 1

[PATCH OLK-5.10] ocfs2: fix races between hole punching and AIO+DIO
by Ye Bin 15 Jul '24

15 Jul '24

From: Su Yue <glass.su(a)suse.com> mainline inclusion from mainline-v6.10-rc1 commit 952b023f06a24b2ad6ba67304c4c84d45bea2f18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0L1 CVE: CVE-2024-40943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4. Link: https://lkml.kernel.org/r/20240408082041.20925-3-glass.su@suse.com Fixes: b25801038da5 ("ocfs2: Support xfs style space reservation ioctls") Signed-off-by: Su Yue <glass.su(a)suse.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- fs/ocfs2/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 318b73d791d5..ec0e67e9a3ec 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1940,6 +1940,8 @@ static int __ocfs2_change_file_space(struct file *file, struct inode *inode, inode_lock(inode); + /* Wait all existing dio workers, newcomers will block on i_rwsem */ + inode_dio_wait(inode); /* * This prevents concurrent writes on other nodes */ -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] ocfs2: fix races between hole punching and AIO+DIO
by Ye Bin 15 Jul '24

15 Jul '24

From: Su Yue <glass.su(a)suse.com> mainline inclusion from mainline-v6.10-rc1 commit 952b023f06a24b2ad6ba67304c4c84d45bea2f18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0L1 CVE: CVE-2024-40943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4. Link: https://lkml.kernel.org/r/20240408082041.20925-3-glass.su@suse.com Fixes: b25801038da5 ("ocfs2: Support xfs style space reservation ioctls") Signed-off-by: Su Yue <glass.su(a)suse.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- fs/ocfs2/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index fd49fd2ad86f..8c0e300f0463 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1940,6 +1940,8 @@ static int __ocfs2_change_file_space(struct file *file, struct inode *inode, inode_lock(inode); + /* Wait all existing dio workers, newcomers will block on i_rwsem */ + inode_dio_wait(inode); /* * This prevents concurrent writes on other nodes */ -- 2.31.1

2 1

[PATCH OLK-5.10] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..893421d81e1e 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,13 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..893421d81e1e 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,13 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH OLK-5.10] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH OLK-5.10] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

From: Nathan Lynch <nathanl(a)linux.ibm.com> stable inclusion from stable-v4.19.317 commit acf2b80c31c37acab040baa3cf5f19fbd5140b18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACRHB CVE: CVE-2024-40974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ] plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.i… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index 00c8cda1c9c3..a8035af4fc50 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -453,7 +453,7 @@ long plpar_hcall_norets_notrace(unsigned long opcode, ...); * Used for all but the craziest of phyp interfaces (see plpar_hcall9) */ #define PLPAR_HCALL_BUFSIZE 4 -long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall_raw: - Make a hypervisor call without calculating hcall stats @@ -467,7 +467,7 @@ long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); * plpar_hcall, but plpar_hcall_raw works in real mode and does not * calculate hypervisor call statistics. */ -long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall9: - Make a pseries hypervisor call with up to 9 return arguments @@ -478,8 +478,8 @@ long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); * PLPAR_HCALL9_BUFSIZE to size the return argument buffer. */ #define PLPAR_HCALL9_BUFSIZE 9 -long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...); -long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall9(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); +long plpar_hcall9_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); struct hvcall_mpp_data { unsigned long entitled_mem; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

From: Nathan Lynch <nathanl(a)linux.ibm.com> stable inclusion from stable-v4.19.317 commit acf2b80c31c37acab040baa3cf5f19fbd5140b18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACRHB CVE: CVE-2024-40974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ] plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.i… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index a0b17f9f1ea4..8347f57e1c6a 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -383,7 +383,7 @@ long plpar_hcall_norets(unsigned long opcode, ...); * Used for all but the craziest of phyp interfaces (see plpar_hcall9) */ #define PLPAR_HCALL_BUFSIZE 4 -long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall_raw: - Make a hypervisor call without calculating hcall stats @@ -397,7 +397,7 @@ long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); * plpar_hcall, but plpar_hcall_raw works in real mode and does not * calculate hypervisor call statistics. */ -long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall9: - Make a pseries hypervisor call with up to 9 return arguments @@ -408,8 +408,8 @@ long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); * PLPAR_HCALL9_BUFSIZE to size the return argument buffer. */ #define PLPAR_HCALL9_BUFSIZE 9 -long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...); -long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall9(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); +long plpar_hcall9_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); struct hvcall_mpp_data { unsigned long entitled_mem; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 15 Jul '24

15 Jul '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> stable inclusion from stable-v6.6.33 commit 9f2ad88f9b349554f64e4037ec185c84d7dd9c7d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N3 CVE: CVE-2024-39488 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@h… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index c762038ba4009..6e73809f6492a 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -28,6 +28,7 @@ 14470: .long 14471f - .; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 15 Jul '24

15 Jul '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> stable inclusion from stable-v5.10.219 commit 461a760d578b2b2c2faac3040b6b7c77baf128f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N3 CVE: CVE-2024-39488 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@h… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index 03f52f84a4f3f..bc2dcc8a00009 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -28,6 +28,7 @@ 14470: .long 14471f - 14470b; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2