netfilter buglog - Feb 2018 - [Bug 1226] New: Segmentation fault when printing a rule checking byte zero of NFT_PAYLOAD_LL_HEADER

https://bugzilla.netfilter.org/show_bug.cgi?id=1226

            Bug ID: 1226
           Summary: Segmentation fault when printing a rule checking byte
                    zero of NFT_PAYLOAD_LL_HEADER
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: linus at mullvad.net

Created attachment 529
  --> https://bugzilla.netfilter.org/attachment.cgi?id=529&action=edit
Program adding rule that crashes nft

Hi! I'm writing a wrapper for libnftnl for Rust. As I'm doing that I use
the
nft tool to debug/print the rules I'm creating.

I was guessing the NFT_PAYLOAD_LL_HEADER payload base would look at the
Ethernet frame header, and would thus allow me to match on the MAC addresses.
As I was playing around with that, I managed to create a rule that made nft
segfault when trying to print it. The rule itself is probably very invalid, but
nft should likely not segfault when printing it.

# Rule that triggers the segfault:

This is how to create the rule from C using libnftnl:

static struct nftnl_rule *setup_rule()
{
    struct nftnl_rule *rule;
    struct nftnl_expr *payload_expr, *cmp_expr;
    uint8_t mac[6] = {0, 0, 0, 0, 0, 0};

    rule = nftnl_rule_alloc();
    // The segfault is only triggered if the rule is an NFPROTO_INET rule.
    nftnl_rule_set(rule, NFTNL_RULE_TABLE, "my_table");
    nftnl_rule_set(rule, NFTNL_RULE_CHAIN, "my_chain");
    nftnl_rule_set_u32(rule, NFTNL_RULE_FAMILY, NFPROTO_INET);


    payload_expr = nftnl_expr_alloc("payload");
    nftnl_expr_set_u32(payload_expr, NFTNL_EXPR_PAYLOAD_BASE,
NFT_PAYLOAD_LL_HEADER);
    nftnl_expr_set_u32(payload_expr, NFTNL_EXPR_PAYLOAD_DREG, NFT_REG_1);
    nftnl_expr_set_u32(payload_expr, NFTNL_EXPR_PAYLOAD_OFFSET, 0);
    nftnl_expr_set_u32(payload_expr, NFTNL_EXPR_PAYLOAD_LEN, 6);
    nftnl_rule_add_expr(rule, payload_expr);

    cmp_expr = nftnl_expr_alloc("cmp");
    nftnl_expr_set_u32(cmp_expr, NFTNL_EXPR_CMP_SREG, NFT_REG_1);
    nftnl_expr_set_u32(cmp_expr, NFTNL_EXPR_CMP_OP, NFT_CMP_EQ);
    nftnl_expr_set(cmp_expr, NFTNL_EXPR_CMP_DATA, &mac, 6);
    nftnl_rule_add_expr(rule, cmp_expr);

    return rule;
}

Complete code, as a modification of nft-add-rule.c from the libnftnl examples:
https://gist.github.com/faern/5f26bba2e34858176d24a421906209f3

Please note that NFTNL_EXPR_PAYLOAD_LEN can be lowered to 1 and still produce
the same result. But changing the NFTNL_EXPR_PAYLOAD_OFFSET to something
non-zero makes it not segfault. Also adding the exact same rule but under
another NFTNL_RULE_FAMILY also makes it not segfault.


# Steps to reproduce:

1. Add the corresponding table and chain, must be in the inet family.
  > nft add table inet my_table
  > nft add chain inet my_table my_chain
2. Add the breaking rule by building the code above and running it:
  > ./nft-add-rule
3. Trigger the segfault by listing the table containing the rule:
  > nft list ruleset inet


nft version: Built from latest master today, nftables v0.8.2 commit b6143aa

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180215/144f894e/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1226

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|pablo at netfilter.org         |fw at strlen.de
                 CC|                            |fw at strlen.de
             Status|NEW                         |ASSIGNED

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
I'll send a fix asap, thanks for reporting.

The rule inserted is this:
 inet my_table my_chain 2 
  [ payload load 6b @ link header + 0 => reg 1 ]
  [ cmp eq reg 1 0x00000000 0x00000000 ]

nft add rule .. ether daddr 0 generates this:
  [ meta load iiftype => reg 1 ];needed so we only test ethernet frames
  [ cmp eq reg 1 0x00000001 ]
  [ payload load 6b @ link header + 0 => reg 1 ]
  [ cmp eq reg 1 0x00000000 0x00000000 ]

When decoding, nft uses proto_inet to find the header layout to decode,
which is not correct.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180215/694acc8c/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1226

--- Comment #2 from Linus F�rnstrand <linus at mullvad.net> ---
Awesome. Very fast response!

Not really part of the bug, but could someone give me a nudge in the right
direction how to check the Ethernet frame content in a rule, if that is
possible?

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180215/a7b50ab8/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1226

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Florian Westphal <fw at strlen.de> ---
(In reply to Linus F�rnstrand from comment #2)
> Not really part of the bug, but could someone give me a nudge in the right
> direction how to check the Ethernet frame content in a rule, if that is
> possible?
Sorry, I forgot about this bz.
I guess you already figured out that you first need to allocate "meta"
expression and fetch NFT_META_IIFTYPE, it works same way as your payload
snippet.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180303/a62dfc08/attachment.html>