linux-kernel - Re: [PATCH 1/2] fbdev: Check in file_fb_info() if the fb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fa010244-b250-ea6d-275e-bfbe1bd8f212@suse.de>
Date:   Mon, 2 May 2022 15:26:46 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     linux-fbdev@...r.kernel.org, Xiyu Yang <xiyuyang19@...an.edu.cn>,
        Helge Deller <deller@....de>,
        Changcheng Deng <deng.changcheng@....com.cn>,
        dri-devel@...ts.freedesktop.org, Maxime Ripard <maxime@...no.tech>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        Alex Deucher <alexander.deucher@....com>,
        Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH 1/2] fbdev: Check in file_fb_info() if the fb_info was
 already been freed

Hi

Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
> If real driver probes, the fbdev core kicks out all drivers that are using
> a framebuffer that were provided by the system firmware. But it could be a
> user-space process still has a file descriptor for the fbdev device node.
> 
> This can lead to a NULL pointer dereference, if the framebuffer device is
> unregistered and associated data freed, but later in the .release callback
> is attempted to access its struct fb_info.
> 
> To prevent this, make file_fb_info() to also check the fb_info reference
> counter and just return NULL if this equals zero. Since that means it has
> already been freed.
> 
> Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
> ---
> 
>   drivers/video/fbdev/core/fbmem.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 84427470367b..20d8929df79f 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -751,8 +751,13 @@ static struct fb_info *file_fb_info(struct file *file)
>   	int fbidx = iminor(inode);
>   	struct fb_info *info = registered_fb[fbidx];
>   
> -	if (info != file->private_data)
> -		info = NULL;
> +	if (!info)
> +		return NULL;
> +
> +	/* check that the fb_info has not changed or was already freed */
> +	if (info != file->private_data || refcount_read(&info->count) == 0)
> +		return NULL;
> +

Acked-by: Thomas Zimmermann <tzimmermann@...e.de>

However, I'm having problems with the semantics of these variables: if 
we have an info from registered_fb[fbinx] and the refcount in 
info->count is still 0, isn't that a consistency problem? If so, we 
should print a WARN_ON().

Best regards
Thomas


>   	return info;
>   }
>   

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)