On Wed, Jan 3, 2018 at 9:55 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jan 04, 2018 at 05:50:12AM +0000, Al Viro wrote: >> On Wed, Jan 03, 2018 at 09:44:33PM -0800, Dan Williams wrote: >> > On Wed, Jan 3, 2018 at 8:44 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> > > On Thu, Jan 04, 2018 at 03:10:51AM +0000, Williams, Dan J wrote: >> > > >> > >> diff --git a/include/linux/fdtable.h b/include/linux/fdtable.h >> > >> index 1c65817673db..dbc12007da51 100644 >> > >> --- a/include/linux/fdtable.h >> > >> +++ b/include/linux/fdtable.h >> > >> @@ -82,8 +82,10 @@ static inline struct file *__fcheck_files(struct files_struct *files, unsigned i >> > >> { >> > >> struct fdtable *fdt = rcu_dereference_raw(files->fdt); >> > >> >> > >> - if (fd < fdt->max_fds) >> > >> + if (fd < fdt->max_fds) { >> > >> + osb(); >> > >> return rcu_dereference_raw(fdt->fd[fd]); >> > >> + } >> > >> return NULL; >> > >> } >> > > >> > > ... and the point of that would be? Possibly revealing the value of files->fdt? >> > > Why would that be a threat, assuming you manage to extract the information in >> > > question in the first place? >> > >> > No, the concern is that an fd value >= fdt->max_fds may cause the cpu >> > to read arbitrary memory addresses relative to files->fdt and >> > userspace can observe that it got loaded. >> >> Yes. And all that might reveal is the value of files->fdt. Who cares? > > Sorry, s/files->fdt/files->fdt->fd/. Still the same question - what information > would that extract and how would attacker use that? The question is if userspace can ex-filtrate any data from the kernel that would otherwise be blocked by a bounds check should the kernel close that hole? For these patches I do not think the bar should be "can I prove an information leak is exploitable" it should be "can I prove that a leak is not exploitable", especially when possibly combined with other leak sites.