- Kernel - mailweb.openeuler.org

[openeuler:openEuler-1.0-LTS 1528/1528] drivers/crypto/.tmp_qcom-rng.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 29 Mar '25

29 Mar '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4d1e247486ffeef035a5a55a97f2659f68177357 commit: c5f5aeef9b55b362ad5a0e04e4b41cd63b208842 [1528/1528] Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux config: x86_64-buildonly-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282324.X867QbB6-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282324.X867QbB6-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/202503282324.X867QbB6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/crypto/.tmp_qcom-rng.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] usb: usbip: fix a refcount leak in stub_probe()
by Xia Fukun 28 Mar '25

28 Mar '25

From: Hangyu Hua <hbh25y(a)gmail.com> stable inclusion from stable-v4.19.325 commit 247d3809e45a34d9e1a3a2bb7012e31ed8b46031 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP3SN CVE: CVE-2022-49389 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- [ Upstream commit 9ec4cbf1cc55d126759051acfe328d489c5d6e60 ] usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. Fixes: 3ff67445750a ("usbip: fix error handling in stub_probe()") Reviewed-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Hangyu Hua <hbh25y(a)gmail.com> Link: https://lore.kernel.org/r/20220412020257.9767-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/usbip/stub_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c index 93891d445c30..2650ef62757a 100644 --- a/drivers/usb/usbip/stub_dev.c +++ b/drivers/usb/usbip/stub_dev.c @@ -410,7 +410,6 @@ static int stub_probe(struct usb_device *udev) (struct usb_dev_state *) udev); err_port: dev_set_drvdata(&udev->dev, NULL); - usb_put_dev(udev); /* we already have busid_priv, just lock busid_lock */ spin_lock(&busid_priv->busid_lock); @@ -425,6 +424,7 @@ static int stub_probe(struct usb_device *udev) put_busid_priv(busid_priv); sdev_free: + usb_put_dev(udev); stub_device_free(sdev); return rc; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 1528/1528] include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function
by kernel test robot 28 Mar '25

28 Mar '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4d1e247486ffeef035a5a55a97f2659f68177357 commit: e44716ed4262a467260fccb7814e4c89588f438d [1528/1528] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY config: arm64-randconfig-003-20250328 (https://download.01.org/0day-ci/archive/20250328/202503281620.pNXaYE13-lkp@…) compiler: aarch64-linux-gcc (GCC) 10.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503281620.pNXaYE13-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/202503281620.pNXaYE13-lkp@intel.com/ Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c: In function 'nv40_fifo_dma_engine_init': drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:111:37: warning: 'ctx' may be used uninitialized in this function [-Wmaybe-uninitialized] 111 | nvkm_wo32(imem->ramfc, chan->ramfc + ctx, inst); | ^ In file included from arch/arm64/include/asm/io.h:213, from include/linux/io.h:25, from include/linux/pci.h:34, from drivers/gpu/drm/nouveau/include/nvif/os.h:8, from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/engine.h:5, from drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h:4, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv04.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:24: >> include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function [-Wmaybe-uninitialized] 742 | #define iowrite32 iowrite32 | ^~~~~~~~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:97:12: note: 'reg' was declared here 97 | u32 inst, reg, ctx; | ^~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c: In function 'nv40_fifo_dma_engine_fini': drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:80:37: warning: 'ctx' may be used uninitialized in this function [-Wmaybe-uninitialized] 80 | nvkm_wo32(imem->ramfc, chan->ramfc + ctx, 0x00000000); | ^ In file included from arch/arm64/include/asm/io.h:213, from include/linux/io.h:25, from include/linux/pci.h:34, from drivers/gpu/drm/nouveau/include/nvif/os.h:8, from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/engine.h:5, from drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h:4, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv04.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:24: >> include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function [-Wmaybe-uninitialized] 742 | #define iowrite32 iowrite32 | ^~~~~~~~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:67:6: note: 'reg' was declared here 67 | u32 reg, ctx; | ^~~ vim +/reg +742 include/asm-generic/io.h 9216efafc52ff9 Thierry Reding 2014-10-01 740 9216efafc52ff9 Thierry Reding 2014-10-01 741 #ifndef iowrite32 9216efafc52ff9 Thierry Reding 2014-10-01 @742 #define iowrite32 iowrite32 9216efafc52ff9 Thierry Reding 2014-10-01 743 static inline void iowrite32(u32 value, volatile void __iomem *addr) 9216efafc52ff9 Thierry Reding 2014-10-01 744 { 9216efafc52ff9 Thierry Reding 2014-10-01 745 writel(value, addr); 9216efafc52ff9 Thierry Reding 2014-10-01 746 } 9216efafc52ff9 Thierry Reding 2014-10-01 747 #endif 9216efafc52ff9 Thierry Reding 2014-10-01 748 :::::: The code at line 742 was first introduced by commit :::::: 9216efafc52ff99e9351ef60de5fcafc2bc8adb6 asm-generic/io.h: Reconcile I/O accessor overrides :::::: TO: Thierry Reding <treding(a)nvidia.com> :::::: CC: Thierry Reding <treding(a)nvidia.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] drivers: usb: host: Fix deadlock in oxu_bus_suspend()
by Xia Fukun 28 Mar '25

