[PATCH openEuler-1.0-LTS 1/2] livepatch/core: Fix livepatch/state leak on error path
From: Zheng Yejian <zhengyejian1@huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5WF0G CVE: NA -------------------------------- File '/proc/livepatch/state' should be removed before removing '/proc/livepatch', otherwise following log will appear: remove_proc_entry: removing non-empty directory '/proc/livepatch', leaking at least 'state' Fixes: 19190325e604 ("livepatch/core: Allow implementation without ftrace") Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> Reviewed-by: Kuohai Xu <xukuohai@huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> --- kernel/livepatch/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index 89b31e827425..af077abe099b 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -1489,10 +1489,12 @@ static int __init klp_init(void) klp_root_kobj = kobject_create_and_add("livepatch", kernel_kobj); if (!klp_root_kobj) - goto error_remove; + goto error_remove_state; return 0; +error_remove_state: + remove_proc_entry("livepatch/state", NULL); error_remove: remove_proc_entry("livepatch", NULL); error_out: -- 2.25.1
From: Ye Bin <yebin10@huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Z79B CVE: NA -------------------------------- There's issue as follows when do test with memory fault injection: [localhost]# fsck.ext4 -a image image: clean, 45595/655360 files, 466841/2621440 blocks [localhost]# fsck.ext4 -fn image Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(1457230--1457256) Fix? no image: ********** WARNING: Filesystem still has errors ********** image: 45595/655360 files (12.4% non-contiguous), 466841/2621440 blocks Inject context: ----------------------------------------------------------- Inject function:kmem_cache_alloc (pid:177858) (return: 0) Calltrace Context: mem_cache_allock+0x73/0xcc ext4_mb_new_blocks+0x32e/0x540 [ext4] ext4_new_meta_blocks+0xc4/0x110 [ext4] ext4_ext_grow_indepth+0x68/0x250 [ext4] ext4_ext_create_new_leaf+0xc5/0x120 [ext4] ext4_ext_insert_extent+0x1bf/0x670 [ext4] ext4_split_extent_at+0x212/0x530 [ext4] ext4_split_extent+0x13a/0x1a0 [ext4] ext4_ext_handle_unwritten_extents+0x13d/0x240 [ext4] ext4_ext_map_blocks+0x459/0x8f0 [ext4] ext4_map_blocks+0x18e/0x5a0 [ext4] ext4_iomap_alloc+0xb0/0x1b0 [ext4] ext4_iomap_begin+0xb0/0x130 [ext4] iomap_apply+0x95/0x2e0 __iomap_dio_rw+0x1cc/0x4b0 iomap_dio_rw+0xe/0x40 ext4_dio_write_iter+0x1a9/0x390 [ext4] new_sync_write+0x113/0x1b0 vfs_write+0x1b7/0x250 ksys_write+0x5f/0xe0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Compare extent change in journal: Start: ee_block ee_len ee_start 75 32798 1457227 -> unwritten len=30 308 12 434489 355 5 442492 => ee_block ee_len ee_start 11 2 951584 74 32769 951647 -> unwritten len=1 75 32771 1457227 -> unwritten len=3, length decreased 27 211 15 960906 308 12 434489 355 5 442492 Acctually, above issue can repaired by 'fsck -fa'. But file system is 'clean', 'fsck' will not do deep repair. Obviously, final lost 27 blocks. Above issue may happens as follows: ext4_split_extent_at ... err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags); -> return -ENOMEM if (err != -ENOSPC && err != -EDQUOT） goto out; -> goto 'out' will not fix extent length, will ... fix_extent_len: ex->ee_len = orig_ex.ee_len; /* * Ignore ext4_ext_dirty return value since we are already in error path * and err is a non-zero error code. */ ext4_ext_dirty(handle, inode, path + path->p_depth); return err; out: ext4_ext_show_leaf(inode, path); return err; If 'ext4_ext_insert_extent' return '-ENOMEM' which will not fix 'ex->ee_len' by old length. 'ext4_ext_insert_extent' will trigger extent tree merge, fix like 'ex->ee_len = orig_ex.ee_len' may lead to new issues. To solve above issue, record error messages when 'ext4_ext_insert_extent' return 'err' not equal '(-ENOSPC && -EDQUOT)'. If filesysten is mounted with 'errors=continue' as filesystem is not clean 'fsck' will repair issue. If filesystem is mounted with 'errors=remount-ro' filesystem will be remounted by read-only. Signed-off-by: Ye Bin <yebin10@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> --- fs/ext4/extents.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e3e0cdb20627..578769f10906 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3337,8 +3337,13 @@ static int ext4_split_extent_at(handle_t *handle, ext4_ext_mark_unwritten(ex2); err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags); - if (err != -ENOSPC && err != -EDQUOT) + if (err != -ENOSPC && err != -EDQUOT) { + if (err) + EXT4_ERROR_INODE_ERR(inode, -err, + "insert extent failed block = %d len = %d", + ex2->ee_block, ex2->ee_len); goto out; + } if (EXT4_EXT_MAY_ZEROOUT & split_flag) { if (split_flag & (EXT4_EXT_DATA_VALID1|EXT4_EXT_DATA_VALID2)) { -- 2.25.1
participants (1)
-
Yongqiang Liu