netdev - Re: [PATCH v4 net] ps3/gelic: Fix SKB allocation

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: <e29708440f07273fe93e3a1a7922428980f3e4a7.camel@redhat.com>
Date: Tue, 13 Feb 2024 14:09:30 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>, Geoff Levand
 <geoff@...radead.org>, sambat goson <sombat3960@...il.com>, "David S.
 Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 net] ps3/gelic: Fix SKB allocation

On Tue, 2024-02-13 at 12:56 +0000, Christophe Leroy wrote:
> 
> Le 13/02/2024 à 13:07, Paolo Abeni a écrit :
> > On Sat, 2024-02-10 at 17:15 +0900, Geoff Levand wrote:
> > > Commit 3ce4f9c3fbb3 ("net/ps3_gelic_net: Add gelic_descr structures") of
> > > 6.8-rc1 did not allocate a network SKB for the gelic_descr, resulting in a
> > > kernel panic when the SKB variable (struct gelic_descr.skb) was accessed.
> > > 
> > > This fix changes the way the napi buffer and corresponding SKB are
> > > allocated and managed.
> > 
> > I think this is not what Jakub asked on v3.
> > 
> > Isn't something alike the following enough to fix the NULL ptr deref?
> 
> If you think it is enough, please explain in more details.

I'm unsure it will be enough, but at least the quoted line causes a
NULL ptr dereference:

	descr->skb = netdev_alloc_skb(*card->netdev, rx_skb_size);
	if (!descr->skb) {
		descr->hw_regs.payload.dev_addr = 0; /* tell DMAC don't touch memory */
		return -ENOMEM;
	}
	// here descr->skb is not NULL...

	descr->hw_regs.dmac_cmd_status = 0;
	descr->hw_regs.result_size = 0;
	descr->hw_regs.valid_size = 0;
	descr->hw_regs.data_error = 0;
	descr->hw_regs.payload.dev_addr = 0;
	descr->hw_regs.payload.size = 0;
	descr->skb = NULL;
	// ... and now it's NULL for no apparent good reason

	offset = ((unsigned long)descr->skb->data) &
        //                            ^^^^^^^ NULL ptr deref

		(GELIC_NET_RXBUF_ALIGN - 1);
	if (offset)
		skb_reserve(descr->skb, GELIC_NET_RXBUF_ALIGN - offset);
	/* io-mmu-map the skb */
	cpu_addr = dma_map_single(ctodev(card), descr->skb->data,
				  GELIC_NET_MAX_FRAME, DMA_FROM_DEVICE);

The buggy line in introduced by the blamed commit.

>  From my point of view, when looking at commit 3ce4f9c3fbb3 
> ("net/ps3_gelic_net: Add gelic_descr structures") that introduced the 
> problem, it is not obvious.

That change is quite complex. It could includes other issues - quickly
skimming over it I could not see them.

Reporting the decoded stack trace generated by the NULL ptr deref could
help.

Cheers,

Paolo