linux-kernel - Re: [PATCH] PCI/DOE: Fix destroy_work_on

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: <20230727075414.GA29643@wunner.de>
Date:   Thu, 27 Jul 2023 09:54:14 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Ira Weiny <ira.weiny@...el.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Davidlohr Bueso <dave@...olabs.net>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI/DOE: Fix destroy_work_on_stack() race

On Wed, Jul 26, 2023 at 11:29:42AM -0700, Ira Weiny wrote:
> The following debug object splat was observed in testing.
[...]
> This occurs because destroy_work_on_stack() was called after signaling
> the completion in the calling thread.  This creates a race between
> destroy_work_on_stack() and the task->work struct going of scope in the
> pci_doe().
> 
> Signal the work complete after destroying the work struct.  This is safe
> because signal_task_complete() is the final thing the work item does and
> the workqueue code is careful not to access the work struct after.
> 
> Fixes: abf04be0e707 ("PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y")
> Cc: Lukas Wunner <lukas@...ner.de>
> Signed-off-by: Ira Weiny <ira.weiny@...el.com>

Reviewed-by: Lukas Wunner <lukas@...ner.de>

Thanks for catching this.  The offending commit abf04be0e707 was applied
by Dan.  Not sure if that means he's going to apply this fix as well?
Would require an ack from Bjorn in that case.  Or Bjorn applies it.

Thanks,

Lukas