Skip to content

L
linux
Switch branch/tag
  1. 13 Jan, 2017 29 commits
  3. 12 Jan, 2017 1 commit
  5. 24 Dec, 2016 1 commit
  7. 23 Dec, 2016 9 commits
    • Sumit Saxena's avatar
      scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression · c27edfb6
      Sumit Saxena authored 
      [ Upstream commit 5e5ec175 ]

This patch will fix regression caused by commit 1e793f6f ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").

The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).

[mkp: clarified patch description]

Fixes: 1e793f6fReported-by: default avatarJens Axboe <axboe@kernel.dk>
CC: stable@vger.kernel.org
Signed-off-by: default avatarKashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
Tested-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
Tested-by: default avatarJens Axboe <axboe@fb.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c27edfb6
    • Michal Kubeček's avatar
      tipc: check minimum bearer MTU · 016d0298
      Michal Kubeček authored 
      [ Upstream commit 3de81b75 ]

Qian Zhang (张谦) reported a potential socket buffer overflow in
tipc_msg_build() which is also known as CVE-2016-8632: due to
insufficient checks, a buffer overflow can occur if MTU is too short for
even tipc headers. As anyone can set device MTU in a user/net namespace,
this issue can be abused by a regular user.

As agreed in the discussion on Ben Hutchings' original patch, we should
check the MTU at the moment a bearer is attached rather than for each
processed packet. We also need to repeat the check when bearer MTU is
adjusted to new device MTU. UDP case also needs a check to avoid
overflow when calculating bearer MTU.

References: CVE-2016-8632
Fixes: b97bf3fd ("[TIPC] Initial merge")
Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
Reported-by: default avatarQian Zhang (张谦) <zhangqian-c@360.cn>
Acked-by: default avatarYing Xue <ying.xue@windriver.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>

Conflicts:
	net/tipc/bearer.c
	net/tipc/bearer.h
due to 1a90632d: tipc: eliminate remnants of hungarian notation
and b1c29f6b tipc: simplify resetting and disabling of bearers
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      016d0298
    • Kees Cook's avatar
      net: ping: check minimum size on ICMP header length · efcf38bd
      Kees Cook authored 
      [ Upstream commit 0eab121e ]

Prior to commit c0371da6 ("put iov_iter into msghdr") in v3.19, there
was no check that the iovec contained enough bytes for an ICMP header,
and the read loop would walk across neighboring stack contents. Since the
iov_iter conversion, bad arguments are noticed, but the returned error is
EFAULT. Returning EINVAL is a clearer error and also solves the problem
prior to v3.19.

This was found using trinity with KASAN on v3.18:

BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
Read of size 8 by task trinity-c2/9623
page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
[<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
[<     inline     >] __dump_stack lib/dump_stack.c:15
[<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
[<     inline     >] print_address_description mm/kasan/report.c:147
[<     inline     >] kasan_report_error mm/kasan/report.c:236
[<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
[<     inline     >] check_memory_region mm/kasan/kasan.c:264
[<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
[<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
[<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
[<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
[<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
[<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
[<     inline     >] __sock_sendmsg_nosec net/socket.c:624
[<     inline     >] __sock_sendmsg net/socket.c:632
[<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
[<     inline     >] SYSC_sendto net/socket.c:1797
[<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761

CVE-2016-8399
Reported-by: default avatarQidan He <i@flanker017.me>
Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      efcf38bd
    • Philip Pettersson's avatar
      packet: fix race condition in packet_set_ring · e29fdf04
      Philip Pettersson authored 
      [ Upstream commit 84ac7260 ]

When packet_set_ring creates a ring buffer it will initialize a
struct timer_list if the packet version is TPACKET_V3. This value
can then be raced by a different thread calling setsockopt to
set the version to TPACKET_V1 before packet_set_ring has finished.

This leads to a use-after-free on a function pointer in the
struct timer_list when the socket is closed as the previously
initialized timer will not be deleted.

The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
changing the packet version while also taking the lock at the start
of packet_set_ring.

References: CVE-2016-8655
Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: default avatarPhilip Pettersson <philip.pettersson@gmail.com>
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e29fdf04
    • Sabrina Dubroca's avatar
      net: add recursion limit to GRO · fabaaaa9
      Sabrina Dubroca authored 
      [ Debian: net-add-recursion-limit-to-gro.patch ]

Currently, GRO can do unlimited recursion through the gro_receive
handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem.  Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.

This patch adds a recursion counter to the GRO layer to prevent stack
overflow.  When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally.

Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.

Fixes: CVE-2016-7039
Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
Reviewed-by: default avatarJiri Benc <jbenc@redhat.com>
Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fabaaaa9
    • Jaganath Kanakkassery's avatar
      Bluetooth: Fix potential NULL dereference in RFCOMM bind callback · 7abf3208
      Jaganath Kanakkassery authored 
      [ Upstream commit 951b6a07 ]

addr can be NULL and it should not be dereferenced before NULL checking.

References: CVE-2015-8956
Signed-off-by: default avatarJaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7abf3208
    • Jann Horn's avatar
      ptrace: being capable wrt a process requires mapped uids/gids · 74cd81c8
      Jann Horn authored 
      [ bugfix/all/ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch ]

ptrace_has_cap() checks whether the current process should be
treated as having a certain capability for ptrace checks
against another process. Until now, this was equivalent to
has_ns_capability(current, target_ns, CAP_SYS_PTRACE).

However, if a root-owned process wants to enter a user
namespace for some reason without knowing who owns it and
therefore can't change to the namespace owner's uid and gid
before entering, as soon as it has entered the namespace,
the namespace owner can attach to it via ptrace and thereby
gain access to its uid and gid.

While it is possible for the entering process to switch to
the uid of a claimed namespace owner before entering,
causing the attempt to enter to fail if the claimed uid is
wrong, this doesn't solve the problem of determining an
appropriate gid.

With this change, the entering process can first enter the
namespace and then safely inspect the namespace's
properties, e.g. through /proc/self/{uid_map,gid_map},
assuming that the namespace owner doesn't have access to
uid 0.
Changed in v2: The caller needs to be capable in the
namespace into which tcred's uids/gids can be mapped.

Rederences: CVE-2015-8709
References: https://lkml.org/lkml/2015/12/25/71Signed-off-by: default avatarJann Horn <jann@thejh.net>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      74cd81c8
    • Dan Carpenter's avatar
      scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer() · 8165fc3e
      Dan Carpenter authored 
      [ Upstream commit 7bc2b55a ]

We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.

References: CVE-2016-7425
Cc: <stable@vger.kernel.org>
Reported-by: default avatarMarco Grassi <marco.gra@gmail.com>
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8165fc3e
    • Eric W. Biederman's avatar
      mnt: Add a per mount namespace limit on the number of mounts · 1171afc4
      Eric W. Biederman authored 
      [ Upstream commit d2921684 ]

CAI Qian <caiqian@redhat.com> pointed out that the semantics
of shared subtrees make it possible to create an exponentially
increasing number of mounts in a mount namespace.

    mkdir /tmp/1 /tmp/2
    mount --make-rshared /
    for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done

Will create create 2^20 or 1048576 mounts, which is a practical problem
as some people have managed to hit this by accident.

As such CVE-2016-6213 was assigned.

Ian Kent <raven@themaw.net> described the situation for autofs users
as follows:

> The number of mounts for direct mount maps is usually not very large because of
> the way they are implemented, large direct mount maps can have performance
> problems. There can be anywhere from a few (likely case a few hundred) to less
> than 10000, plus mounts that have been triggered and not yet expired.
>
> Indirect mounts have one autofs mount at the root plus the number of mounts that
> have been triggered and not yet expired.
>
> The number of autofs indirect map entries can range from a few to the common
> case of several thousand and in rare cases up to between 30000 and 50000. I've
> not heard of people with maps larger than 50000 entries.
>
> The larger the number of map entries the greater the possibility for a large
> number of active mounts so it's not hard to expect cases of a 1000 or somewhat
> more active mounts.

So I am setting the default number of mounts allowed per mount
namespace at 100,000.  This is more than enough for any use case I
know of, but small enough to quickly stop an exponential increase
in mounts.  Which should be perfect to catch misconfigurations and
malfunctioning programs.

For anyone who needs a higher limit this can be changed by writing
to the new /proc/sys/fs/mount-max sysctl.
Tested-by: default avatarCAI Qian <caiqian@redhat.com>
Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>

Conflicts:
	fs/namespace.c
	kernel/sysctl.c
Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1171afc4
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7