- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] drm/radeon: add a force flush to delay work when radeon
by Zhang Zekun 10 May '24

10 May '24

From: Zhenneng Li <lizhenneng(a)kylinos.cn> stable inclusion from stable-v4.19.258 commit c0a45f41fde4a0f2c900f719817493ee5c4a5aa3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9LKDS CVE: CVE-2022-48704 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f461950fdc374a3ada5a63c669d997de4600dffe ] Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem. Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Zhenneng Li <lizhenneng(a)kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/gpu/drm/radeon/radeon_device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 59c8a6647ff2..cc1c07963116 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1625,6 +1625,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend, if (r) { /* delay GPU reset to resume */ radeon_fence_driver_force_completion(rdev, i); + } else { + /* finish executing delayed work */ + flush_delayed_work(&rdev->fence_drv[i].lockup_work); } } -- 2.17.1

2 1

[PATCH v2 openEuler-1.0-LTS 0/3] backport patch for thp deferred list for 4.19
by Wupeng Ma 10 May '24

10 May '24

From: Ma Wupeng <mawupeng1(a)huawei.com> backport patch for thp deferred list for 4.19. changelog since v1: - remove data_race since 4.19 does not have it Jianxing Wang (1): mm/mmu_gather: limit free batch count and add schedule point in tlb_batch_pages_flush Kirill A. Shutemov (1): mm, thp: do not queue fully unmapped pages for deferred split Yin Fengwei (1): THP: avoid lock when check whether THP is in deferred list mm/huge_memory.c | 15 +++++++++++---- mm/mmu_gather.c | 16 ++++++++++++++-- mm/rmap.c | 14 ++++++++++---- 3 files changed, 35 insertions(+), 10 deletions(-) -- 2.25.1

2 4

[PATCH openEuler-1.0-LTS] clk: zynq: Prevent null pointer dereference caused by kmalloc failure
by Yu Liao 10 May '24

10 May '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.9.rc1 commit 7938e9ce39d6779d2f85d822cc930f73420e54a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9NB CVE: CVE-2024-27037 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc(). Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver") Suggested-by: Michal Simek <michal.simek(a)amd.com> Suggested-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Link: https://lore.kernel.org/r/20240301084437.16084-1-duoming@zju.edu.cn Acked-by: Michal Simek <michal.simek(a)amd.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Conflicts: drivers/clk/zynq/clkc.c [The conflicts were caused by not merged bf2244ba9d85("clk: zynq: clkc: Remove various instances of an unused variable 'clk'")] Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/clk/zynq/clkc.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index 88a2cab37f62..35c855708741 100644 --- a/drivers/clk/zynq/clkc.c +++ b/drivers/clk/zynq/clkc.c @@ -53,6 +53,7 @@ static void __iomem *zynq_clkc_base; #define SLCR_SWDT_CLK_SEL (zynq_clkc_base + 0x204) #define NUM_MIO_PINS 54 +#define CLK_NAME_LEN 16 #define DBG_CLK_CTRL_CLKACT_TRC BIT(0) #define DBG_CLK_CTRL_CPU_1XCLKACT BIT(1) @@ -229,7 +230,7 @@ static void __init zynq_clk_setup(struct device_node *np) u32 tmp; int ret; struct clk *clk; - char *clk_name; + char clk_name[CLK_NAME_LEN]; unsigned int fclk_enable = 0; const char *clk_output_name[clk_max]; const char *cpu_parents[4]; @@ -439,12 +440,10 @@ static void __init zynq_clk_setup(struct device_node *np) "gem1_emio_mux", CLK_SET_RATE_PARENT, SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); - tmp = strlen("mio_clk_00x"); - clk_name = kmalloc(tmp, GFP_KERNEL); for (i = 0; i < NUM_MIO_PINS; i++) { int idx; - snprintf(clk_name, tmp, "mio_clk_%2.2d", i); + snprintf(clk_name, CLK_NAME_LEN, "mio_clk_%2.2d", i); idx = of_property_match_string(np, "clock-names", clk_name); if (idx >= 0) can_mio_mux_parents[i] = of_clk_get_parent_name(np, @@ -452,7 +451,6 @@ static void __init zynq_clk_setup(struct device_node *np) else can_mio_mux_parents[i] = dummy_nm; } - kfree(clk_name); clk = clk_register_mux(NULL, "can_mux", periph_parents, 4, CLK_SET_RATE_NO_REPARENT, SLCR_CAN_CLK_CTRL, 4, 2, 0, &canclk_lock); -- 2.25.1

