linux-kernel - Re: [PATCH RESEND] scsi: libfc: Use refcount

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]

Date:   Wed, 01 Mar 2023 14:28:49 -0500
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Deepak R Varma <drv@...lo.com>, Hannes Reinecke <hare@...e.de>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Saurabh Singh Sengar <ssengar@...rosoft.com>,
        Praveen Kumar <kumarpraveen@...ux.microsoft.com>
Subject: Re: [PATCH RESEND] scsi: libfc: Use refcount_* APIs for reference
 count management

On Thu, 2023-03-02 at 00:32 +0530, Deepak R Varma wrote:
> The atomic_t API based object reference counter management is prone
> to counter value overflows, object use-after-free issues and to
> return puzzling values. The improved refcount_t APIs are designed to
> address these known issues with atomic_t reference counter
> management. This white paper [1] has detailed reasons for moving from
> atomic_t to refcount_t APIs. Hence replace the atomic_* based
> implementation by its refcount_* based equivalent.
> The issue is identified using atomic_as_refcounter.cocci Coccinelle
> semantic patch script.
> 
>         [1] https://arxiv.org/pdf/1710.06175.pdf

Citing long whitepapers in support of a patch isn't helpful to time
pressed reviewers, particularly when it's evident you didn't understand
the paper you cite. The argument in the paper for replacing atomics
with refcounts can be summarized as: if a user can cause a counter
overflow in an atomic_t simply by performing some action from userspace
then that represents a source of potential overflow attacks on the
kernel which should be mitigated by replacing the atomic_t in question
with a refcount_t which is overflow resistant.

What's missing from the quoted changelog is a justification of how a
user could cause an overflow in the ex_refcnt atomic_t.

James