linux-stable.git/net/socket.c, branch linux-3.16.y

compat_ioctl: handle SIOCOUTQNSD

2020-02-11T20:03:19+00:00

commit 9d7bf41fafa5b5ddd4c13eb39446b0045f0a8167 upstream.

Unlike the normal SIOCOUTQ, SIOCOUTQNSD was never handled in compat
mode. Add it to the common socket compat handler along with similar
ones.

Fixes: 2f4e1b397097 ("tcp: ioctl type SIOCOUTQNSD returns amount of data not sent")
Cc: Eric Dumazet 
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings

net: socket: fix potential spectre v1 gadget in socketcall

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

commit c8e8cd579bb4265651df8223730105341e61a2d1 upstream.

'call' is a user-controlled value, so sanitize the array index after the
bounds check to avoid speculating past the bounds of the 'nargs' array.

Found with the help of Smatch:

net/socket.c:2508 __do_sys_socketcall() warn: potential spectre issue
'nargs' [r] (local cap)

Cc: Josh Poimboeuf 
Signed-off-by: Jeremy Cline 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: socket: fix recvmmsg not returning error from sock_error

2017-03-16T02:27:23+00:00

[ Upstream commit e623a9e9dec29ae811d11f83d0074ba254aba374 ]

Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"),
changed the exit path of recvmmsg to always return the datagrams
variable and modified the error paths to set the variable to the error
code returned by recvmsg if necessary.

However in the case sock_error returned an error, the error code was
then ignored, and recvmmsg returned 0.

Change the error path of recvmmsg to correctly return the error code
of sock_error.

The bug was triggered by using recvmmsg on a CAN interface which was
not up. Linux 4.6 and later return 0 in this case while earlier
releases returned -ENETDOWN.

Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path")
Signed-off-by: Maxime Jayat 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

sock: fix sendmmsg for partial sendmsg

2017-03-16T02:27:21+00:00

[ Upstream commit 3023898b7d4aac65987bd2f485cc22390aae6f78 ]

Do not send the next message in sendmmsg for partial sendmsg
invocations.

sendmmsg assumes that it can continue sending the next message
when the return value of the individual sendmsg invocations
is positive. It results in corrupting the data for TCP,
SCTP, and UNIX streams.

For example, sendmmsg([["abcd"], ["efgh"]]) can result in a stream
of "aefgh" if the first sendmsg invocation sends only the first
byte while the second sendmsg goes through.

Datagram sockets either send the entire datagram or fail, so
this patch affects only sockets of type SOCK_STREAM and
SOCK_SEQPACKET.

Fixes: 228e548e6020 ("net: Add sendmmsg socket system call")
Signed-off-by: Soheil Hassas Yeganeh 
Signed-off-by: Eric Dumazet 
Signed-off-by: Willem de Bruijn 
Signed-off-by: Neal Cardwell 
Acked-by: Maciej Żenczykowski 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: we don't have the iov_iter API, so make
 ___sys_sendmsg() calculate and write back the remaining length]   
Signed-off-by: Ben Hutchings

net: Fix use after free in the recvmmsg exit path

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

commit 34b88a68f26a75e4fded796f1a49c40f82234b7d upstream.

The syzkaller fuzzer hit the following use-after-free:

  Call Trace:
   [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
   [] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
   [<     inline     >] SYSC_recvmmsg net/socket.c:2281
   [] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
   [] entry_SYSCALL_64_fastpath+0x16/0x7a
  arch/x86/entry/entry_64.S:185

And, as Dmitry rightly assessed, that is because we can drop the
reference and then touch it when the underlying recvmsg calls return
some packets and then hit an error, which will make recvmmsg to set
sock->sk->sk_err, oops, fix it.

Reported-and-Tested-by: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: Eric Dumazet 
Cc: Kostya Serebryany 
Cc: Sasha Levin 
Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall")
http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: socket: Fix the wrong returns for recvmsg and sendmsg

2015-06-02T10:10:03+00:00

Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream.

Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match
copy_msghdr_from_user() behaviour) made get_compat_msghdr() return
error if msg_sys->msg_namelen was negative, which changed the behaviors
of recvmsg and sendmsg syscall in a lib32 system:

Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would
return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen
was invalid and then syscall returned -EINVAL, which is correct.

And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will
fail and wants to return -EINVAL, however, the outer syscall will return
-EFAULT directly, which is unexpected.

This patch gets the return value of get_compat_msghdr() as well as
copy_msghdr_from_user(), then returns this expected value if
get_compat_msghdr() fails.

Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour)
Signed-off-by: Junling Zheng 
Signed-off-by: Hanbing Xu 
Cc: Li Zefan 
Cc: Al Viro 
Cc: David Miller 
Signed-off-by: Luis Henriques

net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland.

2015-02-18T15:36:06+00:00

commit 6a2a2b3ae0759843b22c929881cc184b00cc63ff upstream.

Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when
msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage
value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will
break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.

Signed-off-by: Ani Sinha 
Signed-off-by: David S. Miller 
Cc: Michal Marek 
Signed-off-by: Luis Henriques

net: don't OOPS on socket aio

2015-02-10T13:38:49+00:00

commit 06539d3071067ff146a9bffd1c801fa56d290909 upstream.

Signed-off-by: Christoph Hellwig 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

net: use SYSCALL_DEFINEx for sys_recv

2014-04-16T19:15:05+00:00

Make sys_recv a first class citizen by using the SYSCALL_DEFINEx
macro. Besides being cleaner this will also generate meta data
for the system call so tracing tools like ftrace or LTTng can
resolve this system call.

Signed-off-by: Jan Glauber 
Signed-off-by: David S. Miller

net: ptp: move PTP classifier in its own file

2014-04-01T20:43:18+00:00

This commit fixes a build error reported by Fengguang, that is
triggered when CONFIG_NETWORK_PHY_TIMESTAMPING is not set:

  ERROR: "ptp_classify_raw" [drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.ko] undefined!

The fix is to introduce its own file for the PTP BPF classifier,
so that PTP_1588_CLOCK and/or NETWORK_PHY_TIMESTAMPING can select
it independently from each other. IXP4xx driver on ARM needs to
select it as well since it does not seem to select PTP_1588_CLOCK
or similar that would pull it in automatically.

This also allows for hiding all of the internals of the BPF PTP
program inside that file, and only exporting relevant API bits
to drivers.

This patch also adds a kdoc documentation of ptp_classify_raw()
API to make it clear that it can return PTP_CLASS_* defines. Also,
the BPF program has been translated into bpf_asm code, so that it
can be more easily read and altered (extensively documented in [1]).

In the kernel tree under tools/net/ we have bpf_asm and bpf_dbg
tools, so the commented program can simply be translated via
`./bpf_asm -c prog` where prog is a file that contains the
commented code. This makes it easily readable/verifiable and when
there's a need to change something, jump offsets etc do not need
to be replaced manually which can be very error prone. Instead,
a newly translated version via bpf_asm can simply replace the old
code. I have checked opcode diffs before/after and it's the very
same filter.

  [1] Documentation/networking/filter.txt

Fixes: 164d8c666521 ("net: ptp: do not reimplement PTP/BPF classifier")
Reported-by: Fengguang Wu 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
Cc: Richard Cochran 
Cc: Jiri Benc 
Acked-by: Richard Cochran 
Signed-off-by: David S. Miller