netdev - Re: [net PATCH v2] octeontx2-af: Move validation of ptp pointer before its usage

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: 
 <SA1PR18MB4709E390AC13A1EF5F652165A02AA@SA1PR18MB4709.namprd18.prod.outlook.com>
Date: Fri, 30 Jun 2023 05:19:27 +0000
From: Sai Krishna Gajula <saikrishnag@...vell.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
CC: "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com"
	<edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        "maciej.fijalkowski@...el.com" <maciej.fijalkowski@...el.com>,
        Naveen
 Mamindlapalli <naveenm@...vell.com>
Subject: Re: [net PATCH v2] octeontx2-af: Move validation of ptp pointer
 before its usage


> -----Original Message-----
> From: Dan Carpenter <dan.carpenter@...aro.org>
> Sent: Friday, June 23, 2023 5:14 PM
> To: Sai Krishna Gajula <saikrishnag@...vell.com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; Sunil Kovvuri Goutham <sgoutham@...vell.com>;
> maciej.fijalkowski@...el.com; Naveen Mamindlapalli
> <naveenm@...vell.com>
> Subject: Re: [net PATCH v2] octeontx2-af: Move validation of ptp
> pointer before its usage
> 
> On Fri, Jun 23, 2023 at 11:28:19AM +0000, Sai Krishna Gajula wrote:
> > > This probe function is super weird how it returns success on the failure
> path.
> > > One concern, I had initially was that if anything returns
> > > -EPROBE_DEFER then we cannot recover.  That's not possible in the
> > > current code, but it makes me itch...  But here is a different crash.
> > >
> >
> > In few circumstances, the PTP device is probed before the AF device in
> > the driver. In such instance, -EPROBE_DEFER is used.
> > -- EDEFER_PROBE is useful when probe order changes. Ex: AF driver probes
> before PTP.
> >
> 
> You're describing how -EPROBE_DEFER is *supposed* to work.  But that's not
> what this driver does.
> 
> If the AF driver is probed before the PTP driver then ptp_probe() should
> return -EPROBE_DEFER and that would allow the kernel to automatically retry
> ptp_probe() later.  But instead of that, ptp_probe() returns success.  So I
> guess the user would have to manually rmmod it and insmod it again?  So,
> what I'm saying I don't understand why we can't do this in the normal way.
> 
> The other thing I'm saying is that the weird return success on error stuff
> hasn't been tested or we would have discovered the crash through testing.
> 
> regards,
> dan carpenter

As suggested, we will return error in ptp_probe in case of any failure conditions. In this case AF driver continues without PTP support.
When the AF driver is probed before PTP driver , we will defer the AF probe. Hope these changes are inline with your view.
I will send a v3 patch with these changes. 

Regards,
Sai