Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 6 Feb 2021 20:43:25 +0100
From:   Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Kalle Valo <kvalo@codeaurora.org>,
        Lorenzo Bianconi <lorenzo@kernel.org>, netdev@vger.kernel.org,
        linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>
Subject: Re: pull-request: wireless-drivers-2021-02-05
Message-ID: <20210206194325.GA134674@lore-desk>
References: <20210205163434.14D94C433ED@smtp.codeaurora.org>
 <20210206093537.0bfaf0db@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <20210206093537.0bfaf0db@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Precedence: bulk


--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> On Fri,  5 Feb 2021 16:34:34 +0000 (UTC) Kalle Valo wrote:
> > Hi,
> >=20
> > here's a pull request to net tree, more info below. Please let me know =
if there
> > are any problems.
>=20
> Pulled, thanks! One thing to confirm tho..
>=20
> > ath9k
> >=20
> > * fix build regression related to LEDS_CLASS
> >=20
> > mt76
> >=20
> > * fix a memory leak
>=20
> Lorenzo, I'm just guessing what this code does, but you're dropping a
> frag without invalidating the rest of the SKB, which I presume is now
> truncated? Shouldn't the skb be dropped?
>=20

Hi Jakub,

I agree. We can do something like:

diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireles=
s/mediatek/mt76/dma.c
index e81dfaf99bcb..6d84533d1df2 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -511,8 +511,9 @@ mt76_add_fragment(struct mt76_dev *dev, struct mt76_que=
ue *q, void *data,
 {
 	struct sk_buff *skb =3D q->rx_head;
 	struct skb_shared_info *shinfo =3D skb_shinfo(skb);
+	int nr_frags =3D shinfo->nr_frags;
=20
-	if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) {
+	if (nr_frags < ARRAY_SIZE(shinfo->frags)) {
 		struct page *page =3D virt_to_head_page(data);
 		int offset =3D data - page_address(page) + q->buf_offset;
=20
@@ -526,7 +527,10 @@ mt76_add_fragment(struct mt76_dev *dev, struct mt76_qu=
eue *q, void *data,
 		return;
=20
 	q->rx_head =3D NULL;
-	dev->drv->rx_skb(dev, q - dev->q_rx, skb);
+	if (nr_frags < ARRAY_SIZE(shinfo->frags))
+		dev->drv->rx_skb(dev, q - dev->q_rx, skb);
+	else
+		dev_kfree_skb(skb);
 }
=20

I do not know if it can occur, but I guess we should even check q->rx_head
pointer before overwriting it because if the hw does not report more set to
false for last fragment we will get a memory leak as well. Something like:

@@ -578,6 +582,8 @@ mt76_dma_rx_process(struct mt76_dev *dev, struct mt76_q=
ueue *q, int budget)
 		done++;
=20
 		if (more) {
+			if (q->rx_head)
+				dev_kfree_skb(q->rx_head);
 			q->rx_head =3D skb;
 			continue;
 		}

Regards,
Lorenzo

--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCYB7xWgAKCRA6cBh0uS2t
rBgHAQD5KAy3ewQb/cLDCR//RPheoid10w9MryaxjwAU/2NtngD/beZzbnFs8u+T
ZiVHgyo0+/0HmdWvk9sHoE0Fbs17Iwc=
=/ou8
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--