[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170220165639.GE6515@twins.programming.kicks-ass.net>
Date: Mon, 20 Feb 2017 17:56:39 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Jens Axboe <axboe@...nel.dk>,
Elena Reshetova <elena.reshetova@...el.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-btrfs@...r.kernel.org,
gregkh@...uxfoundation.org, fujita.tomonori@....ntt.co.jp,
mingo@...hat.com, clm@...com, jbacik@...com, dsterba@...e.com
Subject: Re: [PATCH 0/5] block subsystem refcounter conversions
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.
Powered by blists - more mailing lists