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: <20170728.123139.1354715651678675641.davem@davemloft.net>
Date:   Fri, 28 Jul 2017 12:31:39 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     salyzyn@...roid.com
Cc:     andrew@...n.ch, netdev@...r.kernel.org, stable@...r.kernel.org
Subject: Re: refcount_t + (resend to wider audience)

From: Mark Salyzyn <salyzyn@...roid.com>
Date: Fri, 28 Jul 2017 11:07:53 -0700

> On 07/28/2017 10:41 AM, Andrew Lunn wrote:
>> On Fri, Jul 28, 2017 at 10:15:23AM -0700, Mark Salyzyn wrote:
>>> (Resend to wider audience to comply with
>>> Documentation/networking/netdev-FAQ.txt)
>>>
>>> Please apply/backport the following upstream feature and followup
>>> grouped fixes patches to the stable trees (expect included in at least
>>> 3.10.y, 3.18.y, 4.4.y and 4.9.y):
>> .. _stable_kernel_rules:
>>
>> Hi Mark
>>
>> Everything you ever wanted to know about Linux -stable releases
>> ===============================================================
>>
>> Rules on what kind of patches are accepted, and which ones are not,
>> into the
>> "-stable" tree:
>>
>>   - It must be obviously correct and tested.
>>   - It cannot be bigger than 100 lines, with context.
>>
>> The first patch you list is 342 lines. The second one is 634.
>>
>> Please could you read the rules and then provide some justification
>> for ignoring many of the rules.
>>
>>      Andrew
> 
> The first four patches add a new dependent upstream API and type,
> refcount_t. New APIs will notoriously cause a large number of lines to
> be adjusted. They are complete (ToT will/should match stable),
> orthogonal, and without CONFIG_REFCOUNT_FULL completely inert in all
> places where atomic_t reference counters used, and are replaced with
> refcount_t in the followup patches that take advantage of this new
> type.
> 
> The first four do _nothing_ at all to the kernel as-is, but represent
> a dependency for the following changes.
> 
> The remaining patches (for the most part) take advantage of this new
> API to mostly fix, or report/warn when they can not, Use-After-Free
> (KASAN) bugs which can lead to root attack exploits. atomic_t are
> subject to unbounded attacks, refcount_t are relatively immune to
> unbounded attacks. It is admittedly not a complete fix, but greatly
> reduce the chances of the security issues. The recommendation is to
> turn on CONFIG_REFCOUNT_FULL, but that is a decision to balance
> between security and performance.
> 
> For any platform that requires the latest security updates, refcount_t
> is going to be a requirement. I urge you to overlook the first four
> patch sizes because of their status as an orthogonal type and API,
> necessary dependency for security improvements.

Sorry, even with this explanation this -stable require is completely
and totally inappropriate.

You guys are really pushing things way too far with this refcount_t
stuff, seriously.

NACK.