28 Mar '25

From: Duoming Zhou <duoming(a)zju.edu.cn> stable inclusion from stable-v4.19.247 commit f8242044c91cafbba9e320b0fb31abf2429a3221 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP3Z3 CVE: CVE-2022-49313 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4d378f2ae58138d4c55684e1d274e7dd94aa6524 ] There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/host/oxu210hp-hcd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c index c5e6e8d0b5ef..0402fa3b1ea2 100644 --- a/drivers/usb/host/oxu210hp-hcd.c +++ b/drivers/usb/host/oxu210hp-hcd.c @@ -3476,8 +3476,10 @@ static int oxu_bus_suspend(struct usb_hcd *hcd) } } + spin_unlock_irq(&oxu->lock); /* turn off now-idle HC */ del_timer_sync(&oxu->watchdog); + spin_lock_irq(&oxu->lock); ehci_halt(oxu); hcd->state = HC_STATE_SUSPENDED; -- 2.34.1

2 1

[PATCH OLK-6.6 V1] platform/x86: int3472: Check for adev == NULL
by Zicheng Qu 28 Mar '25

28 Mar '25

From: Hans de Goede <hdegoede(a)redhat.com> stable inclusion from stable-v6.6.78 commit f9c7cc44758f4930b41285a6d54afa8cbd9762b4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPC5Y CVE: CVE-2024-58011 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c ] Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs. Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://lore.kernel.org/r/20241209220522.25288-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/platform/x86/intel/int3472/discrete.c | 3 +++ drivers/platform/x86/intel/int3472/tps68470.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index e33c2d75975c..d56f79043f5e 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -284,6 +284,9 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev) struct int3472_cldb cldb; int ret; + if (!adev) + return -ENODEV; + ret = skl_int3472_fill_cldb(adev, &cldb); if (ret) { dev_err(&pdev->dev, "Couldn't fill CLDB structure\n"); diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c index 1e107fd49f82..81ac4c691963 100644 --- a/drivers/platform/x86/intel/int3472/tps68470.c +++ b/drivers/platform/x86/intel/int3472/tps68470.c @@ -152,6 +152,9 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client) int ret; int i; + if (!adev) + return -ENODEV; + n_consumers = skl_int3472_fill_clk_pdata(&client->dev, &clk_pdata); if (n_consumers < 0) return n_consumers; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2025-21726
by Zicheng Qu 28 Mar '25

28 Mar '25

Chen Ridong (2): padata: add pd get/put refcnt helper padata: avoid UAF for reorder_work kernel/padata.c | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] CVE-2025-21726
by Zicheng Qu 28 Mar '25

28 Mar '25

Chen Ridong (2): padata: add pd get/put refcnt helper padata: avoid UAF for reorder_work kernel/padata.c | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 V1] padata: fix UAF in padata_reorder
by Zicheng Qu 28 Mar '25

28 Mar '25

