linux-stable.git/net/netfilter, branch v3.2.86

netfilter: nf_conntrack_sip: extend request line validation

2017-02-23T03:50:56+00:00

commit 444f901742d054a4cd5ff045871eac5131646cfb upstream.

on SIP requests, so a fragmented TCP SIP packet from an allow header starting with
 INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
 Content-Length: 0

will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character.

Confirm with RFC 3261
 Request-Line   =  Method SP Request-URI SP SIP-Version CRLF

Fixes: 30f33e6dee80 ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling")
Signed-off-by: Ulrich Weber 
Acked-by: Marco Angaroni 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

netfilter: restart search if moved to other chain

2017-02-23T03:50:48+00:00

commit 95a8d19f28e6b29377a880c6264391a62e07fccc upstream.

In case nf_conntrack_tuple_taken did not find a conflicting entry
check that all entries in this hash slot were tested and restart
in case an entry was moved to another chain.

Reported-by: Eric Dumazet 
Fixes: ea781f197d6a ("netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()")
Signed-off-by: Florian Westphal 
Acked-by: Eric Dumazet 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2:
 - Adjust context
 - Use NF_CT_STAT_INC(), not the _ATOMIC variant, since we disable BHs]
Signed-off-by: Ben Hutchings

netfilter: nfnetlink_queue: reject verdict request from different portid

2016-11-20T01:01:31+00:00

commit 00a3101f561816e58de054a470484996f78eb5eb upstream.

Like NFQNL_MSG_VERDICT_BATCH do, we should also reject the verdict
request when the portid is not same with the initial portid(maybe
from another process).

Fixes: 97d32cf9440d ("netfilter: nfnetlink_queue: batch verdict support")
Signed-off-by: Liping Zhang 
Reviewed-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

nf_conntrack: avoid kernel pointer value leak in slab name

2016-06-15T20:28:14+00:00

commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 upstream.

The slab name ends up being visible in the directory structure under
/sys, and even if you don't have access rights to the file you can see
the filenames.

Just use a 64-bit counter instead of the pointer to the 'net' structure
to generate a unique name.

This code will go away in 4.7 when the conntrack code moves to a single
kmemcache, but this is the backportable simple solution to avoiding
leaking kernel pointers to user space.

Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep")
Signed-off-by: Linus Torvalds 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ipvs: correct initial offset of Call-ID header search in SIP persistence engine

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

commit 7617a24f83b5d67f4dab1844956be1cebc44aec8 upstream.

The IPVS SIP persistence engine is not able to parse the SIP header
"Call-ID" when such header is inserted in the first positions of
the SIP message.

When IPVS is configured with "--pe sip" option, like for example:
ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
some particular messages (see below for details) do not create entries
in the connection template table, which can be listed with:
ipvsadm -Lcn --persistent-conn

Problematic SIP messages are SIP responses having "Call-ID" header
positioned just after message first line:
SIP/2.0 200 OK
[Call-ID header here]
[rest of the headers]

When "Call-ID" header is positioned down (after a few other headers)
it is correctly recognized.

This is due to the data offset used in get_callid function call inside
ip_vs_pe_sip.c file: since dptr already points to the start of the
SIP message, the value of dataoff should be initially 0.
Otherwise the header is searched starting from some bytes after the
first character of the SIP message.

Fixes: 758ff0338722 ("IPVS: sip persistence engine")
Signed-off-by: Marco Angaroni 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Ben Hutchings

netfilter: nf_conntrack: Support expectations in different zones

2015-08-12T14:33:22+00:00

commit 4b31814d20cbe5cd4ccf18089751e77a04afe4f2 upstream.

When zones were originally introduced, the expectation functions were
all extended to perform lookup using the zone. However, insertion was
not modified to check the zone. This means that two expectations which
are intended to apply for different connections that have the same tuple
but exist in different zones cannot both be tracked.

Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
Signed-off-by: Joe Stringer 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings

ipvs: kernel oops - do_ip_vs_get_ctl

2015-08-06T23:32:16+00:00

commit 8537de8a7ab6681cc72fb0411ab1ba7fdba62dd0 upstream.

Change order of init so netns init is ready
when register ioctl and netlink.

Ver2
	Whitespace fixes and __init added.

Reported-by: "Ryan O'Hara" 
Signed-off-by: Hans Schillstrom 
Acked-by: Julian Anastasov 
Signed-off-by: Jesper Dangaard Brouer 
Signed-off-by: Simon Horman 
Signed-off-by: Ben Hutchings 
Cc: Andreas Unterkircher

ipvs: fix memory leak in ip_vs_ctl.c

2015-08-06T23:32:10+00:00

commit f30bf2a5cac6c60ab366c4bc6db913597bf4d6ab upstream.

Fix memory leak introduced in commit a0840e2e165a ("IPVS: netns,
ip_vs_ctl local vars moved to ipvs struct."):

unreferenced object 0xffff88005785b800 (size 2048):
  comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s)
  hex dump (first 32 bytes):
    bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff  .........x.N....
    04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x4e/0xb0
    [] __kmalloc_track_caller+0x244/0x430
    [] kmemdup+0x20/0x50
    [] ip_vs_control_net_init+0x1f7/0x510
    [] __ip_vs_init+0x100/0x250
    [] ops_init+0x41/0x190
    [] setup_net+0x93/0x150
    [] copy_net_ns+0x82/0x140
    [] create_new_namespaces+0xfd/0x190
    [] unshare_nsproxy_namespaces+0x5a/0xc0
    [] SyS_unshare+0x173/0x310
    [] system_call_fastpath+0x12/0x6f
    [] 0xffffffffffffffff

Fixes: a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Tommi Rantala 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Ben Hutchings

ipvs: uninitialized data with IP_VS_IPV6

2015-05-09T22:16:41+00:00

commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.

The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.

The same issue is there in app_tcp_pkt_in().  Thanks to Julian Anastasov
for noticing that.

Signed-off-by: Dan Carpenter 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Ben Hutchings 
Cc: Pablo Neira Ayuso

ipvs: rerouting to local clients is not needed anymore

2015-05-09T22:16:40+00:00

commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream.

commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
ip_send_reply()." from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.

Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
"3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"

Reported-by: Smart Weblications GmbH - Florian Wiessner 
Tested-by: Smart Weblications GmbH - Florian Wiessner 
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Ben Hutchings 
Cc: Pablo Neira Ayuso