- Kernel - mailweb.openeuler.org

[openeuler:OLK-5.10 2759/2759] ld.lld: error: version script assignment of 'LINUX_2.6' to symbol '__vdso_sgx_enter_enclave' failed: symbol not defined
by kernel test robot 22 Feb '25

22 Feb '25

Hi Sean, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 4d88bf76198b8a462646f7be261586ebb2bbf5f3 commit: 5476cb89ef2297bd36f8b38e27b54617b6f63236 [2759/2759] x86/vdso: Implement a vDSO for Intel SGX enclave call config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20250222/202502220002.A1cz9IPm-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250222/202502220002.A1cz9IPm-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/202502220002.A1cz9IPm-lkp@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: version script assignment of 'LINUX_2.6' to symbol '__vdso_sgx_enter_enclave' failed: symbol not defined >> llvm-objdump: error: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file or directory -- >> llvm-objcopy: error: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file or directory -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] binfmt_flat: Fix integer overflow bug on 32 bit systems
by Tengda Wu 21 Feb '25

21 Feb '25

From: Dan Carpenter <dan.carpenter(a)linaro.org> stable inclusion from stable-v6.6.78 commit d17ca8f2dfcf423c439859995910a20e38b86f00 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBNTYM Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream. Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long); Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers") Cc: stable(a)vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Acked-by: Nicolas Pitre <npitre(a)baylibre.com> Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.moun… Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- fs/binfmt_flat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index cd6d5bbb4b9d..3f740d8abb4f 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -478,7 +478,7 @@ static int load_flat_file(struct linux_binprm *bprm, * 28 bits (256 MB) is way more than reasonable in this case. * If some top bits are set we have probable binary corruption. */ - if ((text_len | data_len | bss_len | stack_len | full_data) >> 28) { + if ((text_len | data_len | bss_len | stack_len | relocs | full_data) >> 28) { pr_err("bad header\n"); ret = -ENOEXEC; goto err; -- 2.34.1

2 1

[PATCH openEuler-25.03 v2 0/4] Add TrIO support in EROFS
by Hongbo Li 21 Feb '25

21 Feb '25

TrIO can accelerate the cold start of containers during on-demand loading. It aggregates the read I/O operations required for container runtime during the first container launch. In the following startups, TrIO pulls the necessary I/O data to the container node in a single large I/O operation and uses this I/O information to construct the runtime rootfs. By improving the efficiency of network I/O, TrIO speeds up container startup in on-demand loading scenarios. TrIO consists of both kernel-space and user-space code. The kernel-space code has been adapted at the overlayfs layer, introducing the CONFIG_EROFS_TRIO configuration to provide isolation. The user-space code requires adaptation by the user, and detailed usage methods are introduced in the tools/trio/README.md section. Patches 1~2 correspond to the kernel adaptations, while patches 3~4 are the scripts and best practices that TrIO relies on for its operation. Hongbo Li (4): erofs:trio: Add trio_manager in erofs erofs: trio: Support TrIO feature in erofs TrIO: Add tools for using TrIO TrIO: Add README.md fs/erofs/Kconfig | 11 + fs/erofs/Makefile | 1 + fs/erofs/fscache.c | 22 +- fs/erofs/internal.h | 39 ++ fs/erofs/super.c | 45 +- fs/erofs/trio_manager.c | 337 ++++++++++++ tools/trio/README.md | 507 +++++++++++++++++++ tools/trio/bpf/iotracker/Makefile | 99 ++++ tools/trio/bpf/iotracker/iotracker.bpf.c | 59 +++ tools/trio/bpf/iotracker/iotracker.c | 57 +++ tools/trio/bpf/rio_tracker_mod/Makefile | 9 + tools/trio/bpf/rio_tracker_mod/rio_tracker.c | 278 ++++++++++ tools/trio/scripts/trace_parser.py | 277 ++++++++++ 13 files changed, 1739 insertions(+), 2 deletions(-) create mode 100644 fs/erofs/trio_manager.c create mode 100644 tools/trio/README.md create mode 100644 tools/trio/bpf/iotracker/Makefile create mode 100644 tools/trio/bpf/iotracker/iotracker.bpf.c create mode 100644 tools/trio/bpf/iotracker/iotracker.c create mode 100644 tools/trio/bpf/rio_tracker_mod/Makefile create mode 100644 tools/trio/bpf/rio_tracker_mod/rio_tracker.c create mode 100644 tools/trio/scripts/trace_parser.py -- 2.34.1

