25 Jun, 2020

1 commit


28 Apr, 2020

4 commits


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
     

05 Jun, 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 and conditions of the gnu general public license
    version 2 as published by the free software foundation

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

09 Apr, 2019

1 commit

  • We need minimal support from the nat core for this, as we do not
    want to register additional base hooks.

    When an inet hook is registered, interally register ipv4 and ipv6
    hooks for them and unregister those when inet hooks are removed.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

27 Feb, 2019

1 commit

  • The l3proto name is gone, its header file is the last trace.
    While at it, also remove nf_nat_core.h, its very small and all users
    include nf_nat.h too.

    before:
    text data bss dec hex filename
    22948 1612 4136 28696 7018 nf_nat.ko

    after removal of l3proto register/unregister functions:
    text data bss dec hex filename
    22196 1516 4136 27848 6cc8 nf_nat.ko

    checkpatch complains about overly long lines, but line breaks
    do not make things more readable and the line length gets smaller
    here, not larger.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

24 Apr, 2018

1 commit

  • This is a patch proposal to support shifted ranges in portmaps. (i.e. tcp/udp
    incoming port 5000-5100 on WAN redirected to LAN 192.168.1.5:2000-2100)

    Currently DNAT only works for single port or identical port ranges. (i.e.
    ports 5000-5100 on WAN interface redirected to a LAN host while original
    destination port is not altered) When different port ranges are configured,
    either 'random' mode should be used, or else all incoming connections are
    mapped onto the first port in the redirect range. (in described example
    WAN:5000-5100 will all be mapped to 192.168.1.5:2000)

    This patch introduces a new mode indicated by flag NF_NAT_RANGE_PROTO_OFFSET
    which uses a base port value to calculate an offset with the destination port
    present in the incoming stream. That offset is then applied as index within the
    redirect port range (index modulo rangewidth to handle range overflow).

    In described example the base port would be 5000. An incoming stream with
    destination port 5004 would result in an offset value 4 which means that the
    NAT'ed stream will be using destination port 2004.

    Other possibilities include deterministic mapping of larger or multiple ranges
    to a smaller range : WAN:5000-5999 -> LAN:5000-5099 (maps WAN port 5*xx to port
    51xx)

    This patch does not change any current behavior. It just adds new NAT proto
    range functionality which must be selected via the specific flag when intended
    to use.

    A patch for iptables (libipt_DNAT.c + libip6t_DNAT.c) will also be proposed
    which makes this functionality immediately available.

    Signed-off-by: Thierry Du Tre
    Signed-off-by: Pablo Neira Ayuso

    Thierry Du Tre
     

10 Jan, 2018

1 commit

  • Place all existing user defined tables in struct net *, instead of
    having one list per family. This saves us from one level of indentation
    in netlink dump functions.

    Place pointer to struct nft_af_info in struct nft_table temporarily, as
    we still need this to put back reference module reference counter on
    table removal.

    This patch comes in preparation for the removal of struct nft_af_info.

    Signed-off-by: Pablo Neira Ayuso

    Pablo Neira Ayuso
     

24 Mar, 2017

1 commit


13 Mar, 2017

1 commit

  • Currently, there are two different methods to store an u16 integer to
    the u32 data register. For example:
    u32 *dest = ®s->data[priv->dreg];
    1. *dest = 0; *(u16 *) dest = val_u16;
    2. *dest = val_u16;

    For method 1, the u16 value will be stored like this, either in
    big-endian or little-endian system:
    0 15 31
    +-+-+-+-+-+-+-+-+-+-+-+-+
    | Value | 0 |
    +-+-+-+-+-+-+-+-+-+-+-+-+

    For method 2, in little-endian system, the u16 value will be the same
    as listed above. But in big-endian system, the u16 value will be stored
    like this:
    0 15 31
    +-+-+-+-+-+-+-+-+-+-+-+-+
    | 0 | Value |
    +-+-+-+-+-+-+-+-+-+-+-+-+

    So later we use "memcmp(®s->data[priv->sreg], data, 2);" to do
    compare in nft_cmp, nft_lookup expr ..., method 2 will get the wrong
    result in big-endian system, as 0~15 bits will always be zero.

    For the similar reason, when loading an u16 value from the u32 data
    register, we should use "*(u16 *) sreg;" instead of "(u16)*sreg;",
    the 2nd method will get the wrong value in the big-endian system.

    So introduce some wrapper functions to store/load an u8 or u16
    integer to/from the u32 data register, and use them in the right
    place.

    Signed-off-by: Liping Zhang
    Signed-off-by: Pablo Neira Ayuso

    Liping Zhang
     

