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

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

Date:   Thu, 6 May 2021 17:43:14 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Atul Gopinathan <atulgopinathan@...il.com>
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

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.

Cheers,
Peter