[PATCH 4.19 242/321] kvm: properly check debugfs dentry before using it

[PATCH 4.19 242/321] kvm: properly check debugfs dentry before using it

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 8ed0579c12b2fe56a1fac2f712f58fc26c1dc49b ]

debugfs can now report an error code if something went wrong instead of
just NULL.  So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.

This is now happening because of ff9fb72bc077 ("debugfs: return error
values, not NULL").  syzbot has found a way to trigger multiple debugfs
files attempting to be created, which fails, and then the error code
gets passed to dentry_path_raw() which obviously does not like it.

Reported-by: Eric Biggers <ebiggers@kernel.org>
Reported-and-tested-by: syzbot+7857962b4d45e602b8ad@syzkaller.appspotmail.com
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 virt/kvm/kvm_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index df3fc0f214ece..9502b1a44232c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3990,7 +3990,7 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
 	}
 	add_uevent_var(env, "PID=%d", kvm->userspace_pid);
 
-	if (kvm->debugfs_dentry) {
+	if (!IS_ERR_OR_NULL(kvm->debugfs_dentry)) {
 		char *tmp, *p = kmalloc(PATH_MAX, GFP_KERNEL);
 
 		if (p) {
-- 
2.20.1

Re: [PATCH 4.19 242/321] kvm: properly check debugfs dentry before using it

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

Hi!

> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> [ Upstream commit 8ed0579c12b2fe56a1fac2f712f58fc26c1dc49b ]
> 
> debugfs can now report an error code if something went wrong instead of
> just NULL.  So if the return value is to be used as a "real" dentry, it
> needs to be checked if it is an error before dereferencing it.
> 
> This is now happening because of ff9fb72bc077 ("debugfs: return error
> values, not NULL").  syzbot has found a way to trigger multiple debugfs
> files attempting to be created, which fails, and then the error code
> gets passed to dentry_path_raw() which obviously does not like it.

4.19-stable does not contain patch ff9fb72bc077, so is this still good
idea? It should not break anything, as it still uses IS_ERR_OR_NULL,
but...

Best regards,
								Pavel

> +++ b/virt/kvm/kvm_main.c
> @@ -3990,7 +3990,7 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
>  	}
>  	add_uevent_var(env, "PID=%d", kvm->userspace_pid);
>  
> -	if (kvm->debugfs_dentry) {
> +	if (!IS_ERR_OR_NULL(kvm->debugfs_dentry)) {
>  		char *tmp, *p = kmalloc(PATH_MAX, GFP_KERNEL);
>  
>  		if (p) {

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 4.19 242/321] kvm: properly check debugfs dentry before using it

[Greg Kroah-Hartman]

On Thu, Dec 05, 2019 at 11:29:28PM +0100, Pavel Machek wrote:
> Hi!
> 
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > [ Upstream commit 8ed0579c12b2fe56a1fac2f712f58fc26c1dc49b ]
> > 
> > debugfs can now report an error code if something went wrong instead of
> > just NULL.  So if the return value is to be used as a "real" dentry, it
> > needs to be checked if it is an error before dereferencing it.
> > 
> > This is now happening because of ff9fb72bc077 ("debugfs: return error
> > values, not NULL").  syzbot has found a way to trigger multiple debugfs
> > files attempting to be created, which fails, and then the error code
> > gets passed to dentry_path_raw() which obviously does not like it.
> 
> 4.19-stable does not contain patch ff9fb72bc077, so is this still good
> idea? It should not break anything, as it still uses IS_ERR_OR_NULL,
> but...

Yes it should as just testing for NULL was incorrect in the first place.

thanks,

greg k-h