April 2024 - Linux-stable-mirror

[PATCH v4] mtd: rawnand: qcom: Fix broken OP_RESET_DEVICE command in qcom_misc_cmd_type_exec()

by Christian Marangi

While migrating to exec_ops in commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path"), OP_RESET_DEVICE command handling got broken unintentionally. Right now for the OP_RESET_DEVICE command, qcom_misc_cmd_type_exec() will simply return 0 without handling it. Even, if that gets fixed, an unnecessary FLASH_STATUS read descriptor command is being added in the middle and that seems to be causing the command to fail on IPQ806x devices. So let's fix the above two issues to make OP_RESET_DEVICE command working again. Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable(a)vger.kernel.org Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- Changes v4: - Rework commit title and description as suggested. - Add Reviewed-by tag Changes v3: - Merge patches - Rework commit description Changes v2: - Split patches drivers/mtd/nand/raw/qcom_nandc.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..b8cff9240b28 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2815,7 +2815,7 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub host->cfg0_raw & ~(7 << CW_PER_PAGE)); nandc_set_reg(chip, NAND_DEV0_CFG1, host->cfg1_raw); instrs = 3; - } else { + } else if (q_op.cmd_reg != OP_RESET_DEVICE) { return 0; } @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL); - (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0, - 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc, - NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL); + if (q_op.cmd_reg == OP_BLOCK_ERASE) + write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL); write_reg_dma(nandc, NAND_EXEC_CMD, 1, NAND_BAM_NEXT_SGL); read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL); -- 2.43.0

9 months

2
1
0 0

[PATCH] mtd: diskonchip: work around ubsan link failure

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> I ran into a randconfig build failure with UBSAN using gcc-13.2: arm-linux-gnueabi-ld: error: unplaced orphan section `.bss..Lubsan_data31' from `drivers/mtd/nand/raw/diskonchip.o' I'm not entirely sure what is going on here, but I suspect this has something to do with the check for the end of the doc_locations[] array that contains an (unsigned long)0xffffffff element, which is compared against the signed (int)0xffffffff. If this is the case, we should get a runtime check for undefined behavior, but we instead get an unexpected build-time error. I would have expected this to work fine on 32-bit architectures despite the signed integer overflow, though on 64-bit architectures this likely won't ever work. Changing the contition to instead check for the size of the array makes the code safe everywhere and avoids the ubsan check that leads to the link error. The loop code goes back to before 2.6.12. Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/mtd/nand/raw/diskonchip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/diskonchip.c b/drivers/mtd/nand/raw/diskonchip.c index 5243fab9face..8db7fc424571 100644 --- a/drivers/mtd/nand/raw/diskonchip.c +++ b/drivers/mtd/nand/raw/diskonchip.c @@ -53,7 +53,7 @@ static unsigned long doc_locations[] __initdata = { 0xe8000, 0xea000, 0xec000, 0xee000, #endif #endif - 0xffffffff }; +}; static struct mtd_info *doclist = NULL; @@ -1554,7 +1554,7 @@ static int __init init_nanddoc(void) if (ret < 0) return ret; } else { - for (i = 0; (doc_locations[i] != 0xffffffff); i++) { + for (i = 0; i < ARRAY_SIZE(doc_locations); i++) { doc_probe(doc_locations[i]); } } -- 2.39.2

9 months

2
1
0 0

[PATCH 5.4.y] drm/vkms: call drm_atomic_helper_shutdown before drm_dev_put()

by Guo Mengqi

