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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 2 Mar 2023 01:23:44 +0530
From:   Deepak R Varma <drv@...lo.com>
To:     James Bottomley <jejb@...ux.ibm.com>
Cc:     Hannes Reinecke <hare@...e.de>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        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 Wed, Mar 01, 2023 at 02:28:49PM -0500, James Bottomley wrote:
> 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.

Thank you very much James for the review comments. I truly appreciate your time
and guidance. I will study your feedback and send in a revision with necessary
update to patch log.

Regards,
./drv

> 
> James
>