<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/net, branch linux-3.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2014-12-16T17:37:10Z</updated>
<entry>
<title>net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks</title>
<updated>2014-12-16T17:37:10Z</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2014-11-26T19:53:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=433337f9c00cac447d020922f59237273f5d92be'/>
<id>urn:sha1:433337f9c00cac447d020922f59237273f5d92be</id>
<content type='text'>
[ Upstream commit f4713a3dfad045d46afcb9c2a7d0bba288920ed4 ]

TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets.
If the socket is of family AF_INET6, call ipv6_recv_error instead
of ip_recv_error.

This change is more complex than a single branch due to the loadable
ipv6 module. It reuses a pre-existing indirect function call from
ping. The ping code is safe to call, because it is part of the core
ipv6 module and always present when AF_INET6 sockets are active.

Fixes: 4ed2d765 (net-timestamp: TCP timestamping)
Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;

----

It may also be worthwhile to add WARN_ON_ONCE(sk-&gt;family == AF_INET6)
to ip_recv_error.
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks</title>
<updated>2014-11-21T17:23:16Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-10-09T20:55:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=35e95fae72ddb67ef94395d99abc48589ce17875'/>
<id>urn:sha1:35e95fae72ddb67ef94395d99abc48589ce17875</id>
<content type='text'>
commit 9de7922bc709eee2f609cd01d98aaedc4cf5ea74 upstream.

Commit 6f4c618ddb0 ("SCTP : Add paramters validity check for
ASCONF chunk") added basic verification of ASCONF chunks, however,
it is still possible to remotely crash a server by sending a
special crafted ASCONF chunk, even up to pre 2.6.12 kernels:

skb_over_panic: text:ffffffffa01ea1c3 len:31056 put:30768
 head:ffff88011bd81800 data:ffff88011bd81800 tail:0x7950
 end:0x440 dev:&lt;NULL&gt;
 ------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:129!
[...]
Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff8144fb1c&gt;] skb_put+0x5c/0x70
 [&lt;ffffffffa01ea1c3&gt;] sctp_addto_chunk+0x63/0xd0 [sctp]
 [&lt;ffffffffa01eadaf&gt;] sctp_process_asconf+0x1af/0x540 [sctp]
 [&lt;ffffffff8152d025&gt;] ? _read_unlock_bh+0x15/0x20
 [&lt;ffffffffa01e0038&gt;] sctp_sf_do_asconf+0x168/0x240 [sctp]
 [&lt;ffffffffa01e3751&gt;] sctp_do_sm+0x71/0x1210 [sctp]
 [&lt;ffffffff8147645d&gt;] ? fib_rules_lookup+0xad/0xf0
 [&lt;ffffffffa01e6b22&gt;] ? sctp_cmp_addr_exact+0x32/0x40 [sctp]
 [&lt;ffffffffa01e8393&gt;] sctp_assoc_bh_rcv+0xd3/0x180 [sctp]
 [&lt;ffffffffa01ee986&gt;] sctp_inq_push+0x56/0x80 [sctp]
 [&lt;ffffffffa01fcc42&gt;] sctp_rcv+0x982/0xa10 [sctp]
 [&lt;ffffffffa01d5123&gt;] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
 [&lt;ffffffff8148bdc9&gt;] ? nf_iterate+0x69/0xb0
 [&lt;ffffffff81496d10&gt;] ? ip_local_deliver_finish+0x0/0x2d0
 [&lt;ffffffff8148bf86&gt;] ? nf_hook_slow+0x76/0x120
 [&lt;ffffffff81496d10&gt;] ? ip_local_deliver_finish+0x0/0x2d0
 [&lt;ffffffff81496ded&gt;] ip_local_deliver_finish+0xdd/0x2d0
 [&lt;ffffffff81497078&gt;] ip_local_deliver+0x98/0xa0
 [&lt;ffffffff8149653d&gt;] ip_rcv_finish+0x12d/0x440
 [&lt;ffffffff81496ac5&gt;] ip_rcv+0x275/0x350
 [&lt;ffffffff8145c88b&gt;] __netif_receive_skb+0x4ab/0x750
 [&lt;ffffffff81460588&gt;] netif_receive_skb+0x58/0x60

This can be triggered e.g., through a simple scripted nmap
connection scan injecting the chunk after the handshake, for
example, ...

  -------------- INIT[ASCONF; ASCONF_ACK] -------------&gt;
  &lt;----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
  -------------------- COOKIE-ECHO --------------------&gt;
  &lt;-------------------- COOKIE-ACK ---------------------
  ------------------ ASCONF; UNKNOWN ------------------&gt;

... where ASCONF chunk of length 280 contains 2 parameters ...

  1) Add IP address parameter (param length: 16)
  2) Add/del IP address parameter (param length: 255)

... followed by an UNKNOWN chunk of e.g. 4 bytes. Here, the
Address Parameter in the ASCONF chunk is even missing, too.
This is just an example and similarly-crafted ASCONF chunks
could be used just as well.

