| 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
| ||
|
Message-ID: <8cba66d2-9608-4a5c-a2af-6cc91f46a49f@kernel.org> Date: Fri, 24 Oct 2025 15:13:39 +0200 From: Danilo Krummrich <dakr@...nel.org> To: Tvrtko Ursulin <tvrtko.ursulin@...lia.com> Cc: phasta@...nel.org, Sumit Semwal <sumit.semwal@...aro.org>, Gustavo Padovan <gustavo@...ovan.org>, Christian König <christian.koenig@....com>, linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] dma-fence: Correct return of dma_fence_driver_name() On 10/24/25 2:40 PM, Tvrtko Ursulin wrote: > You trim too much of the quote making it unclear if you read the whole story. I'm well aware of the context. > If the driver isn't detached from the signalled fence then it is vulnerable to > use after free. When someone just reads "detached-driver" is creates the impression that the driver is unbound from its device, since this is what this term is usually used for. (And this is even the case you want to protect against, i.e. the string behind the pointer returned by get_driver_name() has been freed.) However, the condition that has changed when you print "driver-detached" is that the fence has been signaled, independent of whether the driver has been detached from the device. Now, you can argue that you mean "driver has been detached from the fence", which means something along the lines of "the driver has no business with the fence anymore", but this is not what people think of when they read "detached-driver".
Powered by blists - more mailing lists