2 1

[PATCH OLK-5.10] clk: zynq: Prevent null pointer dereference caused by kmalloc failure
by Yu Liao 10 May '24

10 May '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.9.rc1 commit 7938e9ce39d6779d2f85d822cc930f73420e54a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9NB CVE: CVE-2024-27037 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc(). Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver") Suggested-by: Michal Simek <michal.simek(a)amd.com> Suggested-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Link: https://lore.kernel.org/r/20240301084437.16084-1-duoming@zju.edu.cn Acked-by: Michal Simek <michal.simek(a)amd.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Conflicts: drivers/clk/zynq/clkc.c [The conflicts were caused by not merged bf2244ba9d85("clk: zynq: clkc: Remove various instances of an unused variable 'clk'")] Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/clk/zynq/clkc.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index ffbb9008c1c9..15320945bedc 100644 --- a/drivers/clk/zynq/clkc.c +++ b/drivers/clk/zynq/clkc.c @@ -42,6 +42,7 @@ static void __iomem *zynq_clkc_base; #define SLCR_SWDT_CLK_SEL (zynq_clkc_base + 0x204) #define NUM_MIO_PINS 54 +#define CLK_NAME_LEN 16 #define DBG_CLK_CTRL_CLKACT_TRC BIT(0) #define DBG_CLK_CTRL_CPU_1XCLKACT BIT(1) @@ -218,7 +219,7 @@ static void __init zynq_clk_setup(struct device_node *np) u32 tmp; int ret; struct clk *clk; - char *clk_name; + char clk_name[CLK_NAME_LEN]; unsigned int fclk_enable = 0; const char *clk_output_name[clk_max]; const char *cpu_parents[4]; @@ -428,12 +429,10 @@ static void __init zynq_clk_setup(struct device_node *np) "gem1_emio_mux", CLK_SET_RATE_PARENT, SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); - tmp = strlen("mio_clk_00x"); - clk_name = kmalloc(tmp, GFP_KERNEL); for (i = 0; i < NUM_MIO_PINS; i++) { int idx; - snprintf(clk_name, tmp, "mio_clk_%2.2d", i); + snprintf(clk_name, CLK_NAME_LEN, "mio_clk_%2.2d", i); idx = of_property_match_string(np, "clock-names", clk_name); if (idx >= 0) can_mio_mux_parents[i] = of_clk_get_parent_name(np, @@ -441,7 +440,6 @@ static void __init zynq_clk_setup(struct device_node *np) else can_mio_mux_parents[i] = dummy_nm; } - kfree(clk_name); clk = clk_register_mux(NULL, "can_mux", periph_parents, 4, CLK_SET_RATE_NO_REPARENT, SLCR_CAN_CLK_CTRL, 4, 2, 0, &canclk_lock); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2024-26960
by Jinjiang Tu 10 May '24

10 May '24

fix CVE-2024-26960 Huang Ying (1): mm/swapfile.c: use __try_to_reclaim_swap() in free_swap_and_cache() Ryan Roberts (1): mm: swap: fix race between free_swap_and_cache() and swapoff() mm/swapfile.c | 70 +++++++++++++++++++++++++++------------------------ 1 file changed, 37 insertions(+), 33 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS] usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
by Wei Li 10 May '24

10 May '24

