linux-kernel - Re: [PATCH RFC 1/1] dmaengine: ptdma: use SLAB_TYPESAFE_BY

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] [day] [month] [year] [list]

Message-ID: <87ikn2lcww.fsf@AUSNATLYNCH.amd.com>
Date: Thu, 17 Apr 2025 16:02:23 -0500
From: Nathan Lynch <nathan.lynch@....com>
To: Eder Zulian <ezulian@...hat.com>, <Basavaraj.Natikar@....com>,
	<vkoul@...nel.org>, <dmaengine@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
CC: <jsnitsel@...hat.com>, <ddutile@...hat.com>, Eder Zulian
	<ezulian@...hat.com>
Subject: Re: [PATCH RFC 1/1] dmaengine: ptdma: use SLAB_TYPESAFE_BY_RCU for
 the DMA descriptor slab

Eder Zulian <ezulian@...hat.com> writes:
> The SLAB_TYPESAFE_BY_RCU flag prevents a change of type for objects
> allocated from the slab cache (although the memory may be reallocated to
> a completetly different object of the same type.) Moreover, when the
> last reference to an object is dropped the finalization code must not
> run until all __rcu pointers referencing the object have been updated,
> and then a grace period has passed.
>
> Signed-off-by: Eder Zulian <ezulian@...hat.com>
> ---
>  drivers/dma/amd/ptdma/ptdma-dmaengine.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/amd/ptdma/ptdma-dmaengine.c b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> index 715ac3ae067b..b70dd1b0b9fb 100644
> --- a/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> +++ b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> @@ -597,7 +597,8 @@ int pt_dmaengine_register(struct pt_device *pt)
>  
>  	pt->dma_desc_cache = kmem_cache_create(desc_cache_name,
>  					       sizeof(struct pt_dma_desc), 0,
> -					       SLAB_HWCACHE_ALIGN, NULL);
> +					       SLAB_HWCACHE_ALIGN |
> +					       SLAB_TYPESAFE_BY_RCU, NULL);

No, this code wasn't written to exploit SLAB_TYPESAFE_BY_RCU and this
change can only obscure the problem. There's likely a data race in the
driver.

I suspect pt_cmd_callback_work() has a bug:

        spin_lock_irqsave(&chan->vc.lock, flags);
        if (desc) {
                if (desc->status != DMA_COMPLETE) {
                        if (desc->status != DMA_ERROR)
                                desc->status = DMA_COMPLETE;

                        dma_cookie_complete(tx_desc);
                        dma_descriptor_unmap(tx_desc);
                } else {
                        tx_desc = NULL;
                }
        }
        spin_unlock_irqrestore(&chan->vc.lock, flags);

        if (tx_desc) {
                dmaengine_desc_get_callback_invoke(tx_desc, NULL);
                dma_run_dependencies(tx_desc);
>>>>            list_del(&desc->vd.node); <<< must be done under vc.lock
                vchan_vdesc_fini(vd);
        }

But that's relatively new code that may not be in the kernel you're
running.