- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] perf: arm_spe: Prevent overflow in PERF_IDX2OFF()
by Luo Gengkun 03 Nov '25

03 Nov '25

From: Leo Yan <leo.yan(a)arm.com> stable inclusion from stable-v5.10.246 commit 9c045d4501f7f70724a3bbb561f4f22d292bbfe6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID3WGV CVE: CVE-2025-40081 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit a29fea30dd93da16652930162b177941abd8c75e ] Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2 GiB). Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan <leo.yan(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/perf/arm_spe_pmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c index 3b5d7b690622..30ff2ad32e8d 100644 --- a/drivers/perf/arm_spe_pmu.c +++ b/drivers/perf/arm_spe_pmu.c @@ -94,7 +94,8 @@ struct arm_spe_pmu { #define to_spe_pmu(p) (container_of(p, struct arm_spe_pmu, pmu)) /* Convert a free-running index from perf into an SPE buffer offset */ -#define PERF_IDX2OFF(idx, buf) ((idx) % ((buf)->nr_pages << PAGE_SHIFT)) +#define PERF_IDX2OFF(idx, buf) \ + ((idx) % ((unsigned long)(buf)->nr_pages << PAGE_SHIFT)) /* Keep track of our dynamic hotplug state */ static enum cpuhp_state arm_spe_pmu_online; -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] *** CVE-2025-39973 ***
by Ziming Du 03 Nov '25

03 Nov '25

*** BLURB HERE *** Justin Bronder (1): i40e: increase max descriptors for XL710 Lukasz Czapnik (1): i40e: add validation for ring_len param drivers/net/ethernet/intel/i40e/i40e.h | 1 + .../net/ethernet/intel/i40e/i40e_ethtool.c | 25 ++++++++++++++----- .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 14 +++++++++++ 3 files changed, 34 insertions(+), 6 deletions(-) -- 2.43.0

2 3

[PATCH openEuler-1.0-LTS] fbdev: Fix out-of-bounds issue in sys_fillrect()
by Gu Bowen 03 Nov '25

03 Nov '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICYDSQ -------------------------------- BUG: unable to handle page fault for address: ffffc90000c3f000 PGD 100000067 P4D 100000067 PUD 100c80067 PMD 10ac1c067 PTE 0 Oops: 0002 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 6521 Comm: syz.3.1365 Not tainted 6.6.0+ #82 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:memset64 arch/x86/include/asm/string_64.h:58 [inline] RIP: 0010:memset_l include/linux/string.h:168 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/sysfillrect.c:53 [inline] RIP: 0010:bitfill_aligned+0x144/0x1c0 drivers/video/fbdev/core/sysfillrect.c:25 Code: 23 04 24 48 31 d0 49 89 46 f8 44 89 e0 44 29 f8 29 c3 e8 9f 39 49 fe 89 d8 31 d2 4c 89 f7 41 f7 f4 48 89 c3 48 89 c1 48 89 e8 <f3> 48 ab 31 ff 4c 89 ee e8 df 2f 49 fe 4d 85 ed 0f 84 6b ff ff ff RSP: 0018:ffff888119ce7418 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000180 RCX: 0000000000000180 RDX: 0000000000000000 RSI: ffffc90003873000 RDI: ffffc90000c3f000 RBP: 0000000000000000 R08: 0000000000006000 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000040 R13: 0000000000000000 R14: ffffc90000c3f000 R15: 0000000000000000 FS: 00007f1704b926c0(0000) GS:ffff8881f5980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000c3f000 CR3: 00000001230d0002 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 000000000000e000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> sys_fillrect+0x429/0x830 drivers/video/fbdev/core/sysfillrect.c:281 drm_fbdev_generic_defio_fillrect+0x27/0x140 drivers/gpu/drm/drm_fbdev_generic.c:37 bit_clear+0x183/0x220 drivers/video/fbdev/core/bitblit.c:73 __fbcon_clear+0x5ea/0x670 drivers/video/fbdev/core/fbcon.c:1281 fbcon_scroll+0x41e/0x560 drivers/video/fbdev/core/fbcon.c:1847 con_scroll+0x464/0x6a0 drivers/tty/vt/vt.c:577 lf+0x274/0x2d0 drivers/tty/vt/vt.c:1461 do_con_trol+0x5ea/0x3d80 drivers/tty/vt/vt.c:2149 do_con_write+0x780/0x10c0 drivers/tty/vt/vt.c:2905 con_write+0x28/0xc0 drivers/tty/vt/vt.c:3245 do_output_char+0x5de/0x850 drivers/tty/n_tty.c:433 process_output drivers/tty/n_tty.c:500 [inline] n_tty_write+0x442/0xb00 drivers/tty/n_tty.c:2406 iterate_tty_write+0x2b5/0x630 drivers/tty/tty_io.c:1017 file_tty_write.constprop.0+0x20c/0x3b0 drivers/tty/tty_io.c:1088 call_write_iter include/linux/fs.h:2085 [inline] do_iter_readv_writev+0x210/0x3c0 fs/read_write.c:737 do_iter_write+0x181/0x4e0 fs/read_write.c:862 vfs_writev+0x15b/0x4d0 fs/read_write.c:935 do_writev+0x136/0x370 fs/read_write.c:978 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 When the virtual console is rotated in the backend state, it can lead to inconsistencies between the size of the virtual console's size and its hook functions. In such cases, clearing the screen may result in out-of-bounds issue. Fix it by adding a check in sys_fillrect() and moving set_blitting_type() to the visible area of the VC. Fixes: 68648ed1f58d ("fbdev: add drawing functions for framebuffers in system RAM") Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/video/fbdev/core/fbcon.c | 2 +- drivers/video/fbdev/core/sysfillrect.c | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index f5178eefec64..ec3c71edf72e 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2647,9 +2647,9 @@ static void fbcon_modechanged(struct fb_info *info) return; p = &fb_display[vc->vc_num]; - set_blitting_type(vc, info); if (con_is_visible(vc)) { + set_blitting_type(vc, info); var_to_display(p, &info->var, info); cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); diff --git a/drivers/video/fbdev/core/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c index 33ee3d34f9d2..7b4103c3288e 100644 --- a/drivers/video/fbdev/core/sysfillrect.c +++ b/drivers/video/fbdev/core/sysfillrect.c @@ -248,6 +248,7 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect) u32 bpp = p->var.bits_per_pixel; unsigned long *dst; int dst_idx, left; + long dst_offset; if (p->state != FBINFO_STATE_RUNNING) return; @@ -287,6 +288,11 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect) } while (height--) { dst += dst_idx >> (ffs(bits) - 1); + dst_offset = (long)dst - (long)p->screen_base; + if (dst_offset < 0 || dst_offset >= p->fix.smem_len) { + pr_err("dst offset out of bound: dst_offset(%ld)", dst_offset); + return; + } dst_idx &= (bits - 1); fill_op32(p, dst, dst_idx, pat, width*bpp, bits); dst_idx += p->fix.line_length*8; -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS V2] ext4: avoid crash when inline data creation follows DIO write
by Zizhi Wo 03 Nov '25