07 Mar, 2017

1 commit

  • When we want to validate the expr's dependency or hooks, we must do two
    things to accomplish it. First, write a X_validate callback function
    and point ->validate to it. Second, call X_validate in init routine.
    This is very common, such as fib, nat, reject expr and so on ...

    It is a little ugly, since we will call X_validate in the expr's init
    routine, it's better to do it in nf_tables_newexpr. So we can avoid to
    do this again and again. After doing this, the second step listed above
    is not useful anymore, remove them now.

    Patch was tested by nftables/tests/py/nft-test.py and
    nftables/tests/shell/run-tests.sh.

    Signed-off-by: Liping Zhang
    Signed-off-by: Pablo Neira Ayuso

    Liping Zhang
     

05 Dec, 2016

1 commit


13 Apr, 2015

4 commits

  • Switch the nf_tables registers from 128 bit addressing to 32 bit
    addressing to support so called concatenations, where multiple values
    can be concatenated over multiple registers for O(1) exact matches of
    multiple dimensions using sets.

    The old register values are mapped to areas of 128 bits for compatibility.
    When dumping register numbers, values are expressed using the old values
    if they refer to the beginning of a 128 bit area for compatibility.

    To support concatenations, register loads of less than a full 32 bit
    value need to be padded. This mainly affects the payload and exthdr
    expressions, which both unconditionally zero the last word before
    copying the data.

    Userspace fully passes the testsuite using both old and new register
    addressing.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Pablo Neira Ayuso

    Patrick McHardy
     
  • Add helper functions to parse and dump register values in netlink attributes.
    These helpers will later be changed to take care of translation between the
    old 128 bit and the new 32 bit register numbers.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Pablo Neira Ayuso

    Patrick McHardy
     
  • Replace the array of registers passed to expressions by a struct nft_regs,
    containing the verdict as a seperate member, which aliases to the
    NFT_REG_VERDICT register.

    This is needed to seperate the verdict from the data registers completely,
    so their size can be changed.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Pablo Neira Ayuso

    Patrick McHardy
     
  • Change nft_validate_input_register() to not only validate the input
    register number, but also the length of the load, and rename it to
    nft_validate_register_load() to reflect that change.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Pablo Neira Ayuso

    Patrick McHardy
     

19 Jan, 2015

1 commit

  • The user can crash the kernel if it uses any of the existing NAT
    expressions from the wrong hook, so add some code to validate this
    when loading the rule.

    This patch introduces nft_chain_validate_hooks() which is based on
    an existing function in the bridge version of the reject expression.

    Signed-off-by: Pablo Neira Ayuso

    Pablo Neira Ayuso
     

23 Dec, 2014

1 commit


18 Oct, 2014

3 commits


14 Oct, 2014

1 commit

  • This adds the missing validation code to avoid the use of nat/masq from
    non-nat chains. The validation assumes two possible configuration
    scenarios:

    1) Use of nat from base chain that is not of nat type. Reject this
    configuration from the nft_*_init() path of the expression.

    2) Use of nat from non-base chain. In this case, we have to wait until
    the non-base chain is referenced by at least one base chain via
    jump/goto. This is resolved from the nft_*_validate() path which is
    called from nf_tables_check_loops().

    The user gets an -EOPNOTSUPP in both cases.

    Signed-off-by: Pablo Neira Ayuso

    Pablo Neira Ayuso
     

