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: <64f7670f-b9b9-4d05-b6b7-630f0e5837fc@infradead.org>
Date: Fri, 16 Feb 2024 19:37:35 +0900
From: Geoff Levand <geoff@...radead.org>
To: Paolo Abeni <pabeni@...hat.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 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 2/13/24 22:09, Paolo Abeni wrote:
> 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

As I mentioned in an earlier mail, the SKB pointer is set to NULL
so we can detect if an SKB has been allocated.
 
> 
> 	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.

The proposed change was tested by both Sambat and I.  It fixes the
problem, and no ill effects were seen.

-Geoff