lkml.org 
[lkml]   [2021]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?

\
 
 \ /
  Last update: 2021-03-28 00:36    [W:0.085 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site