09 Sep, 2014

1 commit

  • Both SNAT and DNAT (and the upcoming masquerade) can have additional
    configuration parameters, such as port randomization and NAT addressing
    persistence. We can cover these scenarios by simply adding a flag
    attribute for userspace to fill when needed.

    The flags to use are defined in include/uapi/linux/netfilter/nf_nat.h:

    NF_NAT_RANGE_MAP_IPS
    NF_NAT_RANGE_PROTO_SPECIFIED
    NF_NAT_RANGE_PROTO_RANDOM
    NF_NAT_RANGE_PERSISTENT
    NF_NAT_RANGE_PROTO_RANDOM_FULLY
    NF_NAT_RANGE_PROTO_RANDOM_ALL

    The caller must take care of not messing up with the flags, as they are
    added unconditionally to the final resulting nf_nat_range.

    Signed-off-by: Arturo Borrero Gonzalez
    Signed-off-by: Pablo Neira Ayuso

    Arturo Borrero
     

16 Jun, 2014

1 commit


08 Mar, 2014

1 commit

  • The family in the NAT expression is basically completely useless since
    we have it available during runtime anyway. Nevertheless it is used to
    decide the NAT family, so at least validate it properly. As we don't
    support cross-family NAT, it needs to match the family of the table the
    expression exists in.

    Unfortunately we can't remove it completely since we need to dump it for
    userspace (*sigh*), so at least reduce the memory waste.

    Additionally clean up the module init function by removing useless
    temporary variables.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Pablo Neira Ayuso

    Patrick McHardy
     

29 Oct, 2013

1 commit

  • This patch fixes this:

    CHECK net/netfilter/nft_nat.c
    net/netfilter/nft_nat.c:50:43: warning: incorrect type in assignment (different base types)
    net/netfilter/nft_nat.c:50:43: expected restricted __be32 [addressable] [usertype] ip
    net/netfilter/nft_nat.c:50:43: got unsigned int [unsigned] [usertype]
    net/netfilter/nft_nat.c:51:43: warning: incorrect type in assignment (different base types)
    net/netfilter/nft_nat.c:51:43: expected restricted __be32 [addressable] [usertype] ip
    net/netfilter/nft_nat.c:51:43: got unsigned int [unsigned] [usertype]
    net/netfilter/nft_nat.c:65:37: warning: incorrect type in assignment (different base types)
    net/netfilter/nft_nat.c:65:37: expected restricted __be16 [addressable] [assigned] [usertype] all
    net/netfilter/nft_nat.c:65:37: got unsigned int [unsigned]
    net/netfilter/nft_nat.c:66:37: warning: incorrect type in assignment (different base types)
    net/netfilter/nft_nat.c:66:37: expected restricted __be16 [addressable] [assigned] [usertype] all
    net/netfilter/nft_nat.c:66:37: got unsigned int [unsigned]

    Signed-off-by: Tomasz Bursztyka
    Signed-off-by: Pablo Neira Ayuso

    Tomasz Bursztyka
     

15 Oct, 2013

1 commit

  • This patch generalizes the NAT expression to support both IPv4 and IPv6
    using the existing IPv4/IPv6 NAT infrastructure. This also adds the
    NAT chain type for IPv6.

    This patch collapses the following patches that were posted to the
    netfilter-devel mailing list, from Tomasz:

    * nf_tables: Change NFTA_NAT_ attributes to better semantic significance
    * nf_tables: Split IPv4 NAT into NAT expression and IPv4 NAT chain
    * nf_tables: Add support for IPv6 NAT expression
    * nf_tables: Add support for IPv6 NAT chain
    * nf_tables: Fix up build issue on IPv6 NAT support

    And, from Pablo Neira Ayuso:

    * fix missing dependencies in nft_chain_nat

    Signed-off-by: Tomasz Bursztyka
    Signed-off-by: Pablo Neira Ayuso

    Tomasz Bursztyka