linux-stable.git/net/caif, branch linux-3.16.y

net: caif: Add a missing rcu_read_unlock() in caif_flow_cb

2018-11-20T18:05:46+00:00

commit 64119e05f7b31e83e2555f6782e6cdc8f81c63f4 upstream.

Add a missing rcu_read_unlock in the error path

Fixes: c95567c80352 ("caif: added check for potential null return")
Signed-off-by: YueHaibing 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: caif: fix misleading indentation

2017-11-11T13:33:52+00:00

commit 8e0cc8c326d99e41468c96fea9785ab78883a281 upstream.

gcc points out code that is not indented the way it is
interpreted:

net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen':
net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
    return cfpkt_getlen(pkt);
    ^~~~~~
net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not
   else
   ^~~~

It is clear from the context that not returning here would be
a bug, as we'd end up passing a negative length into a function
that takes a u16 length, so it is not missing curly braces
here, and I'm assuming that the indentation is the only part
that's wrong about it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

unix/caif: sk_socket can disappear when state is unlocked

2015-06-12T12:30:18+00:00

commit b48732e4a48d80ed4a14812f0bab09560846514e upstream.

got a rare NULL pointer dereference in clear_bit

Signed-off-by: Mark Salyzyn 
Acked-by: Hannes Frederic Sowa 
----
v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c
v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

caif: fix MSG_OOB test in caif_seqpkt_recvmsg()

2015-03-24T10:30:02+00:00

commit 3eeff778e00c956875c70b145c52638c313dfb23 upstream.

It should be checking flags, not msg->msg_flags.  It's ->sendmsg()
instances that need to look for that in ->msg_flags, ->recvmsg() ones
(including the other ->recvmsg() instance in that file, as well as
unix_dgram_recvmsg() this one claims to be imitating) check in flags.
Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC
in receive") back in 2010, so it goes quite a while back.

Signed-off-by: Al Viro 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

caif: remove wrong dev_net_set() call

2015-03-04T13:24:16+00:00

commit 8997c27ec41127bf57421cc0205413d525421ddc upstream.

src_net points to the netns where the netlink message has been received. This
netns may be different from the netns where the interface is created (because
the user may add IFLA_NET_NS_[PID|FD]). In this case, src_net is the link netns.

It seems wrong to override the netns in the newlink() handler because if it
was not already src_net, it means that the user explicitly asks to create the
netdevice in another netns.

CC: Sjur Brændeland 
CC: Dmitry Tarnyagin 
Fixes: 8391c4aab1aa ("caif: Bugfixes in CAIF netdevice for close and flow control")
Fixes: c41254006377 ("caif-hsi: Add rtnl support")
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

net: Fix use after free by removing length arg from sk_data_ready callbacks.

2014-04-11T20:15:36+00:00

Several spots in the kernel perform a sequence like:

	skb_queue_tail(&sk->s_receive_queue, skb);
	sk->sk_data_ready(sk, skb->len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb->len access is potentially
to freed up memory.

Furthermore, the skb->len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller

net: Include appropriate header file in caif/cfsrvl.c

2014-02-10T01:32:49+00:00

Include appropriate header file net/caif/caif_dev.h in caif/cfsrvl.c
because it has prototype declaration of functions defined in
caif/cfsrvl.c.

This eliminates the following warning in caif/cfsrvl.c:
net/caif/cfsrvl.c:198:6: warning: no previous prototype for ‘caif_free_client’ [-Wmissing-prototypes]
net/caif/cfsrvl.c:208:6: warning: no previous prototype for ‘caif_client_register_refcnt’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
Signed-off-by: David S. Miller

net: Include appropriate header file in caif/caif_dev.c

2014-02-10T01:32:49+00:00

Include appropriate header file net/caif/caif_dev.h in caif/caif_dev.c
because it has prototype declarations of function defined in
caif/caif_dev.c.

This eliminates the following file in caif/caif_dev.c:
net/caif/caif_dev.c:303:6: warning: no previous prototype for ‘caif_enroll_dev’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
Signed-off-by: David S. Miller

net: Missing change from the ether_addr_copy() fixups.

2014-01-22T06:54:01+00:00

Signed-off-by: David S. Miller

caif_usb: Use ether_addr_copy

2014-01-22T02:13:04+00:00

Use ether_addr_copy instead of memcpy(a, b, ETH_ALEN) to
save some cycles on arm and powerpc.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller