linux-kernel - Re: [syzbot] KASAN: null-ptr-deref Read in filp

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: <YF/A0eZdQwi0/PJU@zeniv-ca.linux.org.uk>
Date:   Sat, 27 Mar 2021 23:33:37 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot <syzbot+283ce5a46486d6acdbaf@...kaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot] KASAN: null-ptr-deref Read in filp_close (2)

On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote:
> @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
>  static inline void __range_cloexec(struct files_struct *cur_fds,
>  				   unsigned int fd, unsigned int max_fd)
>  {
> +	unsigned int cur_max;
>  	struct fdtable *fdt;
>  
>  	if (fd > max_fd)
> @@ -639,7 +640,12 @@ static inline void __range_cloexec(struct files_struct *cur_fds,
>  
>  	spin_lock(&cur_fds->file_lock);
>  	fdt = files_fdtable(cur_fds);
> -	bitmap_set(fdt->close_on_exec, fd, max_fd - fd + 1);
> +	/* make very sure we're using the correct maximum value */
> +	cur_max = fdt->max_fds;
> +	cur_max--;
> +	cur_max = min(max_fd, cur_max);
> +	if (fd <= cur_max)
> +		bitmap_set(fdt->close_on_exec, fd, cur_max - fd + 1);
>  	spin_unlock(&cur_fds->file_lock);
>  }

Umm...  That's harder to follow than it ought to be.  What's the point of
having
        max_fd = min(max_fd, cur_max);
done in the caller, anyway?  Note that in __range_close() you have to
compare with re-fetched ->max_fds (look at pick_file()), so...

BTW, I really wonder if the cost of jerking ->file_lock up and down
in that loop in __range_close() is negligible.  What values do we
typically get from callers and how sparse does descriptor table tend
to be for those?