- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP2] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 33f2da805c97..f3e30cb52883 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 1686e7aea823..9bfa0b6b3771 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1126,6 +1126,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS-SP1] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 33f2da805c97..f3e30cb52883 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-5.10] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 33f2da805c97..f3e30cb52883 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-5.10] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 6e87964c5c0a..bf65aec6bfc0 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-5.10] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 6e87964c5c0a..bf65aec6bfc0 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-5.10] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 33f2da805c97..6e87964c5c0a 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1223,6 +1223,8 @@ static int ubifs_symlink(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-5.10] ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
by ZhaoLong Wang 11 May '24

11 May '24

From: Zhihao Cheng <chengzhihao1(a)huawei.com> stable inclusion from stable-v5.10.210 commit d132010e6d5c0cb2e28ce9e91ab3ad0ad4cd1063 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5M6 CVE: CVE-2024-26972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream. For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. Cc: stable(a)vger.kernel.org Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link") Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/ubifs/dir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 6e87964c5c0a..bf65aec6bfc0 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1124,6 +1124,8 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); out_inode: + /* Free inode->i_link before inode is marked as bad. */ + fscrypt_free_inode(inode); make_bad_inode(inode); iput(inode); out_fname: -- 2.34.3

2 1

[PATCH OLK-6.6 v2] tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled
by Yu Liao 11 May '24

11 May '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8PL17 CVE: NA ---------------------------------------- It was found that running the LTP hotplug stress test on a aarch64 system could produce rcu_sched stall warnings. The issue is the following: CPU1 (owns the broadcast hrtimer) CPU2 tick_broadcast_enter() //shut down local timer device ... tick_broadcast_exit() //exits with tick_broadcast_force_mask set, timer device remains disabled initiates offlining of CPU1 take_cpu_down() //CPU1 shuts down and does not send broadcast IPI anymore takedown_cpu() hotplug_cpu__broadcast_tick_pull() //move broadcast hrtimer to this CPU clockevents_program_event() bc_set_next() hrtimer_start() //does not call hrtimer_reprogram() to program timer device if expires equals dev->next_event, so the timer device remains disabled. CPU2 takes over the broadcast duty but local timer device is disabled, causing many CPUs to become stuck. Fix this by calling tick_program_event() to reprogram the local timer device in this scenario. Fixes: 5d1638acb9f6 ("tick: Introduce hrtimer based broadcast") Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- kernel/time/tick-broadcast-hrtimer.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c index e28f9210f8a1..0dc78744fce6 100644 --- a/kernel/time/tick-broadcast-hrtimer.c +++ b/kernel/time/tick-broadcast-hrtimer.c @@ -42,6 +42,19 @@ static int bc_shutdown(struct clock_event_device *evt) */ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) { + struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); + + /* + * This can be called from CPU offline operation to move broadcast + * assignment. If tick_broadcast_force_mask is set, the CPU local + * timer device may be disabled. And hrtimer_reprogram() will not + * called if the timer is not the first expiring timer. Reprogram + * the cpu local timer device to ensure we can take over the + * broadcast duty. + */ + if (tick_check_broadcast_expired() && expires >= dev->next_event) + clockevents_program_event(dev, dev->next_event, 1); + /* * This is called either from enter/exit idle code or from the * broadcast handler. In all cases tick_broadcast_lock is held. -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v2] usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
by Wei Li 11 May '24

11 May '24

From: Norihiko Hama <Norihiko.Hama(a)alpsalpine.com> mainline inclusion from mainline-v6.9-rc5 commit 6334b8e4553cc69f51e383c9de545082213d785e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5KV CVE: CVE-2024-26996 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established. Signed-off-by: Norihiko Hama <Norihiko.Hama(a)alpsalpine.com> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20240327023550.51214-1-Norihiko.Hama@alpsalpine.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/usb/gadget/function/f_ncm.c [lw: fix context conflict only] Signed-off-by: Wei Li <liwei391(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index 5780fba620ab..3da7e6511fc6 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -885,7 +885,7 @@ static int ncm_set_alt(struct usb_function *f, unsigned intf, unsigned alt) if (alt > 1) goto fail; - if (ncm->port.in_ep->enabled) { + if (ncm->netdev) { DBG(cdev, "reset ncm\n"); ncm->timer_stopping = true; ncm->netdev = NULL; @@ -1322,7 +1322,7 @@ static void ncm_disable(struct usb_function *f) DBG(cdev, "ncm deactivated\n"); - if (ncm->port.in_ep->enabled) { + if (ncm->netdev) { ncm->timer_stopping = true; ncm->netdev = NULL; gether_disconnect(&ncm->port); -- 2.25.1

2 1