03 Nov '25

From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v5.10.150 commit fb98cb61efff3b2a1964939465ccaaf906af1d4f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID0RD5 CVE: CVE-2022-50435 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4bb26f2885ac6930984ee451b952c5a6042f2c0e upstream. When inode is created and written to using direct IO, there is nothing to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets truncated later to say 1 byte and written using normal write, we will try to store the data as inline data. This confuses the code later because the inode now has both normal block and inline data allocated and the confusion manifests for example as: kernel BUG at fs/ext4/inode.c:2721! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:ext4_writepages+0x363d/0x3660 RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293 RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing direct IO write to a file. Cc: stable(a)kernel.org Reported-by: Tadeusz Struk <tadeusz.struk(a)linaro.org> Reported-by: syzbot+bd13648a53ed6933ca49(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c8229539… Signed-off-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Lukas Czerner <lczerner(a)redhat.com> Tested-by: Tadeusz Struk<tadeusz.struk(a)linaro.org> Link: https://lore.kernel.org/r/20220727155753.13969-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/ext4/file.c fs/ext4/inode.c [The current direct_IO implementation function of ext4 is ext4_direct_IO_write(), so modify it in this function.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/ext4/inode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 61c07bbeba03..8f38837f41f3 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3677,6 +3677,13 @@ static ssize_t ext4_direct_IO_write(struct kiocb *iocb, struct iov_iter *iter) int orphan = 0; handle_t *handle; + /* + * Make sure inline data cannot be created anymore since we are going + * to allocate blocks for DIO. We know the inode does not have any + * inline data now because ext4_dio_supported() checked for that. + */ + ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); + if (final_size > inode->i_size || final_size > ei->i_disksize) { /* Credits for sb + inode write */ handle = ext4_journal_start(inode, EXT4_HT_INODE, 2); -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] ipvs: Defer ip_vs_ftp unregister during netns cleanup
by Wang Liang 03 Nov '25

03 Nov '25

From: Slavin Liu <slavin452(a)gmail.com> mainline inclusion from mainline-v6.18-rc1 commit 134121bfd99a06d44ef5ba15a9beb075297c0821 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID3FOO CVE: CVE-2025-40018 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free. Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately. Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.") Suggested-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Slavin Liu <slavin452(a)gmail.com> Signed-off-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/netfilter/ipvs/ip_vs_ftp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c index 4398a72edec5..bed914dc138a 100644 --- a/net/netfilter/ipvs/ip_vs_ftp.c +++ b/net/netfilter/ipvs/ip_vs_ftp.c @@ -59,6 +59,7 @@ enum { IP_VS_FTP_EPSV, }; +static bool exiting_module; /* * List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper * First port is set to the default port. @@ -613,7 +614,7 @@ static void __ip_vs_ftp_exit(struct net *net) { struct netns_ipvs *ipvs = net_ipvs(net); - if (!ipvs) + if (!ipvs || !exiting_module) return; unregister_ip_vs_app(ipvs, &ip_vs_ftp); @@ -635,6 +636,7 @@ static int __init ip_vs_ftp_init(void) */ static void __exit ip_vs_ftp_exit(void) { + exiting_module = true; unregister_pernet_subsys(&ip_vs_ftp_ops); /* rcu_barrier() is called by netns */ } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/3] *** CVE-2023-53185 ***
by Ziming Du 03 Nov '25

03 Nov '25

*** BLURB HERE *** Dan Carpenter (1): ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb() Fedor Pchelkin (1): wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes Qiujun Huang (1): ath9k: Fix use-after-free Write in ath9k_htc_rx_msg drivers/net/wireless/ath/ath9k/htc_hst.c | 11 +++++++++++ 1 file changed, 11 insertions(+) -- 2.43.0

2 4

[openeuler:OLK-6.6 3083/3083] net/core/filter.c:12101:17: sparse: sparse: symbol 'bpf_xdp_change_dev' was not declared. Should it be static?
by kernel test robot 03 Nov '25

03 Nov '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 5394cae209c4a4990d81be436ba17ae56fb09d16 commit: 94ac90c1b608e26cfd82703606d5e13667983b96 [3083/3083] bpf: Add bpf_*_change_dev kfunc config: x86_64-randconfig-123-20251103 (https://download.01.org/0day-ci/archive/20251103/202511030954.SJ0Hsr2z-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251103/202511030954.SJ0Hsr2z-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/202511030954.SJ0Hsr2z-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) net/core/filter.c:1416:39: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sock_filter const *filter @@ got struct sock_filter [noderef] __user *filter @@ net/core/filter.c:1416:39: sparse: expected struct sock_filter const *filter net/core/filter.c:1416:39: sparse: got struct sock_filter [noderef] __user *filter net/core/filter.c:1494:39: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sock_filter const *filter @@ got struct sock_filter [noderef] __user *filter @@ net/core/filter.c:1494:39: sparse: expected struct sock_filter const *filter net/core/filter.c:1494:39: sparse: got struct sock_filter [noderef] __user *filter net/core/filter.c:2325:45: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected restricted __be32 [usertype] daddr @@ got unsigned int [usertype] ipv4_nh @@ net/core/filter.c:2325:45: sparse: expected restricted __be32 [usertype] daddr net/core/filter.c:2325:45: sparse: got unsigned int [usertype] ipv4_nh >> net/core/filter.c:12101:17: sparse: sparse: symbol 'bpf_xdp_change_dev' was not declared. Should it be static? net/core/filter.c:1931:43: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected restricted __wsum [usertype] diff @@ got unsigned long long [usertype] to @@ net/core/filter.c:1931:43: sparse: expected restricted __wsum [usertype] diff net/core/filter.c:1931:43: sparse: got unsigned long long [usertype] to net/core/filter.c:1934:36: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected restricted __be16 [usertype] old @@ got unsigned long long [usertype] from @@ net/core/filter.c:1934:36: sparse: expected restricted __be16 [usertype] old net/core/filter.c:1934:36: sparse: got unsigned long long [usertype] from net/core/filter.c:1934:42: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted __be16 [usertype] new @@ got unsigned long long [usertype] to @@ net/core/filter.c:1934:42: sparse: expected restricted __be16 [usertype] new net/core/filter.c:1934:42: sparse: got unsigned long long [usertype] to net/core/filter.c:1937:36: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected restricted __be32 [usertype] from @@ got unsigned long long [usertype] from @@ net/core/filter.c:1937:36: sparse: expected restricted __be32 [usertype] from net/core/filter.c:1937:36: sparse: got unsigned long long [usertype] from net/core/filter.c:1937:42: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted __be32 [usertype] to @@ got unsigned long long [usertype] to @@ net/core/filter.c:1937:42: sparse: expected restricted __be32 [usertype] to net/core/filter.c:1937:42: sparse: got unsigned long long [usertype] to net/core/filter.c:1982:59: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted __wsum [usertype] diff @@ got unsigned long long [usertype] to @@ net/core/filter.c:1982:59: sparse: expected restricted __wsum [usertype] diff net/core/filter.c:1982:59: sparse: got unsigned long long [usertype] to net/core/filter.c:1985:52: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted __be16 [usertype] from @@ got unsigned long long [usertype] from @@ net/core/filter.c:1985:52: sparse: expected restricted __be16 [usertype] from net/core/filter.c:1985:52: sparse: got unsigned long long [usertype] from net/core/filter.c:1985:58: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted __be16 [usertype] to @@ got unsigned long long [usertype] to @@ net/core/filter.c:1985:58: sparse: expected restricted __be16 [usertype] to net/core/filter.c:1985:58: sparse: got unsigned long long [usertype] to net/core/filter.c:1988:52: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted __be32 [usertype] from @@ got unsigned long long [usertype] from @@ net/core/filter.c:1988:52: sparse: expected restricted __be32 [usertype] from net/core/filter.c:1988:52: sparse: got unsigned long long [usertype] from net/core/filter.c:1988:58: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted __be32 [usertype] to @@ got unsigned long long [usertype] to @@ net/core/filter.c:1988:58: sparse: expected restricted __be32 [usertype] to net/core/filter.c:1988:58: sparse: got unsigned long long [usertype] to net/core/filter.c:2034:28: sparse: sparse: incorrect type in return expression (different base types) @@ expected unsigned long long @@ got restricted __wsum @@ net/core/filter.c:2034:28: sparse: expected unsigned long long net/core/filter.c:2034:28: sparse: got restricted __wsum net/core/filter.c:2056:35: sparse: sparse: incorrect type in return expression (different base types) @@ expected unsigned long long @@ got restricted __wsum [usertype] csum @@ net/core/filter.c:2056:35: sparse: expected unsigned long long net/core/filter.c:2056:35: sparse: got restricted __wsum [usertype] csum net/core/filter.c:5895:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] spi @@ got restricted __be32 const [usertype] spi @@ net/core/filter.c:5895:17: sparse: expected unsigned int [usertype] spi net/core/filter.c:5895:17: sparse: got restricted __be32 const [usertype] spi net/core/filter.c:5903:33: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] remote_ipv4 @@ got restricted __be32 const [usertype] a4 @@ net/core/filter.c:5903:33: sparse: expected unsigned int [usertype] remote_ipv4 net/core/filter.c:5903:33: sparse: got restricted __be32 const [usertype] a4 vim +/bpf_xdp_change_dev +12101 net/core/filter.c 12100 12101 __bpf_kfunc int bpf_xdp_change_dev(struct xdp_md *xdp_ctx, u32 ifindex) 12102 { 12103 struct xdp_buff *xdp = (struct xdp_buff *)xdp_ctx; 12104 struct hisock_xdp_buff *hxdp = (void *)xdp; 12105 struct net_device *dev; 12106 12107 WARN_ON_ONCE(!rcu_read_lock_held()); 12108 12109 if (!hxdp->skb) 12110 return -EOPNOTSUPP; 12111 12112 dev = dev_get_by_index_rcu(&init_net, ifindex); 12113 if (!dev) 12114 return -ENODEV; 12115 12116 hxdp->skb->dev = dev; 12117 return 0; 12118 } 12119 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] dm array: fix releasing a faulty array block twice in dm_array_cursor_end
by Li Lingfeng 03 Nov '25

03 Nov '25

From: Ming-Hung Tsai <mtsai(a)redhat.com> mainline inclusion from mainline-v6.13-rc7 commit f2893c0804d86230ffb8f1c8703fdbb18648abc8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBIQYC CVE: CVE-2024-57929 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When dm_bm_read_lock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dm_bm_read_lock() should not operate on this invalid dm_block pointer, or it will lead to undefined result. For example, the dm_array_cursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double release in dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put(). Reproduce steps: 1. initialize a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. wipe the second array block offline dmsteup remove cache cmeta cdata corig mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try reopen the cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Kernel logs: (snip) device-mapper: array: array_block_check failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: get_ablock failed device-mapper: cache metadata: dm_array_cursor_next for mapping failed ------------[ cut here ]------------ kernel BUG at drivers/md/dm-bufio.c:638! Fix by setting the cached block pointer to NULL on errors. In addition to the reproducer described above, this fix can be verified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir <KERNEL_DIR> Signed-off-by: Ming-Hung Tsai <mtsai(a)redhat.com> Fixes: fdd1315aa5f0 ("dm array: introduce cursor api") Reviewed-by: Joe Thornber <thornber(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/persistent-data/dm-array.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/md/persistent-data/dm-array.c b/drivers/md/persistent-data/dm-array.c index 185dc60360b5..849eb1b97c43 100644 --- a/drivers/md/persistent-data/dm-array.c +++ b/drivers/md/persistent-data/dm-array.c @@ -907,23 +907,27 @@ static int load_ablock(struct dm_array_cursor *c) if (c->block) unlock_ablock(c->info, c->block); - c->block = NULL; - c->ab = NULL; c->index = 0; r = dm_btree_cursor_get_value(&c->cursor, &key, &value_le); if (r) { DMERR("dm_btree_cursor_get_value failed"); - dm_btree_cursor_end(&c->cursor); + goto out; } else { r = get_ablock(c->info, le64_to_cpu(value_le), &c->block, &c->ab); if (r) { DMERR("get_ablock failed"); - dm_btree_cursor_end(&c->cursor); + goto out; } } + return 0; + +out: + dm_btree_cursor_end(&c->cursor); + c->block = NULL; + c->ab = NULL; return r; } -- 2.46.1

2 1

[PATCH OLK-6.6] KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
by Pan Taixi 03 Nov '25

03 Nov '25

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.6.113 commit cd3efb93677c4b0cf76348882fb429165fee33fd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID3WHO CVE: CVE-2025-40038 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0910dd7c9ad45a2605c45fd2bf3d1bcac087687c ] Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK> Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons). Fixes: b439eb8ab578 ("Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20250805190526.1453366-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> [ adapted switch-based MSR/HLT fastpath to if-based MSR-only check ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/kvm/svm/svm.c [Context conflicts due to stable commit ca3cc405a3bc ("KVM: x86: Move handling of is_guest_mode() into fastpath exit handlers") not merged. Also this makes nrip check comes after is_guest_mode check, which is fine as both checks return the same exit code.] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- arch/x86/kvm/svm/svm.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 8692b7892d0f..7bf68a753a97 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4206,8 +4206,17 @@ static int svm_vcpu_pre_run(struct kvm_vcpu *vcpu) static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu) { - if (to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR && - to_svm(vcpu)->vmcb->control.exit_info_1) + struct vcpu_svm *svm = to_svm(vcpu); + + /* + * Next RIP must be provided as IRQs are disabled, and accessing guest + * memory to decode the instruction might fault, i.e. might sleep. + */ + if (!nrips || !svm->vmcb->control.next_rip) + return EXIT_FASTPATH_NONE; + + if (svm->vmcb->control.exit_code == SVM_EXIT_MSR && + svm->vmcb->control.exit_info_1) return handle_fastpath_set_msr_irqoff(vcpu); return EXIT_FASTPATH_NONE; -- 2.34.1

2 1

[openeuler:OLK-6.6 3083/3083] mm/memcontrol.c:4061:5: sparse: sparse: symbol 'sysctl_memcg_oom_prio' was not declared. Should it be static?
by kernel test robot 03 Nov '25

03 Nov '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 5394cae209c4a4990d81be436ba17ae56fb09d16 commit: 44391f3171b05060096ff496f3507033f2460161 [3083/3083] memcg: Add sysctl memcg_qos_enable config: x86_64-randconfig-123-20251103 (https://download.01.org/0day-ci/archive/20251103/202511030753.dgyTecoe-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251103/202511030753.dgyTecoe-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/202511030753.dgyTecoe-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/memcontrol.c:4061:5: sparse: sparse: symbol 'sysctl_memcg_oom_prio' was not declared. Should it be static? mm/memcontrol.c:4223:50: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected void * @@ got void [noderef] __user *buffer @@ mm/memcontrol.c:4223:50: sparse: expected void * mm/memcontrol.c:4223:50: sparse: got void [noderef] __user *buffer mm/memcontrol.c:4245:35: sparse: sparse: incorrect type in initializer (incompatible argument 3 (different address spaces)) @@ expected int ( [usertype] *proc_handler )( ... ) @@ got int ( * )( ... ) @@ mm/memcontrol.c:4245:35: sparse: expected int ( [usertype] *proc_handler )( ... ) mm/memcontrol.c:4245:35: sparse: got int ( * )( ... ) mm/memcontrol.c:4504:21: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:4504:21: sparse: struct mem_cgroup_threshold_ary [noderef] __rcu * mm/memcontrol.c:4504:21: sparse: struct mem_cgroup_threshold_ary * mm/memcontrol.c:4506:21: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:4506:21: sparse: struct mem_cgroup_threshold_ary [noderef] __rcu * mm/memcontrol.c:4506:21: sparse: struct mem_cgroup_threshold_ary * mm/memcontrol.c:4662:9: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:4662:9: sparse: struct mem_cgroup_threshold_ary [noderef] __rcu * mm/memcontrol.c:4662:9: sparse: struct mem_cgroup_threshold_ary * mm/memcontrol.c:4756:9: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:4756:9: sparse: struct mem_cgroup_threshold_ary [noderef] __rcu * mm/memcontrol.c:4756:9: sparse: struct mem_cgroup_threshold_ary * mm/memcontrol.c:6799:23: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:6799:23: sparse: struct task_struct [noderef] __rcu * mm/memcontrol.c:6799:23: sparse: struct task_struct * mm/memcontrol.c:7016:52: sparse: sparse: incompatible types in comparison expression (different address spaces): mm/memcontrol.c:7016:52: sparse: struct task_struct [noderef] __rcu * mm/memcontrol.c:7016:52: sparse: struct task_struct * mm/memcontrol.c: note: in included file: include/linux/memcontrol.h:782:9: sparse: sparse: context imbalance in 'folio_lruvec_lock' - wrong count at exit include/linux/memcontrol.h:782:9: sparse: sparse: context imbalance in 'folio_lruvec_lock_irq' - wrong count at exit include/linux/memcontrol.h:782:9: sparse: sparse: context imbalance in 'folio_lruvec_lock_irqsave' - wrong count at exit mm/memcontrol.c:2134:6: sparse: sparse: context imbalance in 'folio_memcg_lock' - wrong count at exit mm/memcontrol.c:2181:17: sparse: sparse: context imbalance in '__folio_memcg_unlock' - unexpected unlock mm/memcontrol.c:6659:9: sparse: sparse: context imbalance in 'mem_cgroup_count_precharge_pte_range' - unexpected unlock mm/memcontrol.c:6927:9: sparse: sparse: context imbalance in 'mem_cgroup_move_charge_pte_range' - unexpected unlock vim +/sysctl_memcg_oom_prio +4061 mm/memcontrol.c 4057 4058 #ifdef CONFIG_MEMCG_OOM_PRIORITY 4059 #define ENABLE_MEMCG_OOM_PROIRITY 1 4060 #define DISABLE_MEMCG_OOM_PROIRITY 0 > 4061 int sysctl_memcg_oom_prio = DISABLE_MEMCG_OOM_PROIRITY; 4062 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0