Re: system panic while dentry reference count overflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 6, 2019 at 5:40 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Linus, lockref is your code, IIRC; which variant would you consider
> more feasible?

I think we should strive for the same kind of count overflow handling
that the pageref patches did: keep the count at 32 bits, but just add
a new "try_dget()" thing that returns "no" when the count grows too
large.

And then use the "try_dget()" model when possible, and particularly
for the easy cases for user mode to trigger. You don't have to catch
them all, and in most places it isn't worth even worrying about it
because users can't force billions of those places to be active at
once.

I don't see the original email (I'm not on fsdevel, and google doesn't
find it), so I don't see if there was some particular case that was
pointed out as being an easy attack vector.

For the page ref counts, it was all about get_user_pages() and a
couple of other places, and the patches ended up being small and
localized:

  15fab63e1e57 fs: prevent page refcount overflow in pipe_buf_get
  8fde12ca79af mm: prevent get_user_pages() from overflowing page refcount
  88b1a17dfc3e mm: add 'try_get_page()' helper function
  f958d7b528b1 mm: make page ref count overflow check tighter and more explicit

and I think we should see this kind of thing as the primary model,
rather than do the whole "let's make everything 64-bit".

                 Linus



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux