- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 13/13] drivers/ub/ubus/port.c:31:5: warning: no previous prototype for 'ub_port_read_byte'
by kernel test robot 26 Dec '25

26 Dec '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 52a3b0aa13aa2325ca2caf528fbcaba06ad3bab5 commit: 210be966e79360fac509e7d66f9adb1712146c14 [13/13] ub:ubus: Support for UB port sysfs attribute files config: arm64-randconfig-004-20251226 (https://download.01.org/0day-ci/archive/20251226/202512261132.sMR3WqA2-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251226/202512261132.sMR3WqA2-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/202512261132.sMR3WqA2-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/ubus/port.c:31:5: warning: no previous prototype for 'ub_port_read_byte' [-Wmissing-prototypes] 31 | int ub_port_read_byte(struct ub_port *port, u32 pos, u8 *val) | ^~~~~~~~~~~~~~~~~ >> drivers/ub/ubus/port.c:38:5: warning: no previous prototype for 'ub_port_read_word' [-Wmissing-prototypes] 38 | int ub_port_read_word(struct ub_port *port, u32 pos, u16 *val) | ^~~~~~~~~~~~~~~~~ >> drivers/ub/ubus/port.c:45:5: warning: no previous prototype for 'ub_port_read_dword' [-Wmissing-prototypes] 45 | int ub_port_read_dword(struct ub_port *port, u32 pos, u32 *val) | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/ubus/port.c:52:5: warning: no previous prototype for 'ub_port_write_byte' [-Wmissing-prototypes] 52 | int ub_port_write_byte(struct ub_port *port, u32 pos, u8 val) | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/ubus/port.c:59:5: warning: no previous prototype for 'ub_port_write_word' [-Wmissing-prototypes] 59 | int ub_port_write_word(struct ub_port *port, u32 pos, u16 val) | ^~~~~~~~~~~~~~~~~~ drivers/ub/ubus/port.c:66:5: warning: no previous prototype for 'ub_port_write_dword' [-Wmissing-prototypes] 66 | int ub_port_write_dword(struct ub_port *port, u32 pos, u32 val) | ^~~~~~~~~~~~~~~~~~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for RESCTRL_FS Depends on [n]: MISC_FILESYSTEMS [=n] && ARCH_HAS_CPU_RESCTRL [=y] Selected by [y]: - ARM64_MPAM [=y] vim +/ub_port_read_byte +31 drivers/ub/ubus/port.c 21 22 #define UB_PORT_ATTR_RO(field) \ 23 static struct ub_port_attribute ub_port_attr_##field = __ATTR_RO(field) 24 25 #define UB_PORT_ATTR_RW(field) \ 26 static struct ub_port_attribute ub_port_attr_##field = __ATTR_RW(field) 27 28 #define UB_PORT_ATTR_WO(field) \ 29 static struct ub_port_attribute ub_port_attr_##field = __ATTR_WO(field) 30 > 31 int ub_port_read_byte(struct ub_port *port, u32 pos, u8 *val) 32 { 33 u64 base = UB_PORT_SLICE_START + port->index * UB_PORT_SLICE_SIZE; 34 35 return ub_cfg_read_byte(port->uent, base + pos, val); 36 } 37 > 38 int ub_port_read_word(struct ub_port *port, u32 pos, u16 *val) 39 { 40 u64 base = UB_PORT_SLICE_START + port->index * UB_PORT_SLICE_SIZE; 41 42 return ub_cfg_read_word(port->uent, base + pos, val); 43 } 44 > 45 int ub_port_read_dword(struct ub_port *port, u32 pos, u32 *val) 46 { 47 u64 base = UB_PORT_SLICE_START + port->index * UB_PORT_SLICE_SIZE; 48 49 return ub_cfg_read_dword(port->uent, base + pos, val); 50 } 51 > 52 int ub_port_write_byte(struct ub_port *port, u32 pos, u8 val) 53 { 54 u64 base = UB_PORT_SLICE_START + port->index * UB_PORT_SLICE_SIZE; 55 56 return ub_cfg_write_byte(port->uent, base + pos, val); 57 } 58 > 59 int ub_port_write_word(struct ub_port *port, u32 pos, u16 val) 60 { 61 u64 base = UB_PORT_SLICE_START + port->index * UB_PORT_SLICE_SIZE; 62 63 return ub_cfg_write_word(port->uent, base + pos, val); 64 } 65 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] ext4: xattr: fix null pointer deref in ext4_raw_inode()
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Karina Yankevich <k.yankevich(a)omp.ru> mainline inclusion from mainline-v6.19-rc1 commit b97cb7d6a051aa6ebd57906df0e26e9e36c26d14 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13034 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c8e008b60492 ("ext4: ignore xattrs past end") Cc: stable(a)kernel.org Signed-off-by: Karina Yankevich <k.yankevich(a)omp.ru> Reviewed-by: Sergey Shtylyov <s.shtylyov(a)omp.ru> Reviewed-by: Baokun Li <libaokun1(a)huawei.com> Message-ID: <20251022093253.3546296-1-k.yankevich(a)omp.ru> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/xattr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 3e5efa68698e..fd44b8c0c4af 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1133,7 +1133,11 @@ ext4_xattr_inode_dec_ref_all(handle_t *handle, struct inode *parent, if (block_csum) end = (void *)bh->b_data + bh->b_size; else { - ext4_get_inode_loc(parent, &iloc); + err = ext4_get_inode_loc(parent, &iloc); + if (err) { + EXT4_ERROR_INODE(parent, "parent inode loc (error %d)", err); + return; + } end = (void *)ext4_raw_inode(&iloc) + EXT4_SB(parent->i_sb)->s_inode_size; } -- 2.39.2

2 1

[PATCH OLK-6.6] ext4: xattr: fix null pointer deref in ext4_raw_inode()
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Karina Yankevich <k.yankevich(a)omp.ru> mainline inclusion from mainline-v6.19-rc1 commit b97cb7d6a051aa6ebd57906df0e26e9e36c26d14 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13034 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c8e008b60492 ("ext4: ignore xattrs past end") Cc: stable(a)kernel.org Signed-off-by: Karina Yankevich <k.yankevich(a)omp.ru> Reviewed-by: Sergey Shtylyov <s.shtylyov(a)omp.ru> Reviewed-by: Baokun Li <libaokun1(a)huawei.com> Message-ID: <20251022093253.3546296-1-k.yankevich(a)omp.ru> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/xattr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 6ef8820625b9..5009fdcfe150 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1184,7 +1184,11 @@ ext4_xattr_inode_dec_ref_all(handle_t *handle, struct inode *parent, if (block_csum) end = (void *)bh->b_data + bh->b_size; else { - ext4_get_inode_loc(parent, &iloc); + err = ext4_get_inode_loc(parent, &iloc); + if (err) { + EXT4_ERROR_INODE(parent, "parent inode loc (error %d)", err); + return; + } end = (void *)ext4_raw_inode(&iloc) + EXT4_SB(parent->i_sb)->s_inode_size; } -- 2.39.2

2 1

[PATCH OLK-6.6] jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Ye Bin <yebin10(a)huawei.com> mainline inclusion from mainline-v6.19-rc1 commit 986835bf4d11032bba4ab8414d18fce038c61bb4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12698 CVE: CVE-2025-68337 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON. Fixes: 470decc613ab ("[PATCH] jbd2: initial copy of files from jbd") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Message-ID: <20251025072657.307851-1-yebin(a)huaweicloud.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/jbd2/transaction.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c index c2b8ad0b24c4..970bebe1dadb 100644 --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -1274,14 +1274,23 @@ int jbd2_journal_get_create_access(handle_t *handle, struct buffer_head *bh) * committing transaction's lists, but it HAS to be in Forget state in * that case: the transaction must have deleted the buffer for it to be * reused here. + * In the case of file system data inconsistency, for example, if the + * block bitmap of a referenced block is not set, it can lead to the + * situation where a block being committed is allocated and used again. + * As a result, the following condition will not be satisfied, so here + * we directly trigger a JBD abort instead of immediately invoking + * bugon. */ spin_lock(&jh->b_state_lock); - J_ASSERT_JH(jh, (jh->b_transaction == transaction || - jh->b_transaction == NULL || - (jh->b_transaction == journal->j_committing_transaction && - jh->b_jlist == BJ_Forget))); + if (!(jh->b_transaction == transaction || jh->b_transaction == NULL || + (jh->b_transaction == journal->j_committing_transaction && + jh->b_jlist == BJ_Forget)) || jh->b_next_transaction != NULL) { + err = -EROFS; + spin_unlock(&jh->b_state_lock); + jbd2_journal_abort(journal, err); + goto out; + } - J_ASSERT_JH(jh, jh->b_next_transaction == NULL); J_ASSERT_JH(jh, buffer_locked(jh2bh(jh))); if (jh->b_transaction == NULL) { -- 2.39.2

2 1

[openeuler:OLK-6.6 13/13] drivers/ub/ubus/ubus_config.c:191:6: warning: no previous prototype for 'ub_sync_cfg_rsp_handle'
by kernel test robot 26 Dec '25

26 Dec '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 52a3b0aa13aa2325ca2caf528fbcaba06ad3bab5 commit: 280895301d3bc3507606cbd2e3cdccba75a8dcdc [13/13] ub:ubus: Support Ubus read/write configuration functions config: arm64-randconfig-004-20251226 (https://download.01.org/0day-ci/archive/20251226/202512260914.fC4Pfn5g-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251226/202512260914.fC4Pfn5g-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/202512260914.fC4Pfn5g-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/ubus/ubus_config.c:191:6: warning: no previous prototype for 'ub_sync_cfg_rsp_handle' [-Wmissing-prototypes] 191 | void ub_sync_cfg_rsp_handle(struct cfg_msg_pld_rsp *rsp, u8 size, | ^~~~~~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:310:5: warning: no previous prototype for '__ub_cfg_read_byte' [-Wmissing-prototypes] 310 | int __ub_cfg_read_byte(struct ub_entity *uent, u64 pos, u8 *val) | ^~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:320:5: warning: no previous prototype for '__ub_cfg_read_word' [-Wmissing-prototypes] 320 | int __ub_cfg_read_word(struct ub_entity *uent, u64 pos, u16 *val) | ^~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:330:5: warning: no previous prototype for '__ub_cfg_read_dword' [-Wmissing-prototypes] 330 | int __ub_cfg_read_dword(struct ub_entity *uent, u64 pos, u32 *val) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:340:5: warning: no previous prototype for '__ub_cfg_write_byte' [-Wmissing-prototypes] 340 | int __ub_cfg_write_byte(struct ub_entity *uent, u64 pos, u8 val) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:350:5: warning: no previous prototype for '__ub_cfg_write_word' [-Wmissing-prototypes] 350 | int __ub_cfg_write_word(struct ub_entity *uent, u64 pos, u16 val) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/ubus/ubus_config.c:360:5: warning: no previous prototype for '__ub_cfg_write_dword' [-Wmissing-prototypes] 360 | int __ub_cfg_write_dword(struct ub_entity *uent, u64 pos, u32 val) | ^~~~~~~~~~~~~~~~~~~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for RESCTRL_FS Depends on [n]: MISC_FILESYSTEMS [=n] && ARCH_HAS_CPU_RESCTRL [=y] Selected by [y]: - ARM64_MPAM [=y] vim +/ub_sync_cfg_rsp_handle +191 drivers/ub/ubus/ubus_config.c 190 > 191 void ub_sync_cfg_rsp_handle(struct cfg_msg_pld_rsp *rsp, u8 size, 192 u64 pos, bool write, u32 *val) 193 { 194 #define UB_CFG_REG_SIZE 4 195 u8 pos_in_reg = pos % UB_CFG_REG_SIZE; 196 u32 read_data; 197 198 if (!write) { 199 read_data = rsp->read_data >> (pos_in_reg * BITS_PER_BYTE); 200 if (size == sizeof(u8)) 201 *(u8 *)val = read_data; 202 else if (size == sizeof(u16)) 203 *(u16 *)val = read_data; 204 else 205 *val = read_data; 206 } 207 } 208 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock
by Yongjian Sun 26 Dec '25

26 Dec '25

From: chuguangqing <chuguangqing(a)inspur.com> mainline inclusion from mainline-v6.18-rc1 commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12622 CVE: CVE-2025-40361 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag. Signed-off-by: chuguangqing <chuguangqing(a)inspur.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 5009fdcfe150..cd906aa08afa 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1549,7 +1549,7 @@ ext4_xattr_inode_cache_find(struct inode *inode, const void *value, WARN_ON_ONCE(ext4_handle_valid(journal_current_handle()) && !(current->flags & PF_MEMALLOC_NOFS)); - ea_data = kvmalloc(value_len, GFP_KERNEL); + ea_data = kvmalloc(value_len, GFP_NOFS); if (!ea_data) { mb_cache_entry_put(ea_inode_cache, ce); return NULL; -- 2.39.2

2 1

[PATCH OLK-6.6] ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Alexey Nepomnyashih <sdl(a)nppct.ru> mainline inclusion from mainline-v6.19-rc1 commit 0cd8feea8777f8d9b9a862b89c688b049a5c8475 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11541 CVE: CVE-2025-68261 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix a race between inline data destruction and block mapping. The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks(). Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert. kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546 Call Trace: <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: c755e251357a ("ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea()") Cc: stable(a)vger.kernel.org # v4.11+ Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> Message-ID: <20251104093326.697381-1-sdl(a)nppct.ru> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/inline.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index 5fa1dd58ac42..bc6960c30a03 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -441,9 +441,13 @@ static int ext4_destroy_inline_data_nolock(handle_t *handle, if (!ei->i_inline_off) return 0; + down_write(&ei->i_data_sem); + error = ext4_get_inode_loc(inode, &is.iloc); - if (error) + if (error) { + up_write(&ei->i_data_sem); return error; + } error = ext4_xattr_ibody_find(inode, &i, &is); if (error) @@ -482,6 +486,7 @@ static int ext4_destroy_inline_data_nolock(handle_t *handle, brelse(is.iloc.bh); if (error == -ENODATA) error = 0; + up_write(&ei->i_data_sem); return error; } -- 2.39.2

2 1

[PATCH OLK-6.6] ext4: refresh inline data size before write operations
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Deepanshu Kartikey <kartikey406(a)gmail.com> mainline inclusion from mainline-v6.19-rc1 commit 892e1cf17555735e9d021ab036c36bc7b58b0e3b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11537 CVE: CVE-2025-68264 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired. This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications. This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue. Reported-by: syzbot+f3185be57d7e8dda32b8(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8 Cc: stable(a)kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Message-ID: <20251020060936.474314-1-kartikey406(a)gmail.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/inline.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index bc6960c30a03..0cb175a1abe0 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -413,7 +413,12 @@ static int ext4_prepare_inline_data(handle_t *handle, struct inode *inode, return -ENOSPC; ext4_write_lock_xattr(inode, &no_expand); - + /* + * ei->i_inline_size may have changed since the initial check + * if other xattrs were added. Recalculate to ensure + * ext4_update_inline_data() validates against current capacity. + */ + (void) ext4_find_inline_data_nolock(inode); if (ei->i_inline_off) ret = ext4_update_inline_data(handle, inode, len); else -- 2.39.2

2 1

[PATCH OLK-6.6] hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
by Yongjian Sun 26 Dec '25

26 Dec '25

From: Viacheslav Dubeyko <slava(a)dubeyko.com> mainline inclusion from mainline-v6.18-rc1 commit 9b3d15a758910bb98ba8feb4109d99cc67450ee4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11613 CVE: CVE-2025-40351 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Tainted: G B 6.12.0-rc6-dirty #17 [ 70.715007][ T9333] Tainted: [B]=BAD_PAGE [ 70.715365][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.716311][ T9333] Call Trace: [ 70.716621][ T9333] <TASK> [ 70.716899][ T9333] dump_stack_lvl+0x1fd/0x2b0 [ 70.717350][ T9333] dump_stack+0x1e/0x30 [ 70.717743][ T9333] panic+0x502/0xca0 [ 70.718116][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.718611][ T9333] kmsan_report+0x296/0x2a0 [ 70.719038][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.719859][ T9333] ? __msan_warning+0x96/0x120 [ 70.720345][ T9333] ? hfsplus_subfolders_dec+0x1d7/0x220 [ 70.720881][ T9333] ? hfsplus_delete_cat+0x105d/0x12b0 [ 70.721412][ T9333] ? hfsplus_rmdir+0x13d/0x310 [ 70.721880][ T9333] ? vfs_rmdir+0x5ba/0x810 [ 70.722458][ T9333] ? do_rmdir+0x964/0xea0 [ 70.722883][ T9333] ? __x64_sys_rmdir+0x71/0xb0 [ 70.723397][ T9333] ? x64_sys_call+0xcd8/0x3cf0 [ 70.723915][ T9333] ? do_syscall_64+0xd9/0x1d0 [ 70.724454][ T9333] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.725110][ T9333] ? vprintk_emit+0xd1f/0xe60 [ 70.725616][ T9333] ? vprintk_default+0x3f/0x50 [ 70.726175][ T9333] ? vprintk+0xce/0xd0 [ 70.726628][ T9333] ? _printk+0x17e/0x1b0 [ 70.727129][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.727739][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.728324][ T9333] __msan_warning+0x96/0x120 [ 70.728854][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.729479][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.729984][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.730646][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.731296][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.731863][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.732390][ T9333] ? __pfx_hfsplus_rmdir+0x10/0x10 [ 70.732919][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.733416][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.734044][ T9333] do_rmdir+0x964/0xea0 [ 70.734537][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.735032][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.735579][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.736092][ T9333] ? irqentry_exit+0x16/0x60 [ 70.736637][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.737269][ T9333] RIP: 0033:0x7fa9424eafc9 [ 70.737775][ T9333] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 70.739844][ T9333] RSP: 002b:00007fff099cd8d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000054 [ 70.740760][ T9333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa9424eafc9 [ 70.741642][ T9333] RDX: 006c6f72746e6f63 RSI: 000000000000000a RDI: 0000000020000100 [ 70.742543][ T9333] RBP: 00007fff099cd8e0 R08: 00007fff099cd910 R09: 00007fff099cd910 [ 70.743376][ T9333] R10: 0000000000000000 R11: 0000000000000202 R12: 0000565430642260 [ 70.744247][ T9333] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 70.745082][ T9333] </TASK> The main reason of the issue that struct hfsplus_inode_info has not been properly initialized for the case of root folder. In the case of root folder, hfsplus_fill_super() calls the hfsplus_iget() that implements only partial initialization of struct hfsplus_inode_info and subfolders field is not initialized by hfsplus_iget() logic. This patch implements complete initialization of struct hfsplus_inode_info in the hfsplus_iget() logic with the goal to prevent likewise issues for the case of root folder. Reported-by: syzbot <syzbot+fdedff847a0e5e84c39f(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=fdedff847a0e5e84c39f Signed-off-by: Viacheslav Dubeyko <slava(a)dubeyko.com> cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> cc: Yangtao Li <frank.li(a)vivo.com> cc: linux-fsdevel(a)vger.kernel.org Link: https://lore.kernel.org/r/20250825225103.326401-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava(a)dubeyko.com> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/hfsplus/super.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 1986b4f18a90..8c086f16dd58 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -67,13 +67,26 @@ struct inode *hfsplus_iget(struct super_block *sb, unsigned long ino) if (!(inode->i_state & I_NEW)) return inode; - INIT_LIST_HEAD(&HFSPLUS_I(inode)->open_dir_list); - spin_lock_init(&HFSPLUS_I(inode)->open_dir_lock); - mutex_init(&HFSPLUS_I(inode)->extents_lock); - HFSPLUS_I(inode)->flags = 0; + atomic_set(&HFSPLUS_I(inode)->opencnt, 0); + HFSPLUS_I(inode)->first_blocks = 0; + HFSPLUS_I(inode)->clump_blocks = 0; + HFSPLUS_I(inode)->alloc_blocks = 0; + HFSPLUS_I(inode)->cached_start = U32_MAX; + HFSPLUS_I(inode)->cached_blocks = 0; + memset(HFSPLUS_I(inode)->first_extents, 0, sizeof(hfsplus_extent_rec)); + memset(HFSPLUS_I(inode)->cached_extents, 0, sizeof(hfsplus_extent_rec)); HFSPLUS_I(inode)->extent_state = 0; + mutex_init(&HFSPLUS_I(inode)->extents_lock); HFSPLUS_I(inode)->rsrc_inode = NULL; - atomic_set(&HFSPLUS_I(inode)->opencnt, 0); + HFSPLUS_I(inode)->create_date = 0; + HFSPLUS_I(inode)->linkid = 0; + HFSPLUS_I(inode)->flags = 0; + HFSPLUS_I(inode)->fs_blocks = 0; + HFSPLUS_I(inode)->userflags = 0; + HFSPLUS_I(inode)->subfolders = 0; + INIT_LIST_HEAD(&HFSPLUS_I(inode)->open_dir_list); + spin_lock_init(&HFSPLUS_I(inode)->open_dir_lock); + HFSPLUS_I(inode)->phys_size = 0; if (inode->i_ino >= HFSPLUS_FIRSTUSER_CNID || inode->i_ino == HFSPLUS_ROOT_CNID) { -- 2.39.2

2 1

[PATCH OLK-6.6] Bluetooth: hci_event: validate skb length for unknown CC opcode
by Zhang Hongtao 26 Dec '25

26 Dec '25

From: Raphael Pinsonneault-Thibeault <rpthibeault(a)gmail.com> mainline inclusion from mainline-v6.12-rc5 commit 5c5f1f64681cc889d9b13e4a61285e9e029d6ab5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDBAAQ CVE: CVE-2025-40301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------- In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data. Reported-by: syzbot+a9a4bedfca6aa9d7fa24(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a9a4bedfca6aa9d7fa24 Tested-by: syzbot+a9a4bedfca6aa9d7fa24(a)syzkaller.appspotmail.com Fixes: afcb3369f46ed ("Bluetooth: hci_event: Fix vendor (unknown) opcode status handling") Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault(a)gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Hongtao Zhang <zhanghongtao35(a)huawei.com> --- net/bluetooth/hci_event.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index ee9cd3d34c2d..cc95c9236921 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -4245,6 +4245,13 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, void *data, } if (i == ARRAY_SIZE(hci_cc_table)) { + if (!skb->len) { + bt_dev_err(hdev, "Unexpected cc 0x%4.4x with no status", + *opcode); + *status = HCI_ERROR_UNSPECIFIED; + return; + } + /* Unknown opcode, assume byte 0 contains the status, so * that e.g. __hci_cmd_sync() properly returns errors * for vendor specific commands send by HCI drivers. -- 2.34.1

2 1