linux-kernel - Re: [PATCH] s390/cio: Fix a memleak in css_alloc

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: <20230922152035.3ef1cb7e.pasic@linux.ibm.com>
Date:   Fri, 22 Sep 2023 15:20:35 +0200
From:   Halil Pasic <pasic@...ux.ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     Dinghao Liu <dinghao.liu@....edu.cn>,
        Vineeth Vijayan <vneethv@...ux.ibm.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Julian Wiedmann <jwi@...ux.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        Halil Pasic <pasic@...ux.ibm.com>
Subject: Re: [PATCH] s390/cio: Fix a memleak in css_alloc_subchannel

On Fri, 22 Sep 2023 14:25:58 +0200
Cornelia Huck <cohuck@...hat.com> wrote:

> > -       spin_lock_init(&sch->lock);
> > +       sch->schid = schid;
> > +       if (cio_is_console(schid)) {
> > +               sch->lock = cio_get_console_lock();
> > +       } else {
> > +               err = cio_create_sch_lock(sch);
> > +               if (err)
> > +                       goto out;
> > +       }
> >
> > I did not spend a huge amount of time looking at this but this
> > is the only reason I found for sch->lock being made a pointer. There may
> > be others, I'm just saying that is all I've found.  
> 
> Author of 2ec2298412e1 here. If I don't completely misremember things,
> this was for the orphanage stuff (i.e. ccw devices that were still kept
> as disconnected, like dasd still in use, that had to be moved from their
> old subchannel object because a different device appeared on that
> subchannel.) That orphanage used a single dummy subchannel for all ccw
> devices moved there.
> 
> I have no idea how the current common I/O layer works, but that might
> give you a hint about what to look for :)

Yes, that is what the commit states and what the series is about. I hope
Vineeth can give us some answers :) maybe even out of the top of his
head... If not, I would trust his judgment on whether figuring things
out is worthwhile or not.


Regards,
Halil