commit 73a82b22963d ("drm/atomic: Fix potential use-after-free in nonblocking commits") introduced drm_dev_get/put() to drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit process. vkms_exit() drm_dev_put() vkms_release() drm_atomic_helper_shutdown() drm_dev_get() drm_dev_put() vkms_release() ------ use after free Using 5.4 stable x86 image on qemu, below stacktrace can be triggered by load and unload vkms.ko. root:~ # insmod vkms.ko [ 76.957802] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 76.961490] [drm] Driver supports precise vblank timestamp query. [ 76.964416] [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 0 root:~ # rmmod vkms.ko [ 79.650202] refcount_t: addition on 0; use-after-free. [ 79.650249] WARNING: CPU: 2 PID: 3533 at ../lib/refcount.c:25 refcount_warn_saturate+0xcf/0xf0 [ 79.654241] Modules linked in: vkms(-) [ 79.654249] CPU: 2 PID: 3533 Comm: rmmod Not tainted 5.4.273 #4 [ 79.654251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 79.654262] RIP: 0010:refcount_warn_saturate+0xcf/0xf0 ... [ 79.654296] Call Trace: [ 79.654462] ? __warn+0x80/0xd0 [ 79.654473] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654481] ? report_bug+0xb6/0x130 [ 79.654484] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654489] ? fixup_bug.part.12+0x13/0x30 [ 79.654492] ? do_error_trap+0x90/0xb0 [ 79.654495] ? do_invalid_op+0x31/0x40 [ 79.654497] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654504] ? invalid_op+0x1e/0x30 [ 79.654508] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654516] drm_atomic_state_init+0x68/0xb0 [ 79.654543] drm_atomic_state_alloc+0x43/0x60 [ 79.654551] drm_atomic_helper_disable_all+0x13/0x180 [ 79.654562] drm_atomic_helper_shutdown+0x5f/0xb0 [ 79.654571] vkms_release+0x18/0x40 [vkms] [ 79.654575] vkms_exit+0x29/0xc00 [vkms] [ 79.654582] __x64_sys_delete_module+0x155/0x220 [ 79.654592] do_syscall_64+0x43/0x120 [ 79.654603] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 79.654619] ---[ end trace ce0c02f57ea6bf73 ]--- It seems that the proper unload sequence is: drm_atomic_helper_shutdown(); drm_dev_put(); Just put drm_atomic_helper_shutdown() before drm_dev_put() should solve the problem. Note that vkms exit code is refactored by commit 53d77aaa3f76 ("drm/vkms: Use devm_drm_dev_alloc") in tags/v5.10-rc1. So this bug only exists on 4.19 and 5.4. Fixes: 380c7ceabdde ("drm/atomic: Fix potential use-after-free in nonblocking commits") Fixes: 2ead1be54b22 ("drm/vkms: Fix connector leak at the module removal") Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index 44ab9f8ef8be..86043d7c0e4b 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -60,7 +60,6 @@ static void vkms_release(struct drm_device *dev) struct vkms_device *vkms = container_of(dev, struct vkms_device, drm); platform_device_unregister(vkms->platform); - drm_atomic_helper_shutdown(&vkms->drm); drm_mode_config_cleanup(&vkms->drm); drm_dev_fini(&vkms->drm); destroy_workqueue(vkms->output.composer_workq); @@ -194,6 +193,7 @@ static void __exit vkms_exit(void) } drm_dev_unregister(&vkms_device->drm); + drm_atomic_helper_shutdown(&vkms_device->drm); drm_dev_put(&vkms_device->drm); kfree(vkms_device); -- 2.17.1

9 months

1
0
0 0

[PATCH] bpf: dereference of null in __cgroup_bpf_query() function

by Mikhail Lobanov

