linux-kernel - Re: [PATCH 27/69] cdrom: gdrom: deallocate struct gdrom_unit fields in remove

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: <20210506164008.GA6283@atulu-nitro>
Date:   Thu, 6 May 2021 22:10:08 +0530
From:   Atul Gopinathan <atulgopinathan@...il.com>
To:     Peter Rosin <peda@...ntia.se>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH 27/69] cdrom: gdrom: deallocate struct gdrom_unit fields
 in remove_gdrom

On Thu, May 06, 2021 at 05:43:14PM +0200, Peter Rosin wrote:
> Hi!
> 
> On 2021-05-06 16:32, Atul Gopinathan wrote:
> > 
> > Apart from this, I don't see gdrom_get_last_session() being called
> > anywhere. But I could be missing something obvious too. 
> > 
> > If you don't mind, could you point out where gd.toc is being used in
> > probe_gdrom() before it is kzalloc-ed in the same function.
> 
> You are very probably correct in your analysis, and I can't find it in me
> to spend the time to dig any further.
> 
> I simply thought it bad enough to hand off a pointer to a function that
> uses a stale pointer to some other driver. I never dug into that other
> module like you did. Relying on that other piece of code to not use the
> function that was just handed to it is way too subtle (for me at least).
> When you "register" with something else, you should be ready to get the
> calls.
> 
> This is true especially in the context of what we are fixing up here;
> broken shit related to people that are fond of weaknesses later to be
> activated by other innocuous commits.

Ah, I see, that makes sense. I just wanted to confirm if I was getting
things right. Thanks for clarifying!

Regards,
Atul