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] [day] [month] [year] [list]
Date:   Sun, 9 Oct 2022 19:21:27 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Abd-Alrhman Masalkhi <abd.masalkhi@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: A field in files_struct has been used without initialization

On Fri, Oct 07, 2022 at 08:16:11PM +0100, Al Viro wrote:

> array of pointers (from first kvmalloc() in alloc_fdtable()): contains file pointers
> array of unsigned long (from the second kmvalloc() there): hosts the bitmaps
> fdtable (allocated in alloc_fdtable()):
> 	open_fds		points to the beginning of bitmap-hosting array
> 	close_on_exec		points to the middle third of the same array
> 	full_fd_bits		points to the last third of the same array

Rereading that... a bit of clarification: the wording would seem to imply
that these 3 bitmaps are of equal size; they are not - the third one is
smaller.

If fdt->max_fds (table capacity) is equal to N, we have
	* N struct file pointers in fdt->fd[]
	* N bits in fdt->open_fds[] (i.e. N/BITS_PER_LONG unsigned long)
	* N bits in fdt->close_on_exec[] (ditto)
	* N/BITS_PER_LONG bits in fdt->full_fd_bits[]

The meaning of bitmaps:
	bit k set in open_fds[] - descriptor k is in use
	bit k set in close_on_exec[] - descriptor k is to be closed on exec()
	bit k set in full_fd_bits[] - all descriptors covered by open_fds[k]
(i.e. BITS_PER_LONG of them,, starting from k * BITS_PER_LONG) are in use.
In other words, "don't even bother looking for clear bits in open_fds[k];
there won't be any".

->full_fd_bits[] is there purely as a way to speed finding unused descriptors,
along with ->next_fd.  Some processes have an obscene amount of opened
descriptors and linear search through the mostly full bitmap can get painful.
E.g. 4 millions of descriptors would mean half megabyte worth of bitmap
(in ->open_fds[]).  Cheaper to search through 8Kb of ->full_fd_bits, then
check one 64bit word in ->open_fds[]; kinder on the cache as well...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