In the __cgroup_bpf_query() function, it is possible to dereference the null pointer in the line id = prog->aux->id; since there is no check for a non-zero value of the variable prog. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> --- kernel/bpf/cgroup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 491d20038cbe..7f2db96f0c6a 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -1092,6 +1092,8 @@ static int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr, i = 0; hlist_for_each_entry(pl, progs, node) { prog = prog_list_prog(pl); + if (!prog_list_prog(pl)) + continue; id = prog->aux->id; if (copy_to_user(prog_ids + i, &id, sizeof(id))) return -EFAULT; -- 2.43.0

9 months

2
1
0 0

[PATCH 2/2] of: property: fw_devlink: Fix links to supplier when created from phandles

by Herve Codina

Since commit 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays"), when using device-tree overlays, the FWNODE_FLAG_NOT_DEVICE is set on each overlay nodes. This flag is cleared when a struct device is actually created for the DT node. Also, when a device is created, the device DT node is parsed for known phandle and devlinks consumer/supplier links are created between the device (consumer) and the devices referenced by phandles (suppliers). As these supplier device can have a struct device not already created, the FWNODE_FLAG_NOT_DEVICE can be set for suppliers and leads the devlink supplier point to the device's parent instead of the device itself. Avoid this situation clearing the supplier FWNODE_FLAG_NOT_DEVICE just before the devlink creation if a device is supposed to be created and handled later in the process. Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays") Cc: <stable(a)vger.kernel.org> Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/of/property.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/of/property.c b/drivers/of/property.c index 641a40cf5cf3..ff5cac477dbe 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1097,6 +1097,7 @@ static void of_link_to_phandle(struct device_node *con_np, struct device_node *sup_np) { struct device_node *tmp_np = of_node_get(sup_np); + struct fwnode_handle *sup_fwnode; /* Check that sup_np and its ancestors are available. */ while (tmp_np) { @@ -1113,7 +1114,20 @@ static void of_link_to_phandle(struct device_node *con_np, tmp_np = of_get_next_parent(tmp_np); } - fwnode_link_add(of_fwnode_handle(con_np), of_fwnode_handle(sup_np)); + /* + * In case of overlays, the fwnode are added with FWNODE_FLAG_NOT_DEVICE + * flag set. A node can have a phandle that references an other node + * added by the overlay. + * Clear the supplier's FWNODE_FLAG_NOT_DEVICE so that fw_devlink links + * to this supplier instead of linking to its parent. + */ + sup_fwnode = of_fwnode_handle(sup_np); + if (sup_fwnode->flags & FWNODE_FLAG_NOT_DEVICE) { + if (of_property_present(sup_np, "compatible") && + of_device_is_available(sup_np)) + sup_fwnode->flags &= ~FWNODE_FLAG_NOT_DEVICE; + } + fwnode_link_add(of_fwnode_handle(con_np), sup_fwnode); } /** -- 2.43.0

9 months

2
7
0 0

[PATCH AUTOSEL 6.8 01/98] drm/vc4: don't check if plane->state->fb == state->fb

by Sasha Levin

From: Maíra Canal <mcanal(a)igalia.com> [ Upstream commit 5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9 ] Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not really needed. We can increase and decrease the refcount symmetrically without problems. This is going to make the code more simple and consistent. Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Acked-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240105175908.242000-1-mcana… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/vc4/vc4_plane.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 00e713faecd5a..5948e34f7f813 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -1505,9 +1505,6 @@ static int vc4_prepare_fb(struct drm_plane *plane, drm_gem_plane_helper_prepare_fb(plane, state); - if (plane->state->fb == state->fb) - return 0; - return vc4_bo_inc_usecnt(bo); } @@ -1516,7 +1513,7 @@ static void vc4_cleanup_fb(struct drm_plane *plane, { struct vc4_bo *bo; - if (plane->state->fb == state->fb || !state->fb) + if (!state->fb) return; bo = to_vc4_bo(&drm_fb_dma_get_gem_obj(state->fb, 0)->base); -- 2.43.0

9 months

5
106
0 0

[PATCH -stable,5.10.x 0/3] Netfilter fixes for -stable

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains a backport for recent fixes already upstream for 5.10.x, to add them on top of your enqueued patches: 994209ddf4f4 ("netfilter: nf_tables: reject new basechain after table flag update") 24cea9677025 ("netfilter: nf_tables: flush pending destroy work before exit_net release") a45e6889575c ("netfilter: nf_tables: release batch on table validation from abort path") 0d459e2ffb54 ("netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path") 1bc83a019bbe ("netfilter: nf_tables: discard table flag update with pending basechain deletion") Please, apply, thanks. Pablo Neira Ayuso (5): netfilter: nf_tables: reject new basechain after table flag update netfilter: nf_tables: flush pending destroy work before exit_net release netfilter: nf_tables: release batch on table validation from abort path netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path netfilter: nf_tables: discard table flag update with pending basechain deletion net/netfilter/nf_tables_api.c | 51 ++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 10 deletions(-) -- 2.30.2

9 months

1
6
0 0

[PATCH -stable,5.4.x 0/5] Netfilter fixes for -stable

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains a backport for recent fixes already upstream for 5.10.x, to add them on top of your enqueued patches: 994209ddf4f4 ("netfilter: nf_tables: reject new basechain after table flag update") 24cea9677025 ("netfilter: nf_tables: flush pending destroy work before exit_net release") a45e6889575c ("netfilter: nf_tables: release batch on table validation from abort path") 0d459e2ffb54 ("netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path") 1bc83a019bbe ("netfilter: nf_tables: discard table flag update with pending basechain deletion") Please, apply, thanks. Pablo Neira Ayuso (5): netfilter: nf_tables: reject new basechain after table flag update netfilter: nf_tables: flush pending destroy work before exit_net release netfilter: nf_tables: release batch on table validation from abort path netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path netfilter: nf_tables: discard table flag update with pending basechain deletion net/netfilter/nf_tables_api.c | 51 ++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 10 deletions(-) -- 2.30.2

9 months

1
5
0 0

[PATCH -stable,5.15.x 0/3] Netfilter fixes for -stable

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains a backport for recent fixes already upstream for 6.1.x, to add them on top of your enqueued patches: a45e6889575c ("netfilter: nf_tables: release batch on table validation from abort path") 0d459e2ffb54 ("netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path") 1bc83a019bbe ("netfilter: nf_tables: discard table flag update with pending basechain deletion") Please, apply, thanks. Pablo Neira Ayuso (3): netfilter: nf_tables: release batch on table validation from abort path netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path netfilter: nf_tables: discard table flag update with pending basechain deletion net/netfilter/nf_tables_api.c | 47 +++++++++++++++++++++++++++-------- 1 file changed, 36 insertions(+), 11 deletions(-) -- 2.30.2

9 months

1
3
0 0

[PATCH] mm/userfaultfd: Allow hugetlb change protection upon poison entry

by peterx＠redhat.com

From: Peter Xu <peterx(a)redhat.com> After UFFDIO_POISON, there can be two kinds of hugetlb pte markers, either the POISON one or UFFD_WP one. Allow change protection to run on a poisoned marker just like !hugetlb cases, ignoring the marker irrelevant of the permission. Here the two bits are mutual exclusive. For example, when install a poisoned entry it must not be UFFD_WP already (by checking pte_none() before such install). And it also means if UFFD_WP is set there must have no POISON bit set. It makes sense because UFFD_WP is a bit to reflect permission, and permissions do not apply if the pte is poisoned and destined to sigbus. So here we simply check uffd_wp bit set first, do nothing otherwise. Attach the Fixes to UFFDIO_POISON work, as before that it should not be possible to have poison entry for hugetlb (e.g., hugetlb doesn't do swap, so no chance of swapin errors). Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: linux-stable <stable(a)vger.kernel.org> # 6.6+ Link: https://lore.kernel.org/r/000000000000920d5e0615602dd1@google.com Reported-by: syzbot+b07c8ac8eee3d4d8440f(a)syzkaller.appspotmail.com Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl") Signed-off-by: Peter Xu <peterx(a)redhat.com> --- mm/hugetlb.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 8267e221ca5d..ba7162441adf 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6960,9 +6960,13 @@ long hugetlb_change_protection(struct vm_area_struct *vma, if (!pte_same(pte, newpte)) set_huge_pte_at(mm, address, ptep, newpte, psize); } else if (unlikely(is_pte_marker(pte))) { - /* No other markers apply for now. */ - WARN_ON_ONCE(!pte_marker_uffd_wp(pte)); - if (uffd_wp_resolve) + /* + * Do nothing on a poison marker; page is + * corrupted, permissons do not apply. Here + * pte_marker_uffd_wp()==true implies !poison + * because they're mutual exclusive. + */ + if (pte_marker_uffd_wp(pte) && uffd_wp_resolve) /* Safe to modify directly (non-present->none). */ huge_pte_clear(mm, address, ptep, psize); } else if (!huge_pte_none(pte)) { -- 2.44.0

9 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024