26 Mar, 2020

1 commit


16 Mar, 2020

1 commit

  • Commit ba0dc5f6e0ba ("netlink: allow sending extended ACK with cookie on
    success") introduced a cookie which can be sent to userspace as part of
    extended ack message in the form of NLMSGERR_ATTR_COOKIE attribute.
    Currently the cookie is ignored if error code is non-zero but there is
    no technical reason for such limitation and it can be useful to provide
    machine parseable information as part of an error message.

    Include NLMSGERR_ATTR_COOKIE whenever the cookie has been set,
    regardless of error code.

    Signed-off-by: Michal Kubecek
    Signed-off-by: David S. Miller

    Michal Kubecek
     

13 Mar, 2020

1 commit


12 Mar, 2020

1 commit


01 Mar, 2020

1 commit


28 Feb, 2020

1 commit


23 Feb, 2020

1 commit

  • 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

    Paolo Abeni
     

22 Feb, 2020

1 commit


21 Feb, 2020

1 commit

  • Since nl_groups is a u32 we can't bind more groups via ->bind
    (netlink_bind) call, but netlink has supported more groups via
    setsockopt() for a long time and thus nlk->ngroups could be over 32.
    Recently I added support for per-vlan notifications and increased the
    groups to 33 for NETLINK_ROUTE which exposed an old bug in the
    netlink_bind() code causing out-of-bounds access on archs where unsigned
    long is 32 bits via test_bit() on a local variable. Fix this by capping the
    maximum groups in netlink_bind() to BITS_PER_TYPE(u32), effectively
    capping them at 32 which is the minimum of allocated groups and the
    maximum groups which can be bound via netlink_bind().

    CC: Christophe Leroy
    CC: Richard Guy Briggs
    Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.")
    Reported-by: Erhard F.
    Signed-off-by: Nikolay Aleksandrov
    Signed-off-by: David S. Miller

    Nikolay Aleksandrov
     

18 Feb, 2020

1 commit

  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: David S. Miller

    Gustavo A. R. Silva
     

10 Dec, 2019

1 commit

  • Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except
    at places where these are defined. Later patches will remove the unused
    definition of FIELD_SIZEOF().

    This patch is generated using following script:

    EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h"

    git grep -l -e "\bFIELD_SIZEOF\b" | while read file;
    do

    if [[ "$file" =~ $EXCLUDE_FILES ]]; then
    continue
    fi
    sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file;
    done

    Signed-off-by: Pankaj Bharadiya
    Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com
    Co-developed-by: Kees Cook
    Signed-off-by: Kees Cook
    Acked-by: David Miller # for net

    Pankaj Bharadiya
     

14 Oct, 2019

1 commit

  • 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

    Michal Kubecek
     

09 Oct, 2019

1 commit

  • 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

    Jiri Pirko
     

06 Oct, 2019

5 commits


15 Jun, 2019

1 commit

  • Pointer members of an object with static storage duration, if not
    explicitly initialized, will be initialized to a NULL pointer. The
    net namespace API checks if this pointer is not NULL before using it,
    it are safe to remove the function.

    Signed-off-by: Li RongQing
    Signed-off-by: David S. Miller

    Li RongQing
     

12 Jun, 2019

1 commit


31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

22 May, 2019

1 commit

  • Pull SPDX update from Greg KH:
    "Here is a series of patches that add SPDX tags to different kernel
    files, based on two different things:

    - SPDX entries are added to a bunch of files that we missed a year
    ago that do not have any license information at all.

    These were either missed because the tool saw the MODULE_LICENSE()
    tag, or some EXPORT_SYMBOL tags, and got confused and thought the
    file had a real license, or the files have been added since the
    last big sweep, or they were Makefile/Kconfig files, which we
    didn't touch last time.

    - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan
    tools can determine the license text in the file itself. Where this
    happens, the license text is removed, in order to cut down on the
    700+ different ways we have in the kernel today, in a quest to get
    rid of all of these.

    These patches have been out for review on the linux-spdx@vger mailing
    list, and while they were created by automatic tools, they were
    hand-verified by a bunch of different people, all whom names are on
    the patches are reviewers.

    The reason for these "large" patches is if we were to continue to
    progress at the current rate of change in the kernel, adding license
    tags to individual files in different subsystems, we would be finished
    in about 10 years at the earliest.

    There will be more series of these types of patches coming over the
    next few weeks as the tools and reviewers crunch through the more
    "odd" variants of how to say "GPLv2" that developers have come up with
    over the years, combined with other fun oddities (GPL + a BSD
    disclaimer?) that are being unearthed, with the goal for the whole
    kernel to be cleaned up.

    These diffstats are not small, 3840 files are touched, over 10k lines
    removed in just 24 patches"

    * tag 'spdx-5.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (24 commits)
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 25
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 24
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 23
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 22
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 21
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 20
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 19
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 18
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 17
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 15
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 14
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 13
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 12
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 11
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 10
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 9
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 7
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 5
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 4
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 3
    ...

    Linus Torvalds
     

21 May, 2019

2 commits


20 May, 2019

1 commit


04 May, 2019

1 commit

  • 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

    Michal Kubecek
     

03 May, 2019

1 commit


28 Apr, 2019

3 commits

  • Add options to strictly validate messages and dump messages,
    sometimes perhaps validating dump messages non-strictly may
    be required, so add an option for that as well.

    Since none of this can really be applied to existing commands,
    set the options everwhere using the following spatch:

    @@
    identifier ops;
    expression X;
    @@
    struct genl_ops ops[] = {
    ...,
    {
    .cmd = X,
    + .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
    ...
    },
    ...
    };

    For new commands one should just not copy the .validate 'opt-out'
    flags and thus get strict validation.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • We currently have two levels of strict validation:

    1) liberal (default)
    - undefined (type >= max) & NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted
    - garbage at end of message accepted
    2) strict (opt-in)
    - NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted

    Split out parsing strictness into four different options:
    * TRAILING - check that there's no trailing data after parsing
    attributes (in message or nested)
    * MAXTYPE - reject attrs > max known type
    * UNSPEC - reject attributes with NLA_UNSPEC policy entries
    * STRICT_ATTRS - strictly validate attribute size

    The default for future things should be *everything*.
    The current *_strict() is a combination of TRAILING and MAXTYPE,
    and is renamed to _deprecated_strict().
    The current regular parsing has none of this, and is renamed to
    *_parse_deprecated().

    Additionally it allows us to selectively set one of the new flags
    even on old policies. Notably, the UNSPEC flag could be useful in
    this case, since it can be arranged (by filling in the policy) to
    not be an incompatible userspace ABI change, but would then going
    forward prevent forgetting attribute entries. Similar can apply
    to the POLICY flag.

    We end up with the following renames:
    * nla_parse -> nla_parse_deprecated
    * nla_parse_strict -> nla_parse_deprecated_strict
    * nlmsg_parse -> nlmsg_parse_deprecated
    * nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
    * nla_parse_nested -> nla_parse_nested_deprecated
    * nla_validate_nested -> nla_validate_nested_deprecated

    Using spatch, of course:
    @@
    expression TB, MAX, HEAD, LEN, POL, EXT;
    @@
    -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
    +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression TB, MAX, NLA, POL, EXT;
    @@
    -nla_parse_nested(TB, MAX, NLA, POL, EXT)
    +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)

    @@
    expression START, MAX, POL, EXT;
    @@
    -nla_validate_nested(START, MAX, POL, EXT)
    +nla_validate_nested_deprecated(START, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, MAX, POL, EXT;
    @@
    -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
    +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)

    For this patch, don't actually add the strict, non-renamed versions
    yet so that it breaks compile if I get it wrong.

    Also, while at it, make nla_validate and nla_parse go down to a
    common __nla_validate_parse() function to avoid code duplication.

    Ultimately, this allows us to have very strict validation for every
    new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
    next patch, while existing things will continue to work as is.

    In effect then, this adds fully strict validation for any new command.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
    netlink based interfaces (including recently added ones) are still not
    setting it in kernel generated messages. Without the flag, message parsers
    not aware of attribute semantics (e.g. wireshark dissector or libmnl's
    mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
    the structure of their contents.

    Unfortunately we cannot just add the flag everywhere as there may be
    userspace applications which check nlattr::nla_type directly rather than
    through a helper masking out the flags. Therefore the patch renames
    nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
    as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
    are rewritten to use nla_nest_start().

    Except for changes in include/net/netlink.h, the patch was generated using
    this semantic patch:

    @@ expression E1, E2; @@
    -nla_nest_start(E1, E2)
    +nla_nest_start_noflag(E1, E2)

    @@ expression E1, E2; @@
    -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
    +nla_nest_start(E1, E2)

    Signed-off-by: Michal Kubecek
    Acked-by: Jiri Pirko
    Acked-by: David Ahern
    Signed-off-by: David S. Miller

    Michal Kubecek
     

26 Apr, 2019

1 commit


18 Apr, 2019

1 commit


13 Apr, 2019

1 commit


28 Mar, 2019

1 commit


22 Mar, 2019

2 commits

  • Since maxattr is common, the policy can't really differ sanely,
    so make it common as well.

    The only user that did in fact manage to make a non-common policy
    is taskstats, which has to be really careful about it (since it's
    still using a common maxattr!). This is no longer supported, but
    we can fake it using pre_doit.

    This reduces the size of e.g. nl80211.o (which has lots of commands):

    text data bss dec hex filename
    398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
    397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
    --------------------------------
    -832 +8 0 -824

    Which is obviously just 8 bytes for each command, and an added 8
    bytes for the new policy pointer. I'm not sure why the ops list is
    counted as .text though.

    Most of the code transformations were done using the following spatch:
    @ops@
    identifier OPS;
    expression POLICY;
    @@
    struct genl_ops OPS[] = {
    ...,
    {
    - .policy = POLICY,
    },
    ...
    };

    @@
    identifier ops.OPS;
    expression ops.POLICY;
    identifier fam;
    expression M;
    @@
    struct genl_family fam = {
    .ops = OPS,
    .maxattr = M,
    + .policy = POLICY,
    ...
    };

    This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
    the cb->data as ops, which we want to change in a later genl patch.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • In genl_register_family(), when idr_alloc() fails,
    we forget to free the memory we possibly allocate for
    family->attrbuf.

    Reported-by: Hulk Robot
    Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
    Signed-off-by: YueHaibing
    Reviewed-by: Kirill Tkhai
    Signed-off-by: David S. Miller

    YueHaibing
     

22 Feb, 2019

1 commit


20 Jan, 2019

1 commit


15 Dec, 2018

1 commit


16 Oct, 2018

1 commit

  • With dump filtering we need a way to ensure the NLM_F_DUMP_FILTERED
    flag is set on a message back to the user if the data returned is
    influenced by some input attributes. Normally this can be done as
    messages are added to the skb, but if the filter results in no data
    being returned, the user could be confused as to why.

    This patch adds answer_flags to the netlink_callback allowing dump
    handlers to set the NLM_F_DUMP_FILTERED at a minimum in the
    NLMSG_DONE message ensuring the flag gets back to the user.

    The netlink_callback space is initialized to 0 via a memset in
    __netlink_dump_start, so init of the new answer_flags is covered.

    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller

    David Ahern