From: Chen Ridong <chenridong(a)huawei.com> mainline inclusion from mainline-v6.14-rc1 commit e01780ea4661172734118d2a5f41bc9720765668 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPBHS CVE: CVE-2025-21727 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.local… [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofe… Fixes: b128a3040935 ("padata: allocate workqueue internally") Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Qu Zicheng <quzicheng(a)huawei.com> Acked-by: Daniel Jordan <daniel.m.jordan(a)oracle.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- kernel/padata.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/padata.c b/kernel/padata.c index 9bf77b58ee08..6567ec3a6658 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -1118,6 +1118,12 @@ void padata_free_shell(struct padata_shell *ps) if (!ps) return; + /* + * Wait for all _do_serial calls to finish to avoid touching + * freed pd's and ps's. + */ + synchronize_rcu(); + mutex_lock(&ps->pinst->lock); list_del(&ps->list); pd = rcu_dereference_protected(ps->pd, 1); -- 2.34.1

2 1

[PATCH OLK-5.10 V1] padata: fix UAF in padata_reorder
by Zicheng Qu 28 Mar '25

28 Mar '25

From: Chen Ridong <chenridong(a)huawei.com> mainline inclusion from mainline-v6.14-rc1 commit e01780ea4661172734118d2a5f41bc9720765668 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPBHS CVE: CVE-2025-21727 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.local… [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofe… Fixes: b128a3040935 ("padata: allocate workqueue internally") Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Qu Zicheng <quzicheng(a)huawei.com> Acked-by: Daniel Jordan <daniel.m.jordan(a)oracle.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- kernel/padata.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/padata.c b/kernel/padata.c index e24244c9c2cc..c27032595247 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -1120,6 +1120,12 @@ void padata_free_shell(struct padata_shell *ps) if (!ps) return; + /* + * Wait for all _do_serial calls to finish to avoid touching + * freed pd's and ps's. + */ + synchronize_rcu(); + mutex_lock(&ps->pinst->lock); list_del(&ps->list); pd = rcu_dereference_protected(ps->pd, 1); -- 2.34.1

2 1

[PATCH OLK-6.6 V1] kernel: be more careful about dup_mmap() failures and uprobe registering
by Zicheng Qu 28 Mar '25

28 Mar '25

From: "Liam R. Howlett" <Liam.Howlett(a)Oracle.com> mainline inclusion from mainline-v6.14-rc1 commit 64c37e134b120fb462fb4a80694bfb8e7be77b14 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPBM0 CVE: CVE-2025-21709 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… -------------------------------- If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised. Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE@google.com/ Link: https://lkml.kernel.org/r/20250127170221.1761366-1-Liam.Howlett@oracle.com Fixes: d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") Signed-off-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Jann Horn <jannh(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Peng Zhang <zhangpeng.00(a)bytedance.com> Cc: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: kernel/events/uprobes.c [The current version does not contain the following include code: include <linux/khugepaged.h> include <linux/rcupdate_trace.h> include <linux/workqueue.h> Upon verification, all three include can be ignore.] Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- kernel/events/uprobes.c | 4 ++++ kernel/fork.c | 17 ++++++++++++++--- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index a14b0059f177..e101416c64e5 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -26,6 +26,7 @@ #include <linux/task_work.h> #include <linux/shmem_fs.h> #include <linux/khugepaged.h> +#include <linux/oom.h> /* check_stable_address_space */ #include <linux/uprobes.h> @@ -1050,6 +1051,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new) goto free; mmap_write_lock(mm); + if (check_stable_address_space(mm)) + goto unlock; + vma = find_vma(mm, info->vaddr); if (!vma || !valid_vma(vma, is_register) || file_inode(vma->vm_file) != uprobe->inode) diff --git a/kernel/fork.c b/kernel/fork.c index f30b24c68442..ca12c40b2c4c 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -793,7 +793,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, mt_set_in_rcu(vmi.mas.tree); ksm_fork(mm, oldmm); khugepaged_fork(mm, oldmm); - } else if (mpnt) { + } else { + /* * The entire maple tree has already been duplicated. If the * mmap duplication fails, mark the failure point with @@ -801,8 +802,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, * stop releasing VMAs that have not been duplicated after this * point. */ - mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1); - mas_store(&vmi.mas, XA_ZERO_ENTRY); + if (mpnt) { + mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1); + mas_store(&vmi.mas, XA_ZERO_ENTRY); + /* Avoid OOM iterating a broken tree */ + set_bit(MMF_OOM_SKIP, &mm->flags); + } + /* + * The mm_struct is going to exit, but the locks will be dropped + * first. Set the mm_struct as unstable is advisable as it is + * not fully initialised. + */ + set_bit(MMF_UNSTABLE, &mm->flags); } out: mmap_write_unlock(mm); -- 2.34.1

2 1