Skip to content

L
linux
Switch branch/tag
  1. 16 Dec, 2015 5 commits
  3. 15 Dec, 2015 20 commits
  5. 14 Dec, 2015 9 commits
    • Sergei Shtylyov's avatar
      sh_eth: uninline sh_eth_{write|read}() · 2274d375
      Sergei Shtylyov authored 
      Commit 3365711d ("sh_eth: WARN on access to a register not implemented in
in  a particular chip") added WARN_ON() to sh_eth_{read|write}(), thus making
it  unacceptable for these functions to be *inline* anymore. Remove *inline*
and move the functions from the header to the driver itself. Below   is our
code economy with ARM gcc 4.7.3:

$ size drivers/net/ethernet/renesas/sh_eth.o{~,}
   text	   data	    bss	    dec	    hex	filename
  32489	   1140	      0	  33629	   835d	drivers/net/ethernet/renesas/sh_eth.o~
  25413	   1140	      0	  26553	   67b9	drivers/net/ethernet/renesas/sh_eth.o
Suggested-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2274d375
    • Chen-Yu Tsai's avatar
      stmmac: dwmac-sunxi: Call exit cleanup function in probe error path · d856c16d
      Chen-Yu Tsai authored 
      dwmac-sunxi has 2 callbacks that were called from stmmac_platform as
part of the probe and remove sequences.

Ater the conversion of dwmac-sunxi into a standalone platform driver,
the .init function is called before calling into the stmmac driver
core, but .exit is not called to clean up if stmmac returns an error.

This patch fixes the probe error path. This properly cleans up and
releases resources when the driver core fails to probe.

Cc: Joachim Eastwood <manabian@gmail.com>
Fixes: 9a9e9a1e ("stmmac: dwmac-sunxi: turn setup callback into a
		      probe function")
Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d856c16d
    • Hannes Frederic Sowa's avatar
      net: add validation for the socket syscall protocol argument · 79462ad0
      Hannes Frederic Sowa authored 
      郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

	int socket_fd;
	struct sockaddr_in addr;
	addr.sin_port = 0;
	addr.sin_addr.s_addr = INADDR_ANY;
	addr.sin_family = 10;

	socket_fd = socket(10,3,0x40000000);
	connect(socket_fd , &addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
kernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
kernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110
kernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
kernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10
kernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

CVE: CVE-2015-8543
Cc: Cong Wang <cwang@twopensource.com>
Reported-by: default avatar郭永刚 <guoyonggang@360.cn>
Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79462ad0
    • Tobias Klauser's avatar
      net: phy: mdio-mux: Check return value of mdiobus_alloc() · 20b08e1a
      Tobias Klauser authored 
      mdiobus_alloc() might return NULL, but its return value is not
checked in mdio_mux_init(). This could potentially lead to a NULL
pointer dereference. Fix it by checking the return value

Fixes: 0ca2997d ("netdev/of/phy: Add MDIO bus multiplexer support.")
Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20b08e1a
    • Paolo Abeni's avatar
      openvswitch: fix trivial comment typo · e5f5d747
      Paolo Abeni authored 
      The commit 33db4125 ("openvswitch: Rename LABEL->LABELS") left
over an old OVS_CT_ATTR_LABEL instance, fix it.

Fixes: 33db4125 ("openvswitch: Rename LABEL->LABELS")
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
Acked-by: default avatarJoe Stringer <joe@ovn.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5f5d747
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 9e5be5bd
      David S. Miller authored 
      Pablo Neira Ayuso says:

====================
netfilter fixes for net

The following patchset contains Netfilter fixes for you net tree,
specifically for nf_tables and nfnetlink_queue, they are:

1) Avoid a compilation warning in nfnetlink_queue that was introduced
   in the previous merge window with the simplification of the conntrack
   integration, from Arnd Bergmann.

2) nfnetlink_queue is leaking the pernet subsystem registration from
   a failure path, patch from Nikolay Borisov.

3) Pass down netns pointer to batch callback in nfnetlink, this is the
   largest patch and it is not a bugfix but it is a dependency to
   resolve a splat in the correct way.

