wireguard-linux/net/netlink/genetlink.c, branch jd/unified-crypt-queue

net: genetlink: return the error code when attribute parsing fails.

2020-02-23T05:58:33Z

Currently if attribute parsing fails and the genl family does not support parallel operation, the error code returned by __nlmsg_parse() is discarded by genl_family_rcv_msg_attrs_parse(). Be sure to report the error for all genl families. Fixes: c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function") Fixes: ab5b526da048 ("net: genetlink: always allocate separate attrs for dumpit ops") Signed-off-by: Paolo Abeni Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller

genetlink: do not parse attributes for families with zero maxattr

2019-10-13T18:20:03Z

Commit c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function") moved attribute buffer allocation and attribute parsing from genl_family_rcv_msg_doit() into a separate function genl_family_rcv_msg_attrs_parse() which, unlike the previous code, calls __nlmsg_parse() even if family->maxattr is 0 (i.e. the family does its own parsing). The parser error is ignored and does not propagate out of genl_family_rcv_msg_attrs_parse() but an error message ("Unknown attribute type") is set in extack and if further processing generates no error or warning, it stays there and is interpreted as a warning by userspace. Dumpit requests are not affected as genl_family_rcv_msg_dumpit() bypasses the call of genl_family_rcv_msg_attrs_parse() if family->maxattr is zero. Move this logic inside genl_family_rcv_msg_attrs_parse() so that we don't have to handle it in each caller. v3: put the check inside genl_family_rcv_msg_attrs_parse() v2: adjust also argument of genl_family_rcv_msg_attrs_free() Fixes: c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function") Signed-off-by: Michal Kubecek Acked-by: Jiri Pirko Acked-by: Jakub Kicinski Signed-off-by: David S. Miller

net: genetlink: always allocate separate attrs for dumpit ops

2019-10-09T01:00:08Z

Individual dumpit ops (start, dumpit, done) are locked by genl_lock if !family->parallel_ops. However, multiple genl_family_rcv_msg_dumpit() calls may in in flight in parallel. Each has a separate struct genl_dumpit_info allocated but they share the same family->attrbuf. Fix this by allocating separate memory for attrs for dumpit ops, for non-parallel_ops (for parallel_ops it is done already). Reported-by: syzbot+495688b736534bb6c6ad@syzkaller.appspotmail.com Reported-by: syzbot+ff59dc711f2cff879a05@syzkaller.appspotmail.com Reported-by: syzbot+dbe02e13bcce52bcf182@syzkaller.appspotmail.com Reported-by: syzbot+9cb7edb2906ea1e83006@syzkaller.appspotmail.com Fixes: bf813b0afeae ("net: genetlink: parse attrs and store in contect info struct during dumpit") Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski

net: genetlink: remove unused genl_family_attrbuf()

2019-10-06T13:44:47Z

genl_family_attrbuf() function is no longer used by anyone, so remove it. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

net: genetlink: parse attrs and store in contect info struct during dumpit

2019-10-06T13:44:47Z

Extend the dumpit info struct for attrs. Instead of existing attribute validation do parse them and save in the info struct. Caller can benefit from this and does not have to do parse itself. In order to properly free attrs, genl_family pointer needs to be added to dumpit info struct as well. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

net: genetlink: push attrbuf allocation and parsing to a separate function

2019-10-06T13:44:46Z

To be re-usable by dumpit as well, push the code that is taking care of attrbuf allocation and parting from doit into separate function. Introduce a helper to free the buffer too. Check family->maxattr too before calling kfree() to be symmetrical with the allocation check. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

net: genetlink: introduce dump info struct to be available during dumpit op

2019-10-06T13:44:46Z

Currently the cb->data is taken by ops during non-parallel dumping. Introduce a new structure genl_dumpit_info and store the ops there. Distribute the info to both non-parallel and parallel dumping. Also add a helper genl_dumpit_info() to easily get the info structure in the dumpit callback from cb. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

net: genetlink: push doit/dumpit code from genl_family_rcv_msg

2019-10-06T13:44:46Z

Currently the function genl_family_rcv_msg() is quite big. Since it is quite convenient, push code that is related to doit and dumpit ops into separate functions. Do small changes on the way, like rc/err unification, NULL check etc. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

genetlink: do not validate dump requests if there is no policy

2019-05-04T05:27:10Z

Unlike do requests, dump genetlink requests now perform strict validation by default even if the genetlink family does not set policy and maxtype because it does validation and parsing on its own (e.g. because it wants to allow different message format for different commands). While the null policy will be ignored, maxtype (which would be zero) is still checked so that any attribute will fail validation. The solution is to only call __nla_validate() from genl_family_rcv_msg() if family->maxtype is set. Fixes: ef6243acb478 ("genetlink: optionally validate strictly/dumps") Signed-off-by: Michal Kubecek Reviewed-by: Johannes Berg Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2019-05-03T02:14:21Z

Three trivial overlapping conflicts. Signed-off-by: David S. Miller