netdev - Re: refcount_t + (resend to wider audience)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0eba17bc-218e-c45c-5a49-9313126cd018@android.com>
Date:   Fri, 28 Jul 2017 12:59:47 -0700
From:   Mark Salyzyn <salyzyn@...roid.com>
To:     David Miller <davem@...emloft.net>
Cc:     andrew@...n.ch, netdev@...r.kernel.org, stable@...r.kernel.org
Subject: Re: refcount_t + (resend to wider audience)

On 07/28/2017 12:31 PM, David Miller wrote:
> Sorry, even with this explanation this -stable require is completely
> and totally inappropriate.
Puts me between a rock and a hard place trying to address kernel 
security issues. Should I instead file KASAN Use-After-Free reports on 
stable kernels here for analysis by those with more wisdom to help 
refine a more targeted fix?

For instance a dive on one of them did turn up 
89e357d83c06b6fac581c3ca7f0ee3ae7e67109e which stopped an unbounded 
refcounter by preventing multiple dump requests at the same time. But 
the other 4 KASAN reports I focused on this week, we were not so lucky.
> You guys are really pushing things way too far with this refcount_t
> stuff, seriously.
First round ever on this, I guess I am missing some turmoil, history or 
bad blood over refcount_t. Always fun to step on a landmine :-)
> NACK.

Please, guidance on where I can go from here.

Sincerely -- Mark Salyzyn