4) Fix a splat due to incorrect socket memory accounting with nfnetlink
   skbuff clones.

5) Add missing conntrack dependencies to NFT_DUP_IPV4 and NFT_DUP_IPV6.

6) Traverse the nftables commit list in reverse order from the commit
   path, otherwise we crash when the user applies an incremental update
   via 'nft -f' that deletes an object that was just introduced in this
   batch, from Xin Long.

Regarding the compilation warning fix, many people have sent us (and
keep sending us) patches to address this, that's why I'm including this
batch even if this is not critical.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e5be5bd
    • David Ahern's avatar
      net: Flush local routes when device changes vrf association · 7f49e7a3
      David Ahern authored 
      The VRF driver cycles netdevs when an interface is enslaved or released:
the down event is used to flush neighbor and route tables and the up
event (if the interface was already up) effectively moves local and
connected routes to the proper table.

As of 4f823def the local route is left hanging around after a link
down, so when a netdev is moved from one VRF to another (or released
from a VRF altogether) local routes are left in the wrong table.

Fix by handling the NETDEV_CHANGEUPPER event. When the upper dev is
an L3mdev then call fib_disable_ip to flush all routes, local ones
to.

Fixes: 4f823def ("ipv4: fix to not remove local route on link down")
Cc: Julian Anastasov <ja@ssi.bg>
Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f49e7a3
    • Andy Shevchenko's avatar
      net:hns: print MAC with %pM · 98900a80
      Andy Shevchenko authored 
      printf() has a dedicated specifier to print MAC addresses. Use it instead of
pushing each byte via stack.
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98900a80
    • Andy Shevchenko's avatar
      net:hns: annotate IO address space properly · 946973a3
      Andy Shevchenko authored 
      Mark address pointer with __iomem in the IO accessors.

Otherwise we will get a sparse complain like following

.../hns/hns_dsaf_reg.h:991:36: warning: incorrect type in argument 1 (different address spaces)
.../hns/hns_dsaf_reg.h:991:36:    expected unsigned char [noderef] [usertype] <asn:2>*base
.../hns/hns_dsaf_reg.h:991:36:    got void *base
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      946973a3
  7. 13 Dec, 2015 1 commit
    • Xin Long's avatar
      netfilter: nf_tables: use reverse traversal commit_list in nf_tables_abort · a907e36d
      Xin Long authored 
      When we use 'nft -f' to submit rules, it will build multiple rules into
one netlink skb to send to kernel, kernel will process them one by one.
meanwhile, it add the trans into commit_list to record every commit.
if one of them's return value is -EAGAIN, status |= NFNL_BATCH_REPLAY
will be marked. after all the process is done. it will roll back all the
commits.

now kernel use list_add_tail to add trans to commit, and use
list_for_each_entry_safe to roll back. which means the order of adding
and rollback is the same. that will cause some cases cannot work well,
even trigger call trace, like:

1. add a set into table foo  [return -EAGAIN]:
   commit_list = 'add set trans'
2. del foo:
   commit_list = 'add set trans' -> 'del set trans' -> 'del tab trans'
then nf_tables_abort will be called to roll back:
firstly process 'add set trans':
                   case NFT_MSG_NEWSET:
                        trans->ctx.table->use--;
                        list_del_rcu(&nft_trans_set(trans)->list);

  it will del the set from the table foo, but it has removed when del
  table foo [step 2], then the kernel will panic.

the right order of rollback should be:
  'del tab trans' -> 'del set trans' -> 'add set trans'.
which is opposite with commit_list order.

so fix it by rolling back commits with reverse order in nf_tables_abort.
Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a907e36d
  9. 12 Dec, 2015 5 commits
    • David S. Miller's avatar
      Merge branch 'mpls-fixes' · 6d13cab4
      David S. Miller authored 
      Robert Shearman says:

====================
mpls: fixes for nexthops without via addresses

These four fixes all apply to the case of having an mpls route with an
output device, but without a nexthop.

