Re: [GIT PULL] ucount fix for v5.14-rc

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, Aug 7, 2021 at 2:11 AM Hillf Danton <hdanton@sina.com> wrote:
>
>
>         CPU0                    CPU1    CPU2
>         ----                    ----    ----
>         given count == 2
>                                         put uc
>                                 put uc
>         get uc
>         UAF

No.

The thread on CPU0 must have had a reference to the ucount.

So if CPU1 and CPU2 are doing a put at the same time (and they held a
ref to it too), then the starting count must have been at least 3.

In other words, the above would be a bug - and not because of the UAF,
but because somebody had screwed up their reference counts.

You might as well had said "given count = 2, do 99x put_ucounts() ->
UAF". True, but immaterial from the standpoint of "put_ucounts()"
correctness.

Get it? You can't do a "get_ucounts()" on something that you don't
already have a reference to (and similarly, you obviously cannot do a
"put_ucounts()" on something you don't hold a reference to).

You *can* do a "find_ucount()" to find a ucount that you don't yet
have a reference to, but that's why you have to hold the lock (and why
anybody who does that has to increment the reference to it after
finding it before they drop the lock).

           Linus