linux-stable.git/net/ipv4/netfilter, branch v3.2.83

netfilter: x_tables: fix unconditional helper

2016-04-30T22:05:28+00:00

commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream.

Ben Hawkes says:

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

Problem is that mark_source_chains should not have been called --
the rule doesn't have a next entry, so its supposed to return
an absolute verdict of either ACCEPT or DROP.

However, the function conditional() doesn't work as the name implies.
It only checks that the rule is using wildcard address matching.

However, an unconditional rule must also not be using any matches
(no -m args).

The underflow validator only checked the addresses, therefore
passing the 'unconditional absolute verdict' test, while
mark_source_chains also tested for presence of matches, and thus
proceeeded to the next (not-existent) rule.

Unify this so that all the callers have same idea of 'unconditional rule'.

Reported-by: Ben Hawkes 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings

ipv4: Don't do expensive useless work during inetdev destroy.

2016-04-30T22:05:24+00:00

commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 upstream.

When an inetdev is destroyed, every address assigned to the interface
is removed.  And in this scenerio we do two pointless things which can
be very expensive if the number of assigned interfaces is large:

1) Address promotion.  We are deleting all addresses, so there is no
   point in doing this.

2) A full nf conntrack table purge for every address.  We only need to
   do this once, as is already caught by the existing
   masq_dev_notifier so masq_inet_event() can skip this.

Reported-by: Solar Designer 
Signed-off-by: David S. Miller 
Tested-by: Cyrill Gorcunov 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

netfilter: x_tables: make sure e->next_offset covers remaining blob size

2016-04-30T22:05:23+00:00

commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream.

Otherwise this function may read data beyond the ruleset blob.

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

netfilter: x_tables: validate e->target_offset early

2016-04-30T22:05:23+00:00

commit bdf533de6968e9686df777dc178486f600c6e617 upstream.

We should check that e->target_offset is sane before
mark_source_chains gets called since it will fetch the target entry
for loop detection.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

netfilter: ipt_ULOG: fix info leaks

2014-08-06T17:07:40+00:00

commit 278f2b3e2af5f32ea1afe34fa12a2518153e6e49 upstream.

The ulog messages leak heap bytes by the means of padding bytes and
incompletely filled string arrays. Fix those by memset(0)'ing the
whole struct before filling it.

Signed-off-by: Mathias Krause 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

netfilter: Can't fail and free after table replacement

2014-06-09T12:28:55+00:00

commit c58dd2dd443c26d856a168db108a0cd11c285bf3 upstream.

All xtables variants suffer from the defect that the copy_to_user()
to copy the counters to user memory may fail after the table has
already been exchanged and thus exposed. Return an error at this
point will result in freeing the already exposed table. Any
subsequent packet processing will result in a kernel panic.

We can't copy the counters before exposing the new tables as we
want provide the counter state after the old table has been
unhooked. Therefore convert this into a silent error.

Cc: Florian Westphal 
Signed-off-by: Thomas Graf 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings

netfilter: nf_nat: don't check for port change on ICMP tuples

2012-12-06T11:20:10+00:00

commit 38fe36a248ec3228f8e6507955d7ceb0432d2000 upstream.

ICMP tuples have id in src and type/code in dst.
So comparing src.u.all with dst.u.all will always fail here
and ip_xfrm_me_harder() is called for every ICMP packet,
even if there was no NAT.

Signed-off-by: Ulrich Weber 
[Pablo Neira Ayuso: Backported to.3.0]
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings

netfilter: nf_nat_sip: fix via header translation with multiple parameters

2012-10-17T02:50:05+00:00

commit f22eb25cf5b1157b29ef88c793b71972efc47143 upstream.

Via-headers are parsed beginning at the first character after the Via-address.
When the address is translated first and its length decreases, the offset to
start parsing at is incorrect and header parameters might be missed.

Update the offset after translating the Via-address to fix this.

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

netfilter: nf_nat_sip: fix incorrect handling of EBUSY for RTCP expectation

2012-10-17T02:50:05+00:00

commit 3f509c689a07a4aa989b426893d8491a7ffcc410 upstream.

We're hitting bug while trying to reinsert an already existing
expectation:

kernel BUG at kernel/timer.c:895!
invalid opcode: 0000 [#1] SMP
[...]
Call Trace:
 
 [] nf_ct_expect_related_report+0x4a0/0x57a [nf_conntrack]
 [] ? in4_pton+0x72/0x131
 [] ip_nat_sdp_media+0xeb/0x185 [nf_nat_sip]
 [] set_expected_rtp_rtcp+0x32d/0x39b [nf_conntrack_sip]
 [] process_sdp+0x30c/0x3ec [nf_conntrack_sip]
 [] ? irq_exit+0x9a/0x9c
 [] ? ip_nat_sdp_media+0x185/0x185 [nf_nat_sip]

We have to remove the RTP expectation if the RTCP expectation hits EBUSY
since we keep trying with other ports until we succeed.

Reported-by: Rafal Fitt 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings

netfilter: nf_ct_ipv4: packets with wrong ihl are invalid

2012-10-17T02:50:04+00:00

commit 07153c6ec074257ade76a461429b567cff2b3a1e upstream.

It was reported that the Linux kernel sometimes logs:

klogd: [2629147.402413] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 447!
klogd: [1072212.887368] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 392

ipv4_get_l4proto() in nf_conntrack_l3proto_ipv4.c and tcp_error() in
nf_conntrack_proto_tcp.c should catch malformed packets, so the errors
at the indicated lines - TCP options parsing - should not happen.
However, tcp_error() relies on the "dataoff" offset to the TCP header,
calculated by ipv4_get_l4proto().  But ipv4_get_l4proto() does not check
bogus ihl values in IPv4 packets, which then can slip through tcp_error()
and get caught at the TCP options parsing routines.

The patch fixes ipv4_get_l4proto() by invalidating packets with bogus
ihl value.

The patch closes netfilter bugzilla id 771.

Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings