Hi,
https://github.com/torvalds/linux/blob/master/drivers/base/swnode.c#L405
We notice that the return pointer of to_swnode is null check in some case, while in some case is not. For example, at line 416, the return pointer is null-check, but in line 405 is not. We want to know whether it would be a potential null pointer dereference problem, in the case that null-check is missing.
This problem is detected by our experimental static analysis tool, we are not familiar with the source code and it could just be a false positive. We send this email in case this is a real problem. Would you like to spare some time to have a look at it?
Thanks so much,
Chengfeng
On Mon, Oct 25, 2021 at 02:03:51PM +0000, YE Chengfeng wrote:
> Hi,
>
> https://github.com/torvalds/linux/blob/master/drivers/base/swnode.c#L405
>
> We notice that the return pointer of to_swnode is null check in some case, while in some case is not. For example, at line 416, the return pointer is null-check, but in line 405 is not. We want to know whether it would be a potential null pointer dereference problem, in the case that null-check is missing.
>
> This problem is detected by our experimental static analysis tool, we are not familiar with the source code and it could just be a false positive. We send this email in case this is a real problem. Would you like to spare some time to have a look at it?
Thank you for the interest to our code!
Line #405 refers to software node operations and it means it won't be ever
called if there is no swnode behind it, means it's backed with properties.
If you think it will be a NULL pointer there, please describe in detail
(with a traceback included) when and how it happens, because such bugs are
serious.
Line #416 refers to the same stage when options are defined and we know we
have been called against swnode. Seems to me like a dead code brought from
day 1 by the commit bc0500c1e43d ("device property: Add fwnode_get_name
for returning the name of a node").
Sakari?
--
With Best Regards,
Andy Shevchenko
Thanks for your reply in such detail!
You are right, seems this is a false positive report by our static analyzer.
Thanks so much,
Chengfeng
-----?ʼ?ԭ??-----
??????: [email protected] <[email protected]>
????ʱ??: 2021??10??26?? 0:41
?ռ???: YE Chengfeng <[email protected]>; Sakari Ailus <[email protected]>
????: [email protected]; [email protected]
????: Re: suspected null-pointer-reference problem for to_swnode
On Mon, Oct 25, 2021 at 02:03:51PM +0000, YE Chengfeng wrote:
> Hi,
>
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fbase%2Fswnode.c%
> 23L405&data=04%7C01%7Ccyeaa%40connect.ust.hk%7Cdc002f67705f4fb1af5
> 308d997d64616%7C6c1d415239d044ca88d9b8d6ddca0708%7C1%7C0%7C63770776882
> 1627362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Mh36sX%2FnHacvwDmSVAjlPs
> I6UWa%2Bb0RMIn%2FvvHtKcdc%3D&reserved=0
>
> We notice that the return pointer of to_swnode is null check in some case, while in some case is not. For example, at line 416, the return pointer is null-check, but in line 405 is not. We want to know whether it would be a potential null pointer dereference problem, in the case that null-check is missing.
>
> This problem is detected by our experimental static analysis tool, we are not familiar with the source code and it could just be a false positive. We send this email in case this is a real problem. Would you like to spare some time to have a look at it?
Thank you for the interest to our code!
Line #405 refers to software node operations and it means it won't be ever called if there is no swnode behind it, means it's backed with properties.
If you think it will be a NULL pointer there, please describe in detail (with a traceback included) when and how it happens, because such bugs are serious.
Line #416 refers to the same stage when options are defined and we know we have been called against swnode. Seems to me like a dead code brought from day 1 by the commit bc0500c1e43d ("device property: Add fwnode_get_name for returning the name of a node").
Sakari?
--
With Best Regards,
Andy Shevchenko
On Mon, Oct 25, 2021 at 07:40:55PM +0300, [email protected] wrote:
> On Mon, Oct 25, 2021 at 02:03:51PM +0000, YE Chengfeng wrote:
> > Hi,
> >
> > https://github.com/torvalds/linux/blob/master/drivers/base/swnode.c#L405
> >
> > We notice that the return pointer of to_swnode is null check in some case, while in some case is not. For example, at line 416, the return pointer is null-check, but in line 405 is not. We want to know whether it would be a potential null pointer dereference problem, in the case that null-check is missing.
> >
> > This problem is detected by our experimental static analysis tool, we are not familiar with the source code and it could just be a false positive. We send this email in case this is a real problem. Would you like to spare some time to have a look at it?
>
> Thank you for the interest to our code!
>
> Line #405 refers to software node operations and it means it won't be ever
> called if there is no swnode behind it, means it's backed with properties.
> If you think it will be a NULL pointer there, please describe in detail
> (with a traceback included) when and how it happens, because such bugs are
> serious.
>
> Line #416 refers to the same stage when options are defined and we know we
> have been called against swnode. Seems to me like a dead code brought from
> day 1 by the commit bc0500c1e43d ("device property: Add fwnode_get_name
> for returning the name of a node").
>
> Sakari?
Yeah, the check could be removed.
--
Sakari Ailus
On Tue, Oct 26, 2021 at 06:11:57PM +0300, Sakari Ailus wrote:
> On Mon, Oct 25, 2021 at 07:40:55PM +0300, [email protected] wrote:
> > On Mon, Oct 25, 2021 at 02:03:51PM +0000, YE Chengfeng wrote:
> > > Hi,
> > >
> > > https://github.com/torvalds/linux/blob/master/drivers/base/swnode.c#L405
> > >
> > > We notice that the return pointer of to_swnode is null check in some case, while in some case is not. For example, at line 416, the return pointer is null-check, but in line 405 is not. We want to know whether it would be a potential null pointer dereference problem, in the case that null-check is missing.
> > >
> > > This problem is detected by our experimental static analysis tool, we are not familiar with the source code and it could just be a false positive. We send this email in case this is a real problem. Would you like to spare some time to have a look at it?
> >
> > Thank you for the interest to our code!
> >
> > Line #405 refers to software node operations and it means it won't be ever
> > called if there is no swnode behind it, means it's backed with properties.
> > If you think it will be a NULL pointer there, please describe in detail
> > (with a traceback included) when and how it happens, because such bugs are
> > serious.
> >
> > Line #416 refers to the same stage when options are defined and we know we
> > have been called against swnode. Seems to me like a dead code brought from
> > day 1 by the commit bc0500c1e43d ("device property: Add fwnode_get_name
> > for returning the name of a node").
> >
> > Sakari?
>
> Yeah, the check could be removed.
I have just sent a patch.
--
With Best Regards,
Andy Shevchenko