On Sat, 5 Oct 2024 at 15:01, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> I wouldn't bet on that. You *can* get over 2G references on 64bit box
> with arseloads of memory, and we have no way to make fget() et.al.
> fail when refcount gets that high - no valid error to return and
> a serious DoS potential if we start doing that.
Why do you think we can't make fget() fail?
That's what we did for the page count, and it worked just fine. Two
billion file references is not a valid thing - it's an attack.
We don't have to fix every file ref increment - the same way we didn't
fix all the get_page() cases. We only need to fix the ones that are
directly triggerable from user accesses (ie temporary kernel refs are
fine).
And the main case that is user-accessible is exactly the fget()
variatiosn that result in get_file_rcu(). It's perfectly fine to say
"nope, I'm not getting you this file, you're clearly a bad person".
There are probably other cases that just do "get_file()" on an
existing 'struct file *" directly, but it's usually fairly hard to get
users to refer to file pointers without giving an actual file
descriptor number. But things like "split a vma" will do it (on the
file that is mapped), and probably a few other cases, but I bet it
really is just a few cases.
That said, the simple "atomic_inc_return()" suggestion of mine was
broken for other reasons anyway.
So I do think it needs some of the rcuref code complexity with the
rcuref_put_slowpath() turning the last ref into RCUREF_DEAD).
Linus