2 5

[PATCH OLK-6.6] kobject: Fix global-out-of-bounds in kobject_action_type()
by Xia Fukun 21 Feb '25

21 Feb '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9REGZ CVE: NA -------------------------------- The following c language code can trigger KASAN's global variable out-of-bounds access error in kobject_action_type(): int main() { int fd; char *filename = "/sys/block/ram12/uevent"; char str[86] = "offline"; int len = 86; fd = open(filename, O_WRONLY); if (fd == -1) { printf("open"); exit(1); } if (write(fd, str, len) == -1) { printf("write"); exit(1); } close(fd); return 0; } Function kobject_action_type() receives the input parameters buf and count, where count is the length of the string buf. In the use case we provided, count is 86, the count_first is 85. Buf points to a string with a length of 86, and its first seven characters are "offline". In line 87 of the code, kobject_actions[action] is the string "offline" with the length of 7,an out-of-boundary access will appear: kobject_actions[action][85]. Modify the judgment logic in line 87. If the length of the string kobject_actions[action] is greater than count_first(e.g. buf is "off", count is 3), continue the loop. Otherwise, the match is considered successful. This change means that our test case will be successfully parsed as an offline event and no out-of-bounds access error will occur. Fixes: f36776fafbaa ("kobject: support passing in variables for synthetic uevents") Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- lib/kobject_uevent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index d397b1ad5ccf..c31fac25d676 100644 --- a/lib/kobject_uevent.c +++ b/lib/kobject_uevent.c @@ -84,7 +84,7 @@ static int kobject_action_type(const char *buf, size_t count, for (action = 0; action < ARRAY_SIZE(kobject_actions); action++) { if (strncmp(kobject_actions[action], buf, count_first) != 0) continue; - if (kobject_actions[action][count_first] != '\0') + if (strlen(kobject_actions[action]) > count_first) continue; if (args) *args = args_start; -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] Push self-developed patches to OLK-5.10
by Xiaomeng Zhang 21 Feb '25

21 Feb '25

Xiaomeng Zhang (2): x86: reboot: Initialize the printk locks to avoid deadlock printk: Skip log flush in NMI context when logbuf_lock is held arch/x86/kernel/reboot.c | 1 + kernel/printk/printk_safe.c | 4 ++++ 2 files changed, 5 insertions(+) -- 2.34.1

2 3

[PATCH OLK-5.10] iio: imu: kmx61: fix information leak in triggered buffer
by Xia Fukun 21 Feb '25

21 Feb '25

From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> stable inclusion from stable-v5.10.234 commit a386d9d2dc6635f2ec210b8199cfb3acf4d31305 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBIQVT CVE: CVE-2024-57908 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6ae053113f6a226a2303caa4936a4c37f3bfff7b upstream. The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values. Initialize the array to zero before using it to avoid pushing uninitialized information to userspace. Cc: stable(a)vger.kernel.org Fixes: c3a23ecc0901 ("iio: imu: kmx61: Add support for data ready triggers") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Link: https://patch.msgid.link/20241125-iio_memset_scan_holes-v1-5-0cb6e98d895c@g… Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/iio/imu/kmx61.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c index 89133315e6aaf..b5c3500b7e9eb 100644 --- a/drivers/iio/imu/kmx61.c +++ b/drivers/iio/imu/kmx61.c @@ -1198,7 +1198,7 @@ static irqreturn_t kmx61_trigger_handler(int irq, void *p) struct kmx61_data *data = kmx61_get_data(indio_dev); int bit, ret, i = 0; u8 base; - s16 buffer[8]; + s16 buffer[8] = { }; if (indio_dev == data->acc_indio_dev) base = KMX61_ACC_XOUT_L; -- 2.34.1

2 1

[PATCH OLK-6.6] virtio-blk: don't keep queue frozen during system suspend
by Zheng Qixing 21 Feb '25

21 Feb '25

From: Ming Lei <ming.lei(a)redhat.com> stable inclusion from stable-v6.6.69 commit 12c0ddd6c551c1e438b087f874b4f1223a75f7ea category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBJ6SJ CVE: CVE-2024-57946 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------- [ Upstream commit 7678abee0867e6b7fb89aa40f6e9f575f755fb37 ] Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@sa… Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend. Cc: Yi Sun <yi.sun(a)unisoc.com> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Jason Wang <jasowang(a)redhat.com> Cc: Stefan Hajnoczi <stefanha(a)redhat.com> Cc: virtualization(a)lists.linux.dev Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Acked-by: Stefan Hajnoczi <stefanha(a)redhat.com> Link: https://lore.kernel.org/r/20241112125821.1475793-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/block/virtio_blk.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 52aaea6e64ad..69f8af74aa49 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -1598,9 +1598,12 @@ static void virtblk_remove(struct virtio_device *vdev) static int virtblk_freeze(struct virtio_device *vdev) { struct virtio_blk *vblk = vdev->priv; + struct request_queue *q = vblk->disk->queue; /* Ensure no requests in virtqueues before deleting vqs. */ - blk_mq_freeze_queue(vblk->disk->queue); + blk_mq_freeze_queue(q); + blk_mq_quiesce_queue_nowait(q); + blk_mq_unfreeze_queue(q); /* Ensure we don't receive any more interrupts */ virtio_reset_device(vdev); @@ -1624,8 +1627,8 @@ static int virtblk_restore(struct virtio_device *vdev) return ret; virtio_device_ready(vdev); + blk_mq_unquiesce_queue(vblk->disk->queue); - blk_mq_unfreeze_queue(vblk->disk->queue); return 0; } #endif -- 2.39.2

2 1

[PATCH OLK-6.6] block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()
by Zheng Qixing 21 Feb '25

21 Feb '25

From: Yu Kuai <yukuai3(a)huawei.com> stable inclusion from stable-v6.6.72 commit be3eed59ac01f429ac10aaa46e26f653bcf581ab category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBIQPR CVE: CVE-2025-21631 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ [ Upstream commit fcede1f0a043ccefe9bc6ad57f12718e42f63f1d ] Our syzkaller report a following UAF for v6.6: BUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958 Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726 CPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 hlist_add_head include/linux/list.h:1023 [inline] bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143 __submit_bio+0xa0/0x6b0 block/blk-core.c:639 __submit_bio_noacct_mq block/blk-core.c:718 [inline] submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847 __ext4_read_bh fs/ext4/super.c:205 [inline] ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230 __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567 ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947 ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182 ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660 ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569 iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91 iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80 ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051 ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220 do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811 __do_sys_ioctl fs/ioctl.c:869 [inline] __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Allocated by task 232719: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:768 [inline] slab_alloc_node mm/slub.c:3492 [inline] kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537 bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869 bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776 bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143 __submit_bio+0xa0/0x6b0 block/blk-core.c:639 __submit_bio_noacct_mq block/blk-core.c:718 [inline] submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847 __ext4_read_bh fs/ext4/super.c:205 [inline] ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217 ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242 ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958 __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671 ext4_lookup_entry fs/ext4/namei.c:1774 [inline] ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842 ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839 __lookup_slow+0x257/0x480 fs/namei.c:1696 lookup_slow fs/namei.c:1713 [inline] walk_component+0x454/0x5c0 fs/namei.c:2004 link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331 link_path_walk fs/namei.c:3826 [inline] path_openat+0x1b9/0x520 fs/namei.c:3826 do_filp_open+0x1b7/0x400 fs/namei.c:3857 do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x148/0x200 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Freed by task 232726: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1827 [inline] slab_free_freelist_hook mm/slub.c:1853 [inline] slab_free mm/slub.c:3820 [inline] kmem_cache_free+0x110/0x760 mm/slub.c:3842 bfq_put_queue+0x6a7/0xfb0 block/bfq-iosched.c:5428 bfq_forget_entity block/bfq-wf2q.c:634 [inline] bfq_put_idle_entity+0x142/0x240 block/bfq-wf2q.c:645 bfq_forget_idle+0x189/0x1e0 block/bfq-wf2q.c:671 bfq_update_vtime block/bfq-wf2q.c:1280 [inline] __bfq_lookup_next_entity block/bfq-wf2q.c:1374 [inline] bfq_lookup_next_entity+0x350/0x480 block/bfq-wf2q.c:1433 bfq_update_next_in_service+0x1c0/0x4f0 block/bfq-wf2q.c:128 bfq_deactivate_entity+0x10a/0x240 block/bfq-wf2q.c:1188 bfq_deactivate_bfqq block/bfq-wf2q.c:1592 [inline] bfq_del_bfqq_busy+0x2e8/0xad0 block/bfq-wf2q.c:1659 bfq_release_process_ref+0x1cc/0x220 block/bfq-iosched.c:3139 bfq_split_bfqq+0x481/0xdf0 block/bfq-iosched.c:6754 bfq_init_rq+0xf29/0x17a0 block/bfq-iosched.c:6934 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143 __submit_bio+0xa0/0x6b0 block/blk-core.c:639 __submit_bio_noacct_mq block/blk-core.c:718 [inline] submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847 __ext4_read_bh fs/ext4/super.c:205 [inline] ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230 __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567 ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947 ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182 ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660 ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569 iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91 iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80 ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051 ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220 do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811 __do_sys_ioctl fs/ioctl.c:869 [inline] __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 commit 1ba0403ac644 ("block, bfq: fix uaf for accessing waker_bfqq after splitting") fix the problem that if waker_bfqq is in the merge chain, and current is the only procress, waker_bfqq can be freed from bfq_split_bfqq(). However, the case that waker_bfqq is not in the merge chain is missed, and if the procress reference of waker_bfqq is 0, waker_bfqq can be freed as well. Fix the problem by checking procress reference if waker_bfqq is not in the merge_chain. Fixes: 1ba0403ac644 ("block, bfq: fix uaf for accessing waker_bfqq after splitting") Signed-off-by: Hou Tao <houtao1(a)huawei.com> Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://lore.kernel.org/r/20250108084148.1549973-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/bfq-iosched.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 8294f77892bf..a8ebf3962f11 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -6850,16 +6850,24 @@ static struct bfq_queue *bfq_waker_bfqq(struct bfq_queue *bfqq) if (new_bfqq == waker_bfqq) { /* * If waker_bfqq is in the merge chain, and current - * is the only procress. + * is the only process, waker_bfqq can be freed. */ if (bfqq_process_refs(waker_bfqq) == 1) return NULL; - break; + + return waker_bfqq; } new_bfqq = new_bfqq->new_bfqq; } + /* + * If waker_bfqq is not in the merge chain, and it's procress reference + * is 0, waker_bfqq can be freed. + */ + if (bfqq_process_refs(waker_bfqq) == 0) + return NULL; + return waker_bfqq; } -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] Push self-developed patches to OLK-5.10
by Xiaomeng Zhang 21 Feb '25

21 Feb '25

Xiaomeng Zhang (2): x86: reboot: Initialize the printk locks to avoid deadlock printk: Skip log flush in NMI context when logbuf_lock is held arch/x86/kernel/reboot.c | 1 + kernel/printk/printk_safe.c | 4 ++++ 2 files changed, 5 insertions(+) -- 2.34.1

2 3

[PATCH OLK-6.6] riscv: mm: Fix the out of bound issue of vmemmap address
by Heyuan Wang 21 Feb '25

21 Feb '25

From: Xu Lu <luxu.kernel(a)bytedance.com> mainline inclusion from mainline-v6.13-rc7 commit f754f27e98f88428aaf6be6e00f5cbce97f62d4b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBJ6RK CVE: CVE-2024-57945 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. Fixes: a11dd49dcb93 ("riscv: Sparse-Memory/vmemmap out-of-bounds fix") Signed-off-by: Xu Lu <luxu.kernel(a)bytedance.com> Reviewed-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> Tested-by: Björn Töpel <bjorn(a)rivosinc.com> Reviewed-by: Björn Töpel <bjorn(a)rivosinc.com> Link: https://lore.kernel.org/r/20241209122617.53341-1-luxu.kernel@bytedance.com Signed-off-by: Palmer Dabbelt <palmer(a)rivosinc.com> Signed-off-by: Heyuan Wang <wangheyuan2(a)h-partners.com> --- arch/riscv/include/asm/page.h | 1 + arch/riscv/include/asm/pgtable.h | 2 +- arch/riscv/mm/init.c | 17 ++++++++++++++++- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h index 94b3d6930fc3..4d1f58848129 100644 --- a/arch/riscv/include/asm/page.h +++ b/arch/riscv/include/asm/page.h @@ -122,6 +122,7 @@ struct kernel_mapping { extern struct kernel_mapping kernel_map; extern phys_addr_t phys_ram_base; +extern unsigned long vmemmap_start_pfn; #define is_kernel_mapping(x) \ ((x) >= kernel_map.virt_addr && (x) < (kernel_map.virt_addr + kernel_map.size)) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 63d8a84826e9..e58315cedfd3 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -84,7 +84,7 @@ * Define vmemmap for pfn_to_page & page_to_pfn calls. Needed if kernel * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled. */ -#define vmemmap ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)) +#define vmemmap ((struct page *)VMEMMAP_START - vmemmap_start_pfn) #define PCI_IO_SIZE SZ_16M #define PCI_IO_END VMEMMAP_START diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 3245bb525212..bdf8ac6c7e30 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -32,6 +32,7 @@ #include <asm/ptdump.h> #include <asm/sections.h> #include <asm/soc.h> +#include <asm/sparsemem.h> #include <asm/tlbflush.h> #include "../kernel/head.h" @@ -57,6 +58,13 @@ EXPORT_SYMBOL(pgtable_l5_enabled); phys_addr_t phys_ram_base __ro_after_init; EXPORT_SYMBOL(phys_ram_base); +#ifdef CONFIG_SPARSEMEM_VMEMMAP +#define VMEMMAP_ADDR_ALIGN (1ULL << SECTION_SIZE_BITS) + +unsigned long vmemmap_start_pfn __ro_after_init; +EXPORT_SYMBOL(vmemmap_start_pfn); +#endif + unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss; EXPORT_SYMBOL(empty_zero_page); @@ -221,8 +229,12 @@ static void __init setup_bootmem(void) * Make sure we align the start of the memory on a PMD boundary so that * at worst, we map the linear mapping with PMD mappings. */ - if (!IS_ENABLED(CONFIG_XIP_KERNEL)) + if (!IS_ENABLED(CONFIG_XIP_KERNEL)) { phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; +#ifdef CONFIG_SPARSEMEM_VMEMMAP + vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT; +#endif + } /* * In 64-bit, any use of __va/__pa before this point is wrong as we @@ -1080,6 +1092,9 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa) kernel_map.xiprom_sz = (uintptr_t)(&_exiprom) - (uintptr_t)(&_xiprom); phys_ram_base = CONFIG_PHYS_RAM_BASE; +#ifdef CONFIG_SPARSEMEM_VMEMMAP + vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT; +#endif kernel_map.phys_addr = (uintptr_t)CONFIG_PHYS_RAM_BASE; kernel_map.size = (uintptr_t)(&_end) - (uintptr_t)(&_start); -- 2.25.1

2 1