The ASCONF chunk passes through sctp_verify_asconf() as all
parameters passed sanity checks, and after walking, we ended
up successfully at the chunk end boundary, and thus may invoke
sctp_process_asconf(). Parameter walking is done with
WORD_ROUND() to take padding into account.

In sctp_process_asconf()'s TLV processing, we may fail in
sctp_process_asconf_param() e.g., due to removal of the IP
address that is also the source address of the packet containing
the ASCONF chunk, and thus we need to add all TLVs after the
failure to our ASCONF response to remote via helper function
sctp_add_asconf_response(), which basically invokes a
sctp_addto_chunk() adding the error parameters to the given
skb.

When walking to the next parameter this time, we proceed
with ...

  length = ntohs(asconf_param-&gt;param_hdr.length);
  asconf_param = (void *)asconf_param + length;

... instead of the WORD_ROUND()'ed length, thus resulting here
in an off-by-one that leads to reading the follow-up garbage
parameter length of 12336, and thus throwing an skb_over_panic
for the reply when trying to sctp_addto_chunk() next time,
which implicitly calls the skb_put() with that length.

Fix it by using sctp_walk_params() [ which is also used in
INIT parameter processing ] macro in the verification *and*
in ASCONF processing: it will make sure we don't spill over,
that we walk parameters WORD_ROUND()'ed. Moreover, we're being
more defensive and guard against unknown parameter types and
missized addresses.

Joint work with Vlad Yasevich.

Fixes: b896b82be4ae ("[SCTP] ADDIP: Support for processing incoming ASCONF_ACK chunks.")
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: sctp: fix panic on duplicate ASCONF chunks</title>
<updated>2014-11-21T17:23:16Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-10-09T20:55:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dd8aaf1f380e008044857d7d2293e8e2824772b8'/>
<id>urn:sha1:dd8aaf1f380e008044857d7d2293e8e2824772b8</id>
<content type='text'>
commit b69040d8e39f20d5215a03502a8e8b4c6ab78395 upstream.

When receiving a e.g. semi-good formed connection scan in the
form of ...

  -------------- INIT[ASCONF; ASCONF_ACK] -------------&gt;
  &lt;----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
  -------------------- COOKIE-ECHO --------------------&gt;
  &lt;-------------------- COOKIE-ACK ---------------------
  ---------------- ASCONF_a; ASCONF_b -----------------&gt;

... where ASCONF_a equals ASCONF_b chunk (at least both serials
need to be equal), we panic an SCTP server!

The problem is that good-formed ASCONF chunks that we reply with
ASCONF_ACK chunks are cached per serial. Thus, when we receive a
same ASCONF chunk twice (e.g. through a lost ASCONF_ACK), we do
not need to process them again on the server side (that was the
idea, also proposed in the RFC). Instead, we know it was cached
and we just resend the cached chunk instead. So far, so good.

Where things get nasty is in SCTP's side effect interpreter, that
is, sctp_cmd_interpreter():

While incoming ASCONF_a (chunk = event_arg) is being marked
!end_of_packet and !singleton, and we have an association context,
we do not flush the outqueue the first time after processing the
ASCONF_ACK singleton chunk via SCTP_CMD_REPLY. Instead, we keep it
queued up, although we set local_cork to 1. Commit 2e3216cd54b1
changed the precedence, so that as long as we get bundled, incoming
chunks we try possible bundling on outgoing queue as well. Before
this commit, we would just flush the output queue.

Now, while ASCONF_a's ASCONF_ACK sits in the corked outq, we
continue to process the same ASCONF_b chunk from the packet. As
we have cached the previous ASCONF_ACK, we find it, grab it and
do another SCTP_CMD_REPLY command on it. So, effectively, we rip
the chunk-&gt;list pointers and requeue the same ASCONF_ACK chunk
another time. Since we process ASCONF_b, it's correctly marked
with end_of_packet and we enforce an uncork, and thus flush, thus
crashing the kernel.

Fix it by testing if the ASCONF_ACK is currently pending and if
that is the case, do not requeue it. When flushing the output
queue we may relink the chunk for preparing an outgoing packet,
but eventually unlink it when it's copied into the skb right
before transmission.

Joint work with Vlad Yasevich.

Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet")
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.</title>
<updated>2014-11-21T17:23:07Z</updated>
<author>
<name>Jesse Gross</name>
<email>jesse@nicira.com</email>
</author>
<published>2014-11-10T19:45:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0fee76308e4193dc38412e7ff7e7b7e369b91fb5'/>
<id>urn:sha1:0fee76308e4193dc38412e7ff7e7b7e369b91fb5</id>
<content type='text'>
[ Upstream commit cfdf1e1ba5bf55e095cf4bcaa9585c4759f239e8 ]

When doing GRO processing for UDP tunnels, we never add
SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
is added (such as SKB_GSO_TCPV4). The result is that if the packet is
later resegmented we will do GSO but not treat it as a tunnel. This
results in UDP fragmentation of the outer header instead of (i.e.) TCP
segmentation of the inner header as was originally on the wire.

Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets</title>
<updated>2014-11-14T18:10:21Z</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-10-30T18:27:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=561295c6f6b4157a76db7ecba961b146241a4573'/>
<id>urn:sha1:561295c6f6b4157a76db7ecba961b146241a4573</id>
<content type='text'>
[ Upstream commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 ]

UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sctp: handle association restarts when the socket is closed.</title>
<updated>2014-10-15T10:29:23Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevich@gmail.com</email>
</author>
<published>2014-10-03T22:16:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=404db05025f2fb873b0569a99cf541519fec607f'/>
<id>urn:sha1:404db05025f2fb873b0569a99cf541519fec607f</id>
<content type='text'>
[ Upstream commit bdf6fa52f01b941d4a80372d56de465bdbbd1d23 ]

Currently association restarts do not take into consideration the
state of the socket.  When a restart happens, the current assocation
simply transitions into established state.  This creates a condition
where a remote system, through a the restart procedure, may create a
local association that is no way reachable by user.  The conditions
to trigger this are as follows:
  1) Remote does not acknoledge some data causing data to remain
     outstanding.
  2) Local application calls close() on the socket.  Since data
     is still outstanding, the association is placed in SHUTDOWN_PENDING
     state.  However, the socket is closed.
  3) The remote tries to create a new association, triggering a restart
     on the local system.  The association moves from SHUTDOWN_PENDING
     to ESTABLISHED.  At this point, it is no longer reachable by
     any socket on the local system.

This patch addresses the above situation by moving the newly ESTABLISHED
association into SHUTDOWN-SENT state and bundling a SHUTDOWN after
the COOKIE-ACK chunk.  This way, the restarted associate immidiately
enters the shutdown procedure and forces the termination of the
unreachable association.

Reported-by: David Laight &lt;David.Laight@aculab.com&gt;
Signed-off-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipv6: remove rt6i_genid</title>
<updated>2014-09-30T18:00:48Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2014-09-27T22:46:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=705f1c869d577c8055736dd02501f26a2507dd5b'/>
<id>urn:sha1:705f1c869d577c8055736dd02501f26a2507dd5b</id>
<content type='text'>
Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
are already marked DST_HOST (e.g. input routes routes) will always be
invalidated during sk_dst_check. Thus per-socket dst caching absolutely
had no effect and early demuxing had no effect.

Thus this patch removes rt6i_genid: fn_sernum already gets modified during
add operations, so we only must ensure we mutate fn_sernum during ipv6
address remove operations. This is a fairly cost extensive operations,
but address removal should not happen that often. Also our mtu update
functions do the same and we heard no complains so far. xfrm policy
changes also cause a call into fib6_flush_trees. Also plug a hole in
rt6_info (no cacheline changes).

I verified via tracing that this change has effect.

Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: YOSHIFUJI Hideaki &lt;hideaki@yoshifuji.org&gt;
Cc: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Cc: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Cc: Martin Lau &lt;kafai@fb.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec</title>
<updated>2014-09-22T20:41:41Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-09-22T20:41:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=84de67b29882efaacd05861f41e749c5e8f0c3ed'/>
<id>urn:sha1:84de67b29882efaacd05861f41e749c5e8f0c3ed</id>
<content type='text'>
Steffen Klassert says:

====================
pull request (net): ipsec 2014-09-22

We generate a blackhole or queueing route if a packet
matches an IPsec policy but a state can't be resolved.
Here we assume that dst_output() is called to kill
these packets. Unfortunately this assumption is not
true in all cases, so it is possible that these packets
leave the system without the necessary transformations.

This pull request contains two patches to fix this issue:

1) Fix for blackhole routed packets.

2) Fix for queue routed packets.

Both patches are serious stable candidates.

Please pull or let me know if there are problems.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: sched: shrink struct qdisc_skb_cb to 28 bytes</title>
<updated>2014-09-22T18:21:47Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-09-18T15:02:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=257117862634d89de33fec74858b1a0ba5ab444b'/>
<id>urn:sha1:257117862634d89de33fec74858b1a0ba5ab444b</id>
<content type='text'>
We cannot make struct qdisc_skb_cb bigger without impacting IPoIB,
or increasing skb-&gt;cb[] size.

Commit e0f31d849867 ("flow_keys: Record IP layer protocol in
skb_flow_dissect()") broke IPoIB.

Only current offender is sch_choke, and this one do not need an
absolutely precise flow key.

If we store 17 bytes of flow key, its more than enough. (Its the actual
size of flow_keys if it was a packed structure, but we might add new
fields at the end of it later)

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Fixes: e0f31d849867 ("flow_keys: Record IP layer protocol in skb_flow_dissect()")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>genetlink: add function genl_has_listeners()</title>
<updated>2014-09-19T21:28:26Z</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2014-09-18T08:31:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0d566379c5e15a2922dc6bb2ee6a4b7f7a3a0786'/>
<id>urn:sha1:0d566379c5e15a2922dc6bb2ee6a4b7f7a3a0786</id>
<content type='text'>
This function is the counterpart of the function netlink_has_listeners().

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
