[kernel-hardening] Re: Conversion from atomic_t to refcount_t: summary of issues

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Dec 02, 2016 at 05:44:34PM +0200, Liljestrand Hans wrote:
> Then there's cases that check for the first increment, like here (maybe
> something like inc_and_one could allow these without too much leeway?):
> 
> http://lxr.free-electrons.com/source/drivers/tty/serial/zs.c#L764
> 
>  irq_guard = atomic_add_return(1, &scc->irq_guard);
>  	if (irq_guard == 1) {

That's horrid, let's fix it correctly, it just wants to know if the
driver has been initialized or not.  Make it a real lock and a variable
and all is good.

> http://lxr.free-electrons.com/source/drivers/usb/gadget/function/f_fs.c#L1497
> 
>  if (atomic_add_return(1, &ffs->opened) == 1 &&
>  	ffs->state == FFS_DEACTIVATED) {

Another horrid hack to try to be "cute" about only allowing one open to
succeed.  Again, let's do this correctly with a lock.

> And finally some cases with other uses/values:
> 
> http://lxr.free-electrons.com/source/kernel/bpf/syscall.c#L231
> 
>  if (atomic_inc_return(&map->refcnt) > BPF_MAX_REFCNT) {

A "don't allow any more than X things through at once" type counter, a
normal atomic type should be fine for this, it's not a "real" reference
counter for a data structure.

> http://lxr.free-electrons.com/source/drivers/staging/lustre/lustre/ptlrpc/client.c#L3081
> 
>  if (atomic_inc_return(&req->rq_refcount) == 2)

lustre should never be used as an excuse for anything, except for how to
not do things.  That's some messed up code that is slowly getting
better...

This audit is turning up good stuff, it will be nice to clean this crud
up!

thanks,

greg k-h