In the Linux kernel, the following vulnerability has been resolved:

netfilter: handle unreadable frags

sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skbfragsreadable(skb) returns false) is processed by the u32 module, skbcopybits() will safely return a negative error code [..]

xtu32: bail out with hotdrop in this case. gatherfrags: return -1, just as if we had no fragment header. nfnetlinkqueue: restrict to the linear part. nfnetlinklog: restrict to the linear part.

v2: - skbzerocopy helpers don't copy readable flag, i.e. nfnetlinkqueue is broken too xtu32 shouldn't return true if hotdrop was set.

A buffer overflow in iptables-restore in netfilter iptables 1.8.2 allows an attacker to (at least) crash the program or potentially gain code execution via a specially crafted iptables-save file. This is related to addparamtoargv in xshared.c.

In the marksourcechains function (net/ipv4/netfilter/iptables.c) it is possible for a user-supplied iptentry structure to have a large nextoffset field. This field is not bounds checked prior to writing a counter value at the supplied offset.

Proposed fix:

patch v1 message: http://marc.info/?l=netfilter-devel&m=145757134822741&w=2 patch v2 thread: http://marc.info/?t=145757149500006&r=1&w=2

patch v2 message: http://marc.info/?l=netfilter-devel&m=145762719008418&w=2 patch v2 thread: (none yet) http://marc.info/?l=netfilter-devel&r=4&b=201603&w=2

CVE request and assignment:

http://seclists.org/oss-sec/2016/q1/581 http://seclists.org/oss-sec/2016/q1/619

Audit done by netfilter team found several related bugs, patches to better validate rulesets are currently queued in pablos nf-next tree upstream (use "parent" link to cycle to next one - there are 17 additional patches):

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit/?id=d7591f0c41ce3e67600a982bab6989ef0f07b3ce

conntrackd in conntrack-tools 1.4.2 and earlier does not ensure that the optional kernel modules are loaded before using them, which allows remote attackers to cause a denial of service (crash) via a (1) DCCP, (2) SCTP, or (3) ICMPv6 packet.

It was reported [1] that iptables can allow protocols that do not have a protocol handler kernel module loaded.

Given following iptables ruleset: -P FORWARD DROP -A FORWARD -m sctp --dport 9 -j ACCEPT -A FORWARD -p tcp --dport 80 -j ACCEPT -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT

One would assume that this allows SCTP on port 9 and TCP on port 80. Unfortunately, if the SCTP conntrack module is not loaded, this allows all SCTP communication to pass through, i.e. -p sctp -j ACCEPT

[1]: http://www.spinics.net/lists/netfilter-devel/msg33430.html

extensions/libxttcp.c in iptables through 1.4.21 does not match TCP SYN+FIN packets in --syn rules, which might allow remote attackers to bypass intended firewall restrictions via crafted packets. NOTE: the CVE-2012-6638 fix makes this issue less relevant.

Description of problem: commit dce766af541f6605fa9889892c0280bab31c66ab Author: Florian Westphal <fwestphal> Date: Fri Jan 8 17:31:24 2010 +0100

netfilter: ebtables: enforce CAPNETADMIN normal users are currently allowed to set/modify ebtables rules. Restrict it to processes with CAPNETADMIN. Note that this cannot be reproduced with unmodified ebtables binary because it uses SOCKRAW. Signed-off-by: Florian Westphal <fwestphal> Cc: stable Signed-off-by: Patrick McHardy <kaber>

Upstream commit: http://git.kernel.org/linus/dce766af541f6605fa9889892c0280bab31c66ab

iptables before 1.2.4 does not accurately convert rate limits that are specified on the command line, which could allow attackers or users to generate more or less traffic than intended by the administrator.

iptables-save in iptables before 1.2.4 records the "--reject-with icmp-host-prohibited" rule as "--reject-with tcp-reset," which causes iptables to generate different responses than specified by the administrator, possibly leading to an information leak.