Patches 2 and 3 could really have been combined in one patch, but I
wanted to separate the fix for some recent breakage from the fix for a
day-1 issue.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d13cab4
    • Robert Shearman's avatar
      mpls: make via address optional for multipath routes · f20367df
      Robert Shearman authored 
      The via address is optional for a single path route, yet is mandatory
when the multipath attribute is used:

  # ip -f mpls route add 100 dev lo
  # ip -f mpls route add 101 nexthop dev lo
  RTNETLINK answers: Invalid argument

Make them consistent by making the via address optional when the
RTA_MULTIPATH attribute is being parsed so that both forms of
specifying the route work.
Signed-off-by: default avatarRobert Shearman <rshearma@brocade.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f20367df
    • Robert Shearman's avatar
      mpls: fix out-of-bounds access when via address not specified · eb7809f0
      Robert Shearman authored 
      When a via address isn't specified, the via table is left initialised
to 0 (NEIGH_ARP_TABLE), and the via address length also left
initialised to 0. This results in a via address array of length 0
being allocated (contiguous with route and nexthop array), meaning
that when a packet is sent using neigh_xmit the neighbour lookup and
creation will cause an out-of-bounds access when accessing the 4 bytes
of the IPv4 address it assumes it has been given a pointer to.

This could be fixed by allocating the 4 bytes of via address necessary
and leaving it as all zeroes. However, it seems wrong to me to use an
ipv4 nexthop (including possibly ARPing for 0.0.0.0) when the user
didn't specify to do so.

Instead, set the via address table to NEIGH_NR_TABLES to signify it
hasn't been specified and use this at forwarding time to signify a
neigh_xmit using an L2 address consisting of the device address. This
mechanism is the same as that used for both ARP and ND for loopback
interfaces and those flagged as no-arp, which are all we can really
support in this case.

Fixes: cf4b24f0 ("mpls: reduce memory usage of routes")
Signed-off-by: default avatarRobert Shearman <rshearma@brocade.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb7809f0
    • Robert Shearman's avatar
      mpls: don't dump RTA_VIA attribute if not specified · 72dcac96
      Robert Shearman authored 
      The problem seen is that when adding a route with a nexthop with no
via address specified, iproute2 generates bogus output:

  # ip -f mpls route add 100 dev lo
  # ip -f mpls route list
  100 via inet 0.0.8.0 dev lo

The reason for this is that the kernel generates an RTA_VIA attribute
with the family set to AF_INET, but the via address data having zero
length. The cause of family being AF_INET is that on route insert
cfg->rc_via_table is left set to 0, which just happens to be
NEIGH_ARP_TABLE which is then translated into AF_INET.

iproute2 doesn't validate the length prior to printing and so prints
garbage. Although it could be fixed to do the validation, I would
argue that AF_INET addresses should always be exactly 4 bytes so the
kernel is really giving userspace bogus data.

Therefore, avoid generating the RTA_VIA attribute when dumping the
route if the via address wasn't specified on add/modify. This is
indicated by NEIGH_ARP_TABLE and a zero via address length - if the
user specified a via address the address length would have been
validated such that it was 4 bytes. Although this is a change in
behaviour that is visible to userspace, I believe that what was
generated before was invalid and as such userspace wouldn't be
expecting it.
Signed-off-by: default avatarRobert Shearman <rshearma@brocade.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72dcac96
    • Robert Shearman's avatar
      mpls: validate L2 via address length · a3e948e8
      Robert Shearman authored 
      If an L2 via address for an mpls nexthop is specified, the length of
the L2 address must match that expected by the output device,
otherwise it could access memory beyond the end of the via address
buffer in the route.

This check was present prior to commit f8efb73c ("mpls: multipath
route support"), but got lost in the refactoring, so add it back,
applying it to all nexthops in multipath routes.

Fixes: f8efb73c ("mpls: multipath route support")
Signed-off-by: default avatarRobert Shearman <rshearma@brocade.com>
Acked-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3e948e8
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7