From: Norihiko Hama <Norihiko.Hama(a)alpsalpine.com> mainline inclusion from mainline-v6.9-rc5 commit 6334b8e4553cc69f51e383c9de545082213d785e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9AJ86 CVE: CVE-2024-26996 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established. Signed-off-by: Norihiko Hama <Norihiko.Hama(a)alpsalpine.com> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20240327023550.51214-1-Norihiko.Hama@alpsalpine.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/usb/gadget/function/f_ncm.c [lw: fix context conflict only] Signed-off-by: Wei Li <liwei391(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index 5780fba620ab..3da7e6511fc6 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -885,7 +885,7 @@ static int ncm_set_alt(struct usb_function *f, unsigned intf, unsigned alt) if (alt > 1) goto fail; - if (ncm->port.in_ep->enabled) { + if (ncm->netdev) { DBG(cdev, "reset ncm\n"); ncm->timer_stopping = true; ncm->netdev = NULL; @@ -1322,7 +1322,7 @@ static void ncm_disable(struct usb_function *f) DBG(cdev, "ncm deactivated\n"); - if (ncm->port.in_ep->enabled) { + if (ncm->netdev) { ncm->timer_stopping = true; ncm->netdev = NULL; gether_disconnect(&ncm->port); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] KVM: Always flush async #PF workqueue when vCPU is being destroyed
by Wei Li 10 May '24

10 May '24

From: Sean Christopherson <seanjc(a)google.com> mainline inclusion from mainline-v6.9-rc1 commit 3d75b8aa5c29058a512db29da7cbee8052724157 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L4ZX CVE: CVE-2024-26976 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until all VMs are freed") *tried* to fix the module refcounting issue by having VMs grab a reference to the module, but that only made the bug slightly harder to hit as it gave async_pf_execute() a bit more time to complete before the KVM module could be unloaded. Fixes: af585b921e5d ("KVM: Halt vcpu if page it tries to access is swapped out") Cc: stable(a)vger.kernel.org Cc: David Matlack <dmatlack(a)google.com> Reviewed-by: Xu Yilun <yilun.xu(a)intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Link: https://lore.kernel.org/r/20240110011533.503302-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> Conflicts: virt/kvm/async_pf.c [lw: fix context conflict only] Signed-off-by: Wei Li <liwei391(a)huawei.com> --- virt/kvm/async_pf.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c index 23c2519c5b32..57d6c211f3d9 100644 --- a/virt/kvm/async_pf.c +++ b/virt/kvm/async_pf.c @@ -110,7 +110,27 @@ static void async_pf_execute(struct work_struct *work) swake_up_one(&vcpu->wq); mmput(mm); - kvm_put_kvm(vcpu->kvm); +} + +static void kvm_flush_and_free_async_pf_work(struct kvm_async_pf *work) +{ + /* + * The async #PF is "done", but KVM must wait for the work item itself, + * i.e. async_pf_execute(), to run to completion. If KVM is a module, + * KVM must ensure *no* code owned by the KVM (the module) can be run + * after the last call to module_put(). Note, flushing the work item + * is always required when the item is taken off the completion queue. + * E.g. even if the vCPU handles the item in the "normal" path, the VM + * could be terminated before async_pf_execute() completes. + * + * Wake all events skip the queue and go straight done, i.e. don't + * need to be flushed (but sanity check that the work wasn't queued). + */ + if (work->wakeup_all) + WARN_ON_ONCE(work->work.func); + else + flush_work(&work->work); + kmem_cache_free(async_pf_cache, work); } void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu) @@ -137,7 +157,6 @@ void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu) #else if (cancel_work_sync(&work->work)) { mmput(work->mm); - kvm_put_kvm(vcpu->kvm); /* == work->vcpu->kvm */ kmem_cache_free(async_pf_cache, work); } #endif @@ -149,7 +168,10 @@ void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu) list_first_entry(&vcpu->async_pf.done, typeof(*work), link); list_del(&work->link); - kmem_cache_free(async_pf_cache, work); + + spin_unlock(&vcpu->async_pf.lock); + kvm_flush_and_free_async_pf_work(work); + spin_lock(&vcpu->async_pf.lock); } spin_unlock(&vcpu->async_pf.lock); @@ -173,7 +195,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu) list_del(&work->queue); vcpu->async_pf.queued--; - kmem_cache_free(async_pf_cache, work); + kvm_flush_and_free_async_pf_work(work); } } @@ -202,7 +224,6 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva, work->arch = *arch; work->mm = current->mm; mmget(work->mm); - kvm_get_kvm(work->vcpu->kvm); /* this can't really happen otherwise gfn_to_pfn_async would succeed */ -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
by Ziyang Xuan 10 May '24

10 May '24

mainline inclusion from mainline-v6.9-rc5 commit d78d867dcea69c328db30df665be5be7d0148484 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L4T1 CVE: CVE-2024-27019 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process. Fixes: e50092404c1b ("netfilter: nf_tables: add stateful objects") Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Conflicts: net/netfilter/nf_tables_api.c [The version does not include 776d45164844.] Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/netfilter/nf_tables_api.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index f70fedb98695..3f679c872ff3 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -5066,7 +5066,7 @@ static const struct nft_object_type *__nft_obj_type_get(u32 objtype) { const struct nft_object_type *type; - list_for_each_entry(type, &nf_tables_objects, list) { + list_for_each_entry_rcu(type, &nf_tables_objects, list) { if (objtype == type->type) return type; } @@ -5078,9 +5078,13 @@ nft_obj_type_get(struct net *net, u32 objtype) { const struct nft_object_type *type; + rcu_read_lock(); type = __nft_obj_type_get(objtype); - if (type != NULL && try_module_get(type->owner)) + if (type != NULL && try_module_get(type->owner)) { + rcu_read_unlock(); return type; + } + rcu_read_unlock(); lockdep_nfnl_nft_mutex_not_held(); #ifdef CONFIG_MODULES -- 2.25.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS f238d4e533e14006972f8c6ae542e7ee1ca1ad1c
by kernel test robot 10 May '24

10 May '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: f238d4e533e14006972f8c6ae542e7ee1ca1ad1c !7013 media: edia: dvbdev: fix a use-after-free Warning ids grouped by kconfigs: clang_recent_errors |-- arm64-allyesconfig | |-- Documentation-devicetree-bindings-arm-cpu.yaml:properties:capacity-dmips-mhz:ref-should-not-be-valid-under-const:ref | |-- Documentation-devicetree-bindings-arm-cpu.yaml:title:ARM-CPUs-bindings-should-not-be-valid-under-pattern:(-Bb-inding-Ss-chema) | |-- Documentation-devicetree-bindings-arm-cpus.yaml:examples:cpus-arm-pbha-performance-only-bits-arm-pbha-no-aliases-bits-ncpu-device_type-cpu-compatible-arm-cortex-a57-...-n-is-not-of-type-array | |-- Documentation-devicetree-bindings-arm-cpus.yaml:maintainers-is-a-required-property | |-- description:Display-controller-reference-clock-source-is-not-of-type-object-boolean | |-- description:Display-controller-reference-clock-source-is-too-short | |-- description:Offset-and-length-of-the-memory-mapped-registers-is-too-short | |-- items-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneOf-r | `-- minItems-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneO `-- x86_64-allnoconfig |-- Warning:openEuler-MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-networking-hinic3.rst `-- drivers-net-ethernet-mucse-rnpm-rnpm_common.h:linux-version.h-not-needed. elapsed time: 737m configs tested: 35 configs skipped: 150 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240510 clang arm64 randconfig-002-20240510 gcc arm64 randconfig-003-20240510 clang arm64 randconfig-004-20240510 clang x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240510 gcc x86_64 buildonly-randconfig-002-20240510 clang x86_64 buildonly-randconfig-003-20240510 gcc x86_64 buildonly-randconfig-004-20240510 clang x86_64 buildonly-randconfig-005-20240510 gcc x86_64 buildonly-randconfig-006-20240510 clang x86_64 defconfig gcc x86_64 randconfig-001-20240510 gcc x86_64 randconfig-002-20240510 clang x86_64 randconfig-003-20240510 clang x86_64 randconfig-004-20240510 gcc x86_64 randconfig-005-20240510 gcc x86_64 randconfig-006-20240510 gcc x86_64 randconfig-011-20240510 clang x86_64 randconfig-012-20240510 clang x86_64 randconfig-013-20240510 clang x86_64 randconfig-014-20240510 clang x86_64 randconfig-015-20240510 clang x86_64 randconfig-016-20240510 gcc x86_64 randconfig-071-20240510 clang x86_64 randconfig-072-20240510 clang x86_64 randconfig-073-20240510 clang x86_64 randconfig-074-20240510 gcc x86_64 randconfig-075-20240510 clang x86_64 randconfig-076-20240510 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2024-26865
by Zhengchao Shao 10 May '24

10 May '24

Fix CVE-2024-26865. Eric Dumazet (1): tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge() Kuniyuki Iwashima (1): tcp: Clean up kernel listener's reqsk in inet_twsk_purge() net/ipv4/inet_timewait_sock.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) -- 2.34.1

2 3