linux-stable.git/net/caif, branch v3.18.76

net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx

2017-07-05T12:35:12+00:00

[ Upstream commit f146e872eb12ebbe92d8e583b2637e0741440db3 ]

The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the
function call path is:
cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
  cfctrl_linkdown_req
    cfpkt_create
      cfpkt_create_pfx
        alloc_skb(GFP_KERNEL) --> may sleep
cfserl_receive (acquire the lock by rcu_read_lock)
  cfpkt_split
    cfpkt_create_pfx
      alloc_skb(GFP_KERNEL) --> may sleep

There is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or
"GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function
is called under a rcu read lock, instead in interrupt.

To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: caif: fix misleading indentation

2017-02-08T08:43:03+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

unix/caif: sk_socket can disappear when state is unlocked

2015-06-15T18:26:52+00:00

[ Upstream commit b48732e4a48d80ed4a14812f0bab09560846514e ]

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: Sasha Levin

caif: fix MSG_OOB test in caif_seqpkt_recvmsg()

2015-03-24T12:22:20+00:00

[ Upstream commit 3eeff778e00c956875c70b145c52638c313dfb23 ]

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: Sasha Levin

caif_usb: use target structure member in memset

2014-10-14T20:05:45+00:00

parent cfusbl was used instead of first structure member 'layer'

Suggested-by: Joe Perches 
Signed-off-by: Fabian Frederick 
Signed-off-by: David S. Miller

caif_usb: remove redundant memory message

2014-10-14T20:05:45+00:00

Let MM subsystem display out of memory messages.

Signed-off-by: Fabian Frederick 
Signed-off-by: David S. Miller

caif: replace kmalloc/memset 0 by kzalloc

2014-10-14T20:04:07+00:00

Also add blank line after declaration

Signed-off-by: Fabian Frederick 
Signed-off-by: David S. Miller

caif: remove unnecessary break after goto

2014-07-15T23:27:01+00:00

Signed-off-by: Fabian Frederick 
Signed-off-by: David S. Miller

net/caif/caif_socket.c: remove unnecessary null test before debugfs_remove_recursive

2014-07-03T00:05:29+00:00

based on checkpatch:
"debugfs_remove_recursive(NULL) is safe this check is probably not required"

Cc: Dmitry Tarnyagin 
Cc: "David S. Miller" 
Cc: netdev@vger.kernel.org
Signed-off-by: Fabian Frederick 
Signed-off-by: David S. Miller

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