Message ID | 20210403151312.31796-1-paskripkin@gmail.com (mailing list archive) |
---|---|
State | Rejected |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | net: netlink: fix error check in genl_family_rcv_msg_doit | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Guessed tree name to be net-next |
netdev/subject_prefix | warning | Target tree name not specified in the subject |
netdev/cc_maintainers | warning | 3 maintainers not CCed: stranche@codeaurora.org fw@strlen.de xiyou.wangcong@gmail.com |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 1 this patch: 1 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 1 this patch: 1 |
netdev/header_inline | success | Link |
On Sat, 2021-04-03 at 15:13 +0000, Pavel Skripkin wrote: > genl_family_rcv_msg_attrs_parse() can return NULL > pointer: > > if (!ops->maxattr) > return NULL; > > But this condition doesn't cause an error in > genl_family_rcv_msg_doit And I'm almost certain that in fact it shouldn't cause an error! If the family doesn't set maxattr then it doesn't want to have generic netlink doing the parsing, but still it should be possible to call the ops. Look at fs/dlm/netlink.c for example, it doesn't even have attributes. You're breaking it with this patch. Also, the (NULL) pointer is not actually _used_ anywhere, so why would it matter? johannes
Hi! On Sat, 2021-04-03 at 18:26 +0200, Johannes Berg wrote: > On Sat, 2021-04-03 at 15:13 +0000, Pavel Skripkin wrote: > > genl_family_rcv_msg_attrs_parse() can return NULL > > pointer: > > > > if (!ops->maxattr) > > return NULL; > > > > But this condition doesn't cause an error in > > genl_family_rcv_msg_doit > > And I'm almost certain that in fact it shouldn't cause an error! > > If the family doesn't set maxattr then it doesn't want to have > generic > netlink doing the parsing, but still it should be possible to call > the > ops. Look at fs/dlm/netlink.c for example, it doesn't even have > attributes. You're breaking it with this patch. > > Also, the (NULL) pointer is not actually _used_ anywhere, so why > would > it matter? > Oh, I see now. I thought, it could cause a NULL ptr deference in some cases, because some ->doit() functions accessing info.attrs directly. Now I understand the point, sorry for my misunderstanding the situation. > johannes > With regards, Pavel Skripkin
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 2d6fdf40df66..c06d06ead181 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -719,6 +719,8 @@ static int genl_family_rcv_msg_doit(const struct genl_family *family, GENL_DONT_VALIDATE_STRICT); if (IS_ERR(attrbuf)) return PTR_ERR(attrbuf); + if (!attrbuf) + return -EINVAL; info.snd_seq = nlh->nlmsg_seq; info.snd_portid = NETLINK_CB(skb).portid;
genl_family_rcv_msg_attrs_parse() can return NULL pointer: if (!ops->maxattr) return NULL; But this condition doesn't cause an error in genl_family_rcv_msg_doit Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> --- net/netlink/genetlink.c | 2 ++ 1 file changed, 2 insertions(+)