linux-kernel - RE: [PATCH 2/3] dmaengine: idxd: Prevent use after free on completion memory

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: <IA1PR11MB60973AA139D6BE79958675ED9B179@IA1PR11MB6097.namprd11.prod.outlook.com>
Date:   Fri, 2 Dec 2022 19:45:14 +0000
From:   "Yu, Fenghua" <fenghua.yu@...el.com>
To:     "Chatre, Reinette" <reinette.chatre@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/3] dmaengine: idxd: Prevent use after free on completion
 memory

> On driver unload any pending descriptors are flushed at the time the interrupt is
> freed:
> idxd_dmaengine_drv_remove() ->
> 	drv_disable_wq() ->
> 		idxd_wq_free_irq() ->
> 			idxd_flush_pending_descs().
> 
> If there are any descriptors present that need to be flushed this flow triggers a
> "not present" page fault as below:
> 
>  BUG: unable to handle page fault for address: ff391c97c70c9040
>  #PF: supervisor read access in kernel mode
>  #PF: error_code(0x0000) - not-present page
> 
> The address that triggers the fault is the address of the descriptor that was freed
> moments earlier via:
> drv_disable_wq()->idxd_wq_free_resources()
> 
> Fix the use after free by freeing the descriptors after any possible usage. This is
...
> Fixes: 63c14ae6c161 ("dmaengine: idxd: refactor wq driver enable/disable
> operations")
> Suggested-by: Dave Jiang <dave.jiang@...el.com>
> Signed-off-by: Reinette Chatre <reinette.chatre@...el.com>

Reviewed-by: Fenghua Yu <fenghua.yu@...el.com>