netdev - Re: [bug] dpaa2-eth: "Wrong SWA type" and null deref in dpaa2_eth_free_tx

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: <20231013155203.kib4nowqvhtcv5ak@LXL00007.wbi.nxp.com>
Date: Fri, 13 Oct 2023 18:52:03 +0300
From: Ioana Ciornei <ioana.ciornei@....com>
To: Daniel Klauer <daniel.klauer@....de>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [bug] dpaa2-eth: "Wrong SWA type" and null deref in
 dpaa2_eth_free_tx_fd()

On Fri, Oct 06, 2023 at 04:03:19PM +0200, Daniel Klauer wrote:
> On 04.10.23 17:50, Ioana Ciornei wrote:
> > On Wed, Aug 30, 2023 at 07:10:05PM +0200, Daniel Klauer wrote:
> >> Hi,
> >>
> 
(...)

> > 
> >> It's 100% reproducible here, however it seems to depend on the data
> >> rate/load: Once it happened after receiving the first 80 frames,
> >> another time after the first 300 frames, etc., and if I only send 5
> >> frames per second, it does not happen at all.
> >>
> >> Please let me know if I should provide more info or do more tests. I
> >> can provide a test program if needed.
> >>
> > 
> > If you can provide a test program, that would be great. It would help in
> > reproducing and debugging the issue on my side.
> 
> OK, I've attached a test program, send_and_recv.c, reduced as far as I could get it. If I run it:
> 
> ip link set up dev eth6
> ip link set mtu 9000 dev eth6
> ./send_and_recv eth6
> 

Thanks for the test program! I was able to reproduce the issue fairly easily.

I still do not know the root cause but it seems to always happen with
frames which are not 64 bytes aligned. I am afraid that the memory is
somehow corrupted between Tx and Tx conf.

The driver already has a PTR_ALIGN call in dpaa2_eth_build_single_fd()
but if there is not enough space in the skb's headroom then it will just
go ahead without it.

Attached you will find 2 patches which make the 64 bytes alignment a
must. With these patches applied onto net-next I do not see the issue
anymore.

Could you please also test on your side?

In the meantime, I will search internally for some more information on
the Tx alignment restrictions in DPAA2 and whether or not they are only
"nice to have" as the comment below suggests.

	/* If there's enough room to align the FD address, do it.
	 * It will help hardware optimize accesses.
	 */

Ioana

View attachment "0001-dpaa2-eth-increase-the-needed-headroom-to-account-fo.patch" of type "text/x-diff" (1811 bytes)

View attachment "0002-dpaa2-eth-set-needed_headroom-to-the-maximum-value-n.patch" of type "text/x-diff" (1233 bytes)