netdev - Re: [PATCH net 3/5] ibmvnic: Handle DMA unmapping of login buffs in release functions

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]

Date: Sat, 5 Aug 2023 09:19:56 +0200
From: Simon Horman <horms@...nel.org>
To: Nick Child <nnac123@...ux.ibm.com>
Cc: netdev@...r.kernel.org, haren@...ux.ibm.com, ricklind@...ibm.com,
	danymadden@...ibm.com, tlfalcon@...ux.ibm.com,
	bjking1@...ux.ibm.com
Subject: Re: [PATCH net 3/5] ibmvnic: Handle DMA unmapping of login buffs in
 release functions

On Thu, Aug 03, 2023 at 03:20:08PM -0500, Nick Child wrote:
> Rather than leaving the DMA unmapping of the login buffers to the
> login response handler, move this work into the login release functions.
> Previously, these functions were only used for freeing the allocated
> buffers. This could lead to issues if there are more than one
> outstanding login buffer requests, which is possible if a login request
> times out.
> 
> If a login request times out, then there is another call to send login.
> The send login function makes a call to the login buffer release
> function. In the past, this freed the buffers but did not DMA unmap.
> Therefore, the VIOS could still write to the old login (now freed)
> buffer. It is for this reason that it is a good idea to leave the DMA
> unmap call to the login buffers release function.
> 
> Since the login buffer release functions now handle DMA unmapping,
> remove the duplicate DMA unmapping in handle_login_rsp().
> 
> Fixes: dff515a3e71d ("ibmvnic: Harden device login requests")
> Signed-off-by: Nick Child <nnac123@...ux.ibm.com>

Reviewed-by: Simon Horman <horms@...nel.org>