On Mon, 2017-02-20 at 17:56 +0100, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 07:41:01AM -0800, James Bottomley wrote: > > On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: > > > On 02/20/2017 04:16 AM, Elena Reshetova wrote: > > > > Now when new refcount_t type and API are finally merged > > > > (see include/linux/refcount.h), the following > > > > patches convert various refcounters in the block susystem from > > > > atomic_t to refcount_t. By doing this we prevent intentional or > > > > accidental underflows or overflows that can led to use-after > > > > -free vulnerabilities. > > > > This description isn't right ... nothing is prevented; we get > > warnings on saturation and use after free with this. > > The thing that is prevented is overflow and then a use-after-free by > making it a leak. > > Modular stuff, you put and free at: (n+1) mod n, by saturating at n-1 > we'll never get there. > > So you loose use-after-free, you gain a resource leak. The general > idea being that use-after-free is a nice trampoline for exploits, > leaks are 'only' a DoS. OK, I see the intention: it's protection from outside influence. It still doesn't prevent *us* from screwing up in the kernel and inducing a use after free by doing too many puts (or too few gets) ... that's what the message suggests to me (me coding wrongly is accidental underflows or